Shared from "Study" on Inkdown
The 80-200MB APK/IPA you build locally is not what users download.
| Artifact | Size |
|---|---|
| Universal APK (release build) | 40-80MB |
| AAB uploaded to Play Store | 25-35MB |
| What user actually downloads (Android) | 8-15MB |
| What user actually downloads (iOS) | 3-8MB |
A minimal blank Expo app is under 4MB on the App Store. The giant local artifact is a universal dev build — not the shipped product.
1. Four CPU architectures bundled into one file Android supports arm64-v8a, armeabi-v7a, x86, x86_64. Your APK includes compiled native libraries for all four. A user's phone only needs one. So you're shipping 4 apps in one file.
2. The JavaScript engine ships inside your app
React Native bundles Hermes on Android as a compiled .so file (~10MB). On iOS, JSC is built into the OS so it's smaller, but Hermes still adds ~2MB if you enable it.
3. Expo SDK native layer Managed Expo links Camera, GPS, Sensors, Haptics, Notifications natively — even if your app never uses them. The JS side is tree-shaken since SDK 54, but the native compiled code is always there.
Play Store and App Store do it — you don't.
This is called App Thinning (iOS) and App Bundles (Android). You upload the fat universal binary. The store looks at the user's device, generates a custom version with only what that device needs (right chip, right screen density, right language), and delivers that.
It's not compression. It's surgical removal of everything irrelevant to that specific phone.
This only works if you upload AAB (not APK) on Android.
Upload .aab to Play Store, not .apk. This is what enables per-device slimming. Instant 30-40% reduction in user download size with zero code changes.
In eas.json:
95%+ of active Android devices are 64-bit. x86 is emulators. armeabi-v7a is pre-2014 devices.
Halves your native library footprint.
Without this, your app bundles string resources for every language in every dependency (Google Play Services alone has dozens).
Metro bundles everything transitively imported — even code you never call.
Tree shaking handles ESM-native libraries automatically (SDK 54+), but many libs still need explicit cherry-picking.
Every console.log you wrote is shipped to users otherwise.
@expo/vector-icons) instead of multiple PNG sizesDon't optimize blind. Run Atlas and see what's actually large before touching anything.
Opens an interactive visual map of your bundle — every module, its size, its dependencies. Usually reveals one or two libraries eating 20-30% of the bundle that you forgot about or never needed.
For deeper inspection without Hermes bytecode:
| # | Action | Impact |
|---|---|---|
| 1 | Upload AAB not APK | 30-40% download reduction |
| 2 | Target arm64-v8a only | ~40% native lib reduction |
| 3 | Enable shrinkResources + minifyEnabled | 5-15% |
| 4 | Filter locales with resConfigs | 2-5% |
| 5 | Fix JS imports / remove unused deps | varies, can be large |
| 6 | Compress/offload assets | varies, often largest for media apps |
| 7 | Strip console logs | minor |
| Link | What For |
|---|---|
| docs.expo.dev/distribution/app-size | APK vs AAB vs actual download size explained |
| docs.expo.dev/guides/tree-shaking | Metro tree shaking, SDK 54+ |
| docs.expo.dev/guides/analyzing-bundles | Expo Atlas setup |
| developer.android.com/topic/performance/reduce-apk-size | Google's own guide |
| developer.apple.com/documentation/xcode/reducing-your-app-s-size | Apple's own guide |
| callstack.com/blog/optimize-android-application-size-with-gradle-settings | Gradle config deep dive |