Google's own research found that every 6MB shaved off your Android download size correlates with roughly a 1% install-rate improvement — and users in high-growth markets are especially size-sensitive. App Bundles are the mechanism that makes those savings possible, and they're mandatory for any new app.
App size is one of the few ASO-relevant levers that's purely technical, with no metadata or creative component — but its conversion impact is real and measurable, particularly in markets where mobile data and storage are more constrained. Understanding what an Android App Bundle actually does, versus the traditional APK it replaced, is the foundation for actually using this lever.
A traditional APK is a single file containing every resource for every possible device — every screen density, every CPU architecture, every language — which a user downloads in full regardless of which of those variations actually applies to their specific phone. An Android App Bundle (AAB) instead packages all of that as a publishing format, and Google Play's servers generate and serve a much smaller, device-specific APK at download time — including only the screen density, CPU architecture, and language resources that specific device actually needs. The user never sees or downloads the unused variations at all.
Sourced from Google Play's documented App Bundle/dynamic delivery mechanism (see footer).
Illustrative install-rate improvement: +2.0%
Illustrative model based on the commonly cited ~1% install-rate lift per 6MB size reduction — your app's actual sensitivity will vary and should be validated with your own Play Console data where possible.
Users in high-growth markets — commonly cited examples include India, Brazil, and Indonesia — tend to be meaningfully more sensitive to app size than users in wealthier markets with more reliable connectivity and larger-storage devices, since mobile data costs and device storage constraints bite harder there. This means the install-rate benefit of switching to App Bundles (or further reducing size through dynamic feature modules) isn't evenly distributed across your user base — if a meaningful share of your growth is targeted at these markets, size optimization is a proportionally higher-leverage ASO investment than it would be for an app focused purely on markets with abundant storage and connectivity.
Beyond the automatic configuration splitting every AAB provides, dynamic feature modules let you go further by packaging entire features (not just device-specific resources) as separately downloadable components — installed on demand rather than bundled into the initial download. A photo-editing app might ship its core editing tools in the base install and package an advanced AI-filter feature as an on-demand module that only downloads when a user actually opens that feature, keeping the initial install size — and by extension the first-impression conversion cost — as small as possible.
Directionally true, unverified: reported install-completion-rate improvements from switching APK to AAB (commonly cited figures around 15-20%+) vary by source and app profile — treat the direction as well-supported and any specific percentage as an estimate to validate against your own data.
Beyond configuration splitting itself, the largest contributors to app size are usually native libraries compiled for multiple CPU architectures, high-resolution image and video assets not optimized for the range of screen densities actually in use, and third-party SDKs (analytics, ads, crash reporting) that each add their own weight — sometimes substantially, especially when multiple overlapping SDKs are included for redundancy or historical reasons nobody has since cleaned up. An honest size audit typically finds that a meaningful share of bloat comes not from the app's own core functionality but from accumulated dependencies and unoptimized assets that crept in incrementally across many releases, each individually small enough that no single change looked worth blocking a release over.
Because size tends to creep back up as new features, dependencies, and assets get added across successive releases, a single size-optimization pass produces a temporary win that erodes without ongoing discipline. Treating size as a metric worth monitoring release-over-release — similar to how a performance budget works for load time — catches this creep early, before it accumulates back to where an app was before the original optimization effort. Some teams set an explicit size budget per release and treat exceeding it as something that needs justification in code review, the same way an unusually large dependency addition might get flagged for review on other grounds.
"PhotoLab," a photo editor, migrates from APK to App Bundle. These are illustrative numbers to show the reasoning, not real measured data.
| Format | Typical download size | Illustrative install-rate effect |
|---|---|---|
| Traditional APK (all resources bundled) | 48 MB | Baseline |
| App Bundle (auto config splitting) | 36 MB (device-specific) | +2% illustrative, from 12MB reduction |
| App Bundle + AI filters as dynamic module | 24 MB (base install) | +4% illustrative, from further 24MB reduction |
Illustrative relative sensitivity for demonstration — actual sensitivity varies by connectivity infrastructure and device profile in each specific market.
App size doesn't operate in isolation from the other technical health metrics that affect visibility and conversion. A larger download can plausibly increase the odds a user abandons mid-download on unreliable connections, which produces a similar practical effect to a crash early in the experience — a lost install that never gets attributed clearly to its actual cause. It's also worth noting that some of the same third-party SDK bloat that inflates app size can simultaneously contribute to slower cold start time, since heavier SDKs typically mean more initialization work at launch — meaning a size-reduction effort that also audits and trims unnecessary SDKs can produce a compounding benefit across size, startup performance, and app stability simultaneously, rather than treating these as three unrelated optimization projects.
Google Play has required new apps to publish as App Bundles for some time now, but existing apps that launched before that requirement took effect could, in principle, still be running on a legacy APK-based release process if nobody has revisited it. If that describes your situation, migrating isn't a major undertaking for most apps — the App Bundle format is generated directly from the same build tooling most Android projects already use, and the automatic configuration-splitting benefit applies without any additional code changes. The larger investment, if you want to go further, is auditing for dynamic-feature-module candidates and doing a genuine size audit of dependencies — but simply publishing as an AAB instead of a legacy APK captures a meaningful share of the available benefit with comparatively little engineering effort, making it one of the better-leverage technical ASO fixes available if it hasn't already been done.
Android App Bundles let Google Play serve device-specific, smaller downloads instead of one bloated APK containing every device variation — and Google's own research ties roughly a 1% install-rate improvement to every 6MB of size reduction. This effect concentrates in high-growth, more size-sensitive markets. Beyond the automatic savings, dynamic feature modules let you defer non-essential feature downloads further, and periodic size audits keep gains from eroding as your app grows.