How to Reduce Your App Size on Mobile and Desktop

Google has published data showing that for roughly every 6MB increase in an Android app's size, install conversion drops by about 1%. That sounds small until you do the math on an app that's grown from 30MB to 90MB over a few release cycles — that's a double-digit conversion hit, silently costing installs before a single line of marketing copy even gets read.

Desktop doesn't have an app store conversion funnel in the same way, but the underlying cost is the same shape: bigger downloads mean more abandoned downloads on slow connections, slower CI/CD artifact uploads, slower auto-update delivery, and — if you're notarizing and signing builds, as any serious macOS or Windows app should — more bandwidth and time spent shipping every single release.

What actually makes up app size

Strip away the platform-specific tooling and every app's size breaks down into the same four categories: compiled code, third-party libraries and frameworks, embedded image/media assets, and — on desktop especially — native binaries duplicated across CPU architectures.

The architecture trap: a real example

We hit this directly while shipping TinyPixels itself. Our compression engine ships as a native binary bundled inside the app. Supporting both Apple Silicon and Intel Macs from one build means embedding a full compiled copy of that engine for each architecture inside a single universal binary — there's no way around it if you want both CPU types to work from one downloadable file.

The result was a direct, measurable size increase: our build went from 78.7MB to 87.2MB the moment we correctly supported both architectures — roughly 8.5MB added purely from architecture coverage, with zero new features. This is the same trade-off behind Android App Bundles and iOS App Thinning: both exist specifically so users download only the binary slice their device actually needs, instead of a universal file containing every architecture at once.

Mobile-specific tools worth using

Desktop-specific tools worth using

Desktop platforms have fewer automatic size-splitting mechanisms than mobile app stores provide, which makes manual diligence matter more. Audit which third-party frameworks and SDKs you're actually bundling — analytics, crash reporting, and update libraries each add real weight, and it's easy to accumulate several without anyone tracking the cumulative cost. Strip debug symbols from release builds where your signing/notarization process allows it. And specifically for universal binaries: there's no avoiding the architecture-duplication cost described above, so the size you reclaim has to come from elsewhere in the bundle.

The one fix that works identically on every platform

Code stripping requires careful testing — remove the wrong dependency and something breaks in production. Architecture support is largely non-negotiable if you want broad compatibility. But embedded image assets — app icons at every required resolution, onboarding illustrations, in-app screenshots, marketing graphics bundled for an about screen — are almost always compressed far less aggressively than they could be, and optimizing them carries essentially zero functional risk.

This is a surprisingly common gap: assets get exported once from a design tool, dropped into the project, and never revisited. A single onboarding illustration exported as an unoptimized PNG can be 2-3MB; the same image properly compressed is often under 200KB with no visible quality difference. Multiply that across every icon, splash screen, and in-app graphic in a typical app and the cumulative savings are real — often several megabytes reclaimed without touching a single line of application code.

A practical checklist

None of these require a rewrite. The image-compression step in particular is the one most teams skip simply because it's unglamorous — but it's also the one with the lowest risk and the fastest turnaround of anything on this list.

Frequently asked questions