Code Shrinking

How Code Shrinking Works

Code shrinking is a build-time optimisation step, not a runtime feature. It analyses an application’s code graph, traces what is reachable, and removes classes, methods, or resources that appear unused so the shipped artifact is smaller and often faster to load.

The basic idea is straightforward, but the result depends on how accurately the analyser can understand indirect use. Code reached through reflection, dependency injection, serialization, annotations, native bridges, generated wiring, or platform callbacks may look unused to a static analyser even though it is required at runtime.

That is why code shrinking is usually paired with configuration that tells the shrinker what to preserve. In practice, the value comes from trimming dead code without breaking legitimate execution paths, especially in large mobile or modular builds where unused libraries can accumulate quickly.

Why Code Shrinking Is Used

Teams use code shrinking to reduce download size, lower memory pressure, and cut the amount of bytecode the platform has to process. Smaller packages can improve installation experience and sometimes startup time, particularly on resource-constrained devices.

It also improves software hygiene by exposing whether a build actually depends on code paths that developers thought were active. In that sense, shrinking can serve as a forcing function: if a feature disappears when the optimiser runs, it may already be dead code or be relying on an implicit linkage that deserves attention.

For mobile and client applications, this matters because the practical cost of code bloat is user-visible. A seemingly minor unused dependency can inflate release size, complicate maintenance, and increase the surface area that must still be tested, scanned, and packaged.

Where Code Shrinking Can Go Wrong

The main failure mode is over-aggressive removal. If the shrinker cannot see indirect references, it may strip code that is only activated by framework conventions or runtime metadata. That can produce crashes, missing screens, broken serialization, or features that fail only under specific user flows.

Because the analyser works from static reachability, the risk is highest when execution depends on late binding or generated access paths. The more a codebase relies on hidden control flow, the more important it is to preserve the right classes and methods explicitly.

Code shrinking can also hide problems during development if teams assume that “unused” means “safe to delete” without verifying how the application is assembled at release time. The result is a build that appears clean in source form but behaves differently once optimisation and packaging are applied.

Code Shrinking in Build and Release Pipelines

In a healthy release pipeline, shrinking sits alongside testing, obfuscation, and packaging validation. It should be treated as part of release engineering, not as a cosmetic size reduction step that can be enabled once and forgotten.

Because the output is still functional software, it benefits from regression tests that exercise the runtime paths most likely to be affected by indirect references. A successful build is not proof that shrinking is correct; it only proves the optimiser finished without obvious errors.

For teams working with dynamic frameworks or generated code, the practical question is whether the shrinker’s model of reachability matches the application’s real execution model. When those two diverge, the build may be smaller but less trustworthy.

Risk and Threat Considerations

Code shrinking is primarily a build optimisation, but it carries a material integrity risk when removal logic misidentifies code that is required only through indirect runtime use. In mobile and client applications, that can create broken features, availability issues, or unintended exposure when developers compensate with overly broad keep rules.

Failure mechanism: The shrinker cannot fully observe reflection, callbacks, generated wiring, or framework-driven invocation, so it removes code that the runtime still needs, or forces teams to retain too much code to avoid breakage.

Impact: The application may crash, lose functionality, ship unnecessary surface area, or behave differently across build variants, which makes release assurance and troubleshooting harder.

Practitioner Guidance

Why practitioners should care: Code shrinking only helps when the optimisation is aligned with the application’s actual runtime behaviour. Treat every shrink step as a correctness-sensitive build transformation, not just a size reduction feature.

What to watch for: Indirect invocation paths, generated code, reflection-heavy libraries, and platform callbacks are the first places to review when a shrinked build behaves differently from a debug build. If a feature depends on hidden reachability, preserve it explicitly and verify it in release-like testing.

Practitioner takeaway: The safest way to use code shrinking is to measure size gains while continuously validating that the optimiser has not changed the application’s intended behaviour.

Related resources from NHI Mgmt Group

• How should teams handle reflection-heavy Android apps when using code shrinking?
• Why is hardcoding credentials into source code so dangerous?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between scanning AI-generated code and governing AI agent identity?