Optimizing Mobile App Size
App size directly impacts install conversion: Google data shows ~1% conversion drop per additional MB on slow internet devices. Android sets 200 MB default download limit without Wi-Fi. iOS App Store warns when downloading over 200 MB on cellular. These aren't abstract metrics — they're real install barriers.
Android: AAB and Play Feature Delivery
Switch from APK to AAB (Android App Bundle) — first and easiest step. Google Play dynamically builds optimized APK for each device: only needed ABI (arm64-v8a, x86_64), only needed density resources (xxhdpi for xxhdpi devices). Typical savings — 20-40% from universal APK size.
If project still builds APK without AAB — this technical debt needs closing first.
R8 and ProGuard. R8 enabled by default in release builds with AGP 3.4+. But minifyEnabled true and shrinkResources true in buildTypes.release must be checked explicitly — legacy projects often have them disabled "to avoid breaking". Full ProGuard gives 30-50% code size reduction.
After enabling minification, must: test release build (not debug), add rules to proguard-rules.pro for reflection-heavy libraries (Gson, Retrofit, Room migrations), Crashlytics with mapping.txt for readable stacktraces.
Resources. webp instead of PNG/JPEG for all raster images except cases where transparency with artifacts is unacceptable. Android Studio supports conversion right from IDE. Vector drawables instead of PNG for icons and simple graphics — vector size 1-3 KB vs 50-200 KB PNG set for different densities.
Unused resources: shrinkResources true removes unused resources automatically. But resources connected dynamically via Resources.getIdentifier() may be incorrectly removed — need keep.xml file.
Native libraries (.so). If project includes NDK libraries, verify ABI list: abiFilters 'arm64-v8a', 'x86_64' for production. armeabi-v7a only if supporting pre-2014 devices. Each extra ABI — copy of all .so files.
iOS: App Thinning and Bitcode
App Store automatically applies App Thinning: different build variants for different devices (2x/3x assets, arm64 only for modern devices). In Xcode Organizer → App Size Report you can see build size for specific device types.
Assets.xcassets. Images must be there, not in bundle directly — only then Asset Catalog Compiler and App Thinning work. WebP supported from iOS 14. PDF for vector assets in Asset Catalog — convenient, but Xcode rasterizes them at build time, no real size advantages. SVG via UIGraphicsImageRenderer or SwiftUI Image with systemName for SF Symbols.
On-Demand Resources. For apps with large content (games, education) — break resources into tags and load on demand. Initial download size minimal, resources pulled as progressing.
Duplicate dependencies. CocoaPods and Swift Package Manager can include one library twice in different versions. otool -L on binary or analysis via bloaty shows real contribution of each framework.
Dependency Audit — Often Yields Greater Effect
Simplest way to shrink size — remove unused dependencies. SDK connected "just in case", SDK where one function remained — candidates for removal.
| Dependency Type | Typical Size Contribution |
|---|---|
| Ad SDKs (AdMob, IronSource) | 3-8 MB |
| ML libraries (TensorFlow Lite, Core ML models) | 5-50 MB |
| Analytics (Firebase, Amplitude) | 1-3 MB |
| Maps (Google Maps SDK) | 8-15 MB |
Firebase can be connected modularly — only needed components, without pod 'Firebase' pulling everything.
Optimization timeline: three to seven business days — dependency audit and build configuration, implementing changes, measuring result.







