Why does dead code detection & deletion matter?

Over time, dead code can accumulate until it starts to take up a real chunk of the app. This can be due to A/B test branches that are no longer used, helper classes for long-deleted features, or all other manner of things. This has the following issues:

• Increased build time, due to compiling code that won’t be needed
• Worse code cleanliness, with unused classes polluting the file structure, grep results, etc.
• Longer startup time, because it will take up extra space in the binary that usually gets loaded from disk (for a deeper dive into how a binary is loaded from disk, see our blog post.

iOS

How does Reaper work?

Reaper is an SDK added to your app to report which Swift and Objective-C types were used for each user session. Emerge takes Reaper reports and generates a list of all the unused classes in your binary, for each version of your app. It's easy to integrate, either as a standalone binary or as a Cocoapod, and adds very little overhead to your app.

Reaper supports iOS 15, 16, 17, and 18. It supports all classes written in Objective-C, non-generic Swift classes, and some Swift structs/enums. If you have classes with name collisions (ex: the same name class defined multiple times using private scope in the same module) these classes may have inaccurate results.

Performance Impact

The Reaper iOS SDK will not run any code if you don't initialize it at launch. Should you initialize Reaper, the initialization is synchronous so you can measure exactly how long it takes - Emerge expects that initialization to take under 1ms.

The SDK starts running upon receiving UIApplicationDidEnterBackgroundNotification or UIApplicationWillTerminateNotification. This way, Reaper doesn't run while the user is interacting with your app. Reaper makes one network request per notification, containing:

1. List of used classes
2. App bundle id
3. App version
4. Metadata used to identify the request on the Emerge backend (no PII data)

The data in this network request is compressed and typically under ~20kb, but the size can vary based on the number of used classes in the Report. The same classes are not uploaded on every notification, each class is uploaded at most once per app launch to save user data.

Size Impact

The Reaper iOS SDK adds <20kb to the binary size.

Android

How does Reaper work?

On Android, Reaper works by instrumenting your app's code using Emerge's Gradle plugin. The plugin adds "breadcrumb" logging, which records hashed information about code as it's used.

The Reaper SDK aggregates this information into a report in the background. Once users leave your app, the Reaper SDK will upload the report to Emerge. Emerge will then connect the hashed class usage information on our backend with the detected classes in your app, which is then used to determine which code is used and unused.

Emerge will then reflect which code is unused in the Reaper UI. Emerge recommends waiting some time for a critical amount of sessions to be received before taking action on deleting unused code.

Performance Impact

Emerge has heavily tested Reaper on apps like Hacker News and Now in Android. The overall performance impact of adding/using Reaper is negligible. Reaper adds ~2 instructions to the init method of a class.

Nonetheless, Emerge would encourage adding Reaper to an alpha, beta, or internal release track before rolling out to production and validating using Emerge performance testing or any other performance metrics your team currently leverages.

Size Impact

The overall size impact of Reaper is a function of the number of classes in the app. The SDK itself adds ~12kb of download size to an app. Additionally, Reaper relies on class instrumentation, which will add a few instructions and an 8-byte hash string to each class.

For apps like Hacker News and Now in Android which have a high proportion of Java/Kotlin code and very few assets we've seen a ~5% increase in download size from adding Reaper.