Mobile app build size optimization (App Size)
Your app weighs 120 MB, and conversion during download over a mobile network drops by 30%? We have encountered such projects more than once. According to Google, each additional megabyte reduces conversion by ~1% on devices with slow internet.
Android sets a 200 MB download limit without Wi-Fi, and the iOS App Store warns when downloading over a cellular network above 200 MB. These are not abstract metrics — they are real barriers to installation.
Our experience shows that turnkey build size optimization can reduce APK/IPA by 30-60% without losing functionality, while fitting within 3-7 business days. We guarantee a measurable result: before and after.
Why is App Size important for conversion?
Every megabyte is a potentially lost user. Especially in regions with slow internet or expensive data plans. Many users download apps only over Wi-Fi, and warnings about large size reduce the likelihood of installation.
On certified iOS and Android devices, we have seen a direct correlation: reducing size by 10 MB increased conversion by 5-10%.
Android: AAB and Play Feature Delivery
Migrating from APK to AAB (Android App Bundle) is the first and simplest step. Google Play dynamically assembles an optimized APK for each device: only the required ABIs (arm64-v8a, x86_64), only the required density resources (xxhdpi for devices with xxhdpi screens). Typical savings — 20-40% of the universal APK size.
If the project is still built as APK without AAB — this is tech debt that needs to be addressed first.
How does R8 help reduce size?
R8 is enabled by default in release builds with AGP 3.4+. But minifyEnabled true and shrinkResources true in buildTypes.release need to be checked explicitly — in legacy projects they are often disabled "so nothing breaks". Full ProGuard gives 30-50% code size reduction.
After enabling minification, be sure to: test the release build (not debug), add rules to proguard-rules.pro for the reflection-heavy libraries you use (Gson, Retrofit, Room migrations), Crashlytics with mapping.txt for readable stack traces.
Resources. webp instead of PNG/JPEG for all raster images, except cases where transparency with artifacts is unacceptable. Android Studio supports conversion directly from the IDE.
Vector drawables instead of PNG for icons and simple graphics — vector size 1-3 KB versus 50-200 KB for a set of PNGs for different densities.
Unused resources: shrinkResources true removes unused resources automatically. But resources connected dynamically via Resources.getIdentifier() may be mistakenly removed — a keep.xml file is needed.
What to do with native libraries?
If the project includes NDK libraries, check the ABI list: abiFilters 'arm64-v8a', 'x86_64' for production. armeabi-v7a is only needed if you support devices from before 2014. Each extra ABI is a 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 the build size for specific device types.
Assets.xcassets. Images must be placed there, not directly in the bundle — this is the only way Asset Catalog Compiler and App Thinning work. WebP is supported starting with iOS 14.
PDF for vector assets in Asset Catalog is convenient, but Xcode rasterizes them during build, so it doesn't provide real size advantages. SVG via UIGraphicsImageRenderer or SwiftUI Image with systemName for SF Symbols.
On-Demand Resources. For apps with a large amount of content (games, education) — splitting resources into tags and loading on demand. The initial download size is minimal, resources are pulled in as you progress.
Duplicate dependencies. CocoaPods and Swift Package Manager can include the same library twice in different versions. otool -L on the binary or analysis via bloaty will show the real contribution of each framework.
Dependency Audit — Hidden Reserve
The simplest way to reduce size is to remove unused dependencies. An SDK added "just in case", an SDK with only one function left — both are candidates for removal.
| Dependency type | Typical contribution to size |
|---|---|
| Advertising 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 integrated modularly — only the required components, without pod 'Firebase' which pulls in everything at once.
Comparison of optimization techniques
| Method | Typical reduction | Effort |
|---|---|---|
| R8/ProGuard + shrinkResources | 30-50% | 1-2 days |
| AAB (Android) | 20-40% | 1 day |
| WebP and vectorization | 10-30% | 1-2 days |
| Removing unused dependencies | 5-30% | 1-3 days |
| App Thinning + ODR (iOS) | 15-30% | 2-3 days |
Work Process
- Analysis of the original build — measure size on different devices using APK Analyzer, App Size Report.
- Identify priority areas — find "heavy" components.
- Implement changes — configure AAB, ProGuard, resource conversion.
- Testing — release build on all target devices without crashes and bugs.
- Deploy to stores — publish the optimized version.
What is included in the work?
- Audit of the current build configuration (Gradle, Xcode)
- Dependency analysis and recommendations for removal
- ProGuard/R8 setup with support for all libraries
- Convert resources to WebP
- Migration to AAB (Android) and App Thinning setup (iOS)
- Documentation of changes made
- Support during publishing to App Store and Google Play
Timeline and cost
Optimization timeline — from 3 to 7 business days. Cost is calculated individually after project evaluation. We perform work remotely or at your site. Our experience — 10+ years in mobile development, 200+ successful projects. Get a consultation: contact us, and we will analyze your build and propose an optimization plan.