Cutting App Size and Cold Start Time

Two numbers decide whether a new user ever sees your app work: how long the download takes on their data plan, and how long the first launch feels. Both are usually fixable without touching features.

Size: ship what the device needs

App bundles let the store deliver only the resources for that device rather than every density and architecture. Beyond that, the biggest wins are usually uncompressed images, unused libraries pulled in for one helper function, and resources kept in the binary that could be downloaded on demand. Run a size analysis before optimising, because the answer is rarely where you assume.

Cold start: do less before the first frame

Cold start time is dominated by work done during application startup: initialising analytics, crash reporting, feature flags, dependency graphs and database connections, all in sequence. Most of these can be deferred until after the first screen is drawn, or moved off the main thread entirely.

Make the wait feel shorter

Where work genuinely cannot be deferred, showing a real layout with placeholder content beats a blank screen or a spinner. Perceived speed is not a trick; a user who sees structure believes the app is working.

Track both numbers in your release checklist. They creep upward one library at a time, and nobody notices until an install rate drops.