Every extra megabyte of app size costs you install conversions — studies from both Google and Apple have shown download abandonment rises sharply as size increases, especially on slower connections. The good news: most bloat comes from a small number of predictable places, and fixing them doesn't require rewriting the app.
Where the size actually goes
Before optimizing anything, it helps to know the usual breakdown of a typical app:
| Component | Typical share of size | Fixable how |
|---|---|---|
| Images & icons | 30-60% | Compress, convert to WebP/AVIF, remove unused densities |
| Compiled code | 15-30% | Code shrinking (R8/ProGuard), removing unused libraries |
| Fonts & audio/video | 5-20% | Subset fonts, compress media, load large media on demand |
| Third-party SDKs | varies widely | Audit and remove SDKs you no longer use |
Images are almost always the single biggest, easiest win — which is why it's the first thing worth checking.
Fix #1: switch image assets to WebP or AVIF
PNG is lossless but heavy. WebP typically cuts file size by 25-35% at equal visual quality, and AVIF often goes further still. For an app with dozens of bundled images, converting the whole set is usually the single highest-leverage change you can make in an afternoon. See WebP vs PNG for Mobile Apps for the full comparison.
Use the image converter to batch-convert an entire folder of PNGs to WebP in one pass, and the image compressor to squeeze quality-adjustable savings out of images you need to keep as JPEG or PNG.
Fix #2: ship an Android App Bundle, not a universal APK
Google Play's Android App Bundle (AAB) format lets Google Play generate and deliver a device-specific APK to each user — someone with a phone that only needs one screen density and one CPU architecture doesn't download resources for every other device Android supports. Switching from a universal APK to an AAB routinely cuts the size a typical user downloads by 15-50% with no code changes at all.
Fix #3: enable code shrinking
Android's R8 (the modern successor to ProGuard) removes unused code, inlines short methods, and shortens class/method names, often shrinking the compiled code portion by 20-40%. On iOS, Xcode's built-in "Dead Code Stripping" and bitcode-era optimizations do a similar job automatically in Release builds — the main manual lever there is trimming unused third-party frameworks.
Fix #4: audit your third-party SDKs
Analytics SDKs, ad networks, and old libraries you integrated once and forgot about are a common, invisible source of size. It's worth periodically checking your build's size report (Android Studio's APK Analyzer, or Xcode's App Thinning report) for anything large that isn't earning its space.
Fix #5: don't bundle what you can download on demand
Large media files, onboarding videos, or asset packs only some users need are good candidates for on-demand delivery (Android's Play Feature Delivery, or a simple download-on-first-launch from your own server) instead of shipping inside the initial install.
Start with the easiest win: your images
Batch-compress or convert every image in your app to WebP/AVIF in minutes — free.
A quick before-you-ship checklist
- Are all bundled images compressed and in a modern format (WebP/AVIF where supported)?
- Are you shipping an AAB (Android) rather than a universal APK?
- Is code shrinking (R8/ProGuard) enabled for release builds?
- Have you checked your build's size report for any single oversized component?
- Are large, optional assets downloaded on demand instead of bundled?
FAQ
Does app size actually affect downloads?
Yes — both Google and Apple have published data showing install abandonment rises measurably as app size increases, particularly over cellular connections.
What's the single biggest way to reduce app size?
For most apps, it's images — converting bundled assets to WebP or AVIF and compressing photos typically has the highest size-reduction-to-effort ratio of any single change.
Do I need to rewrite my app to make it smaller?
No — image conversion, enabling an App Bundle, and turning on code shrinking are all configuration or asset-level changes, not rewrites.