Reaper iOS

Why it's ranked here

Its runtime evidence is more useful than a purely static guess when reflection and dynamic loading complicate reachability. The design is focused and inspectable, but incomplete Swift coverage, narrow binary support, and a required collection pipeline make it a specialist diagnostic rather than a turnkey cleanup system.

What's good

It handles Objective-C classes plus many Swift classes, structs, and enums. Reports contain only newly observed types, reducing repeated output across background and termination events. The bundle analyzer includes embedded frameworks, understands chained fixups, and emits a simple JSON inventory for downstream comparison.

Tradeoffs

Generic Swift types and types with resilient superclasses fall outside key detection paths. The analyzer rejects fat binaries and supports only arm64 input. Runtime collection activates only on an explicit set of operating-system major versions. Reaper supplies observations through a callback, so storage, aggregation, comparison, and deletion decisions remain your responsibility.

How to use it well

Use it for mature iOS apps with representative production sessions and engineers comfortable validating removal candidates. Collect usage across varied journeys, compare those reports with the bundle inventory, then confirm each candidate before deletion. It does not provide a hosted backend, automatic source edits, or proof that an unobserved path is unreachable.

Observed

License

MIT

Implementation languages

Objective-C++, Swift, and TypeScript

Install surfaces

Swift Package Manager, CocoaPods, and downloadable XCFramework

Interface

Embedded iOS library with a callback, plus a Node-based bundle analysis CLI

Platform

iOS, with a declared deployment target of iOS 13

Binary analysis support

64-bit arm64 Mach-O input; fat binaries are rejected

Output format

The bundle analyzer writes a JSON array of detectable type names