Does App Size Affect Installs? What the Docs Actually Say

Google states the relationship directly: increasing your app's size can negatively impact install success and increase uninstalls. That sentence appears in Android's own guidance on reducing app size, and it is the strongest first-party statement you will find on the subject.

The full quote from the reduce your app size guide reads: larger sizes are possible using Play Feature Delivery and Play Asset Delivery, but increasing your app's size can negatively impact install success and increase uninstalls, so Google recommends applying the guidelines on that page to reduce download size as much as possible.

The same page explains the mechanism in user terms rather than algorithmic ones. Users often avoid downloading apps that seem too large, particularly in emerging markets where devices connect to spotty 2G and 3G networks or work on plans with data limits. Play Console's own help repeats the framing from the developer's side: app size is an important aspect of technical quality that can affect your app's install and uninstall metrics.

That distinction matters more than it sounds. "Size affects installs" is a documented fact you can act on. "Every 6MB costs you X per cent" is a planning input you would build a roadmap around, and building a roadmap on an unverifiable coefficient is how teams end up spending a quarter on a rewrite that returns nothing measurable.

Across the 300+ apps we have managed since 2013, the honest version of this brief is: cut size when the evidence in your own Console says size is hurting you, and treat the global claims as direction rather than arithmetic. The rest of this piece is about finding that evidence.

Because three current Google pages state three different ceilings, and any team that reads only one of them will plan against the wrong number. This is not a rumour or a stale third-party summary — the contradiction is live across developer.android.com and Play Console Help, and it is worth documenting before anyone quotes a limit in a planning document.

The App Bundle FAQ is explicit that the base module ceiling is 500MB and that Play checks the maximum cumulative total compressed download size any individual device receives is not over 4GB. The App Bundle guide adds a third framing again: new apps larger than 200MB are now supported by either Play Feature Delivery or Play Asset Delivery.

Read together, the most coherent reading is that 200MB is no longer a hard publication cap but a threshold with consequences attached, and that the operative limits are the ones in the Console table. There is a documentation reason to prefer that reading: Play Console Help states that all Google Play size limits are based on the compressed download size, as calculated by Play Console upon uploading your app bundle. The number that stops an upload is the number Console computes against its own table.

We keep a note on this in our internal checklist for the same reason we keep notes on the vitals thresholds — see the Android vitals thresholds that decide distribution — because a limit quoted from memory in a sprint planning session is a limit nobody re-checks for two years.

Play shows the user a dialog, and Google is precise about the kind of dialog it is. Play Console Help states that if your app is above 200MB in size, users on a mobile data connection will see a non-blocking dialog when installing the app from Google Play informing them of the app's large size.

Three words in that sentence carry the entire commercial argument, and they are worth taking one at a time.

• Above 200MB. A documented, specific threshold in the Google Play size limits documentation, measured on compressed download size. This is the one size number in the whole subject that behaves like an actual switch.
• Mobile data connection. The dialog is conditional on how the user is connected. In a market where a large share of installs happen on mobile data rather than home broadband, this affects a materially different proportion of your funnel than it does in a market where it does not.
• Non-blocking. Nobody is stopped. The install still proceeds. What is added is an interruption at the exact moment the user has already decided to install, which is the most expensive moment in the funnel to introduce a reason to reconsider.

What Google does not publish is what fraction of users abandon at that dialog. We have never seen a first-party figure for it, and we will not print a second-hand one. If your app sits just above 200MB, the actionable question is not "how many people does this cost me" but "how far below the threshold can I get, and how quickly", because getting under it removes the interruption entirely rather than reducing it.

For apps whose growth depends on India and comparable markets, this is a bigger lever than it looks on a spreadsheet. It compounds with the connectivity point from the size guide — spotty networks and data-limited plans — and with everything in the India app market picture about how installs actually happen there.

Play Console publishes an App size dashboard whose two storage metrics are the closest thing to a direct read on whether size is damaging your business. Most teams look at the size number and stop, which skips the two fields that actually answer the question.

The dashboard reports, in Google's own labels: app download size, which is your app's size on a reference device and its size range across all device configurations; app download size versus peers; app download size over time; active devices with under 2GB free, defined as the percentage of your app's active users with less than 2GB of device storage space remaining; and uninstalls on devices with under 2GB free, defined as the ratio of uninstalls on active devices with less than 2GB of storage remaining to uninstalls on all active devices.

That last metric is the one to read carefully, because it is a ratio rather than a rate. It compares uninstalls on storage-constrained devices to uninstalls overall. If your app is being deleted disproportionately by users who are short of space, that shows up here and almost nowhere else, and it is the single cleanest signal that your build is competing for room rather than for attention.

The peers comparison deserves one caution. It tells you where you sit in a distribution, not where you should sit. A photo editor that ships offline models will lose to a peer set of thin clients on every size chart and still be the right product. Use the comparison to spot outliers you cannot explain, not as a target to converge on.

Because Play measures compressed download size per device configuration, not the size of the artefact your build produced. Teams routinely optimise against the wrong figure for weeks, and the gap between the two is often large enough to change the conclusion entirely.

Play Console Help is unambiguous about the basis of measurement: all Google Play size limits are based on the compressed download size, as calculated by Play Console upon uploading your app bundle. The bundle you upload is not what any user downloads. Play generates optimised APKs for each device configuration, so a given device receives the base APK plus only the configuration APKs it needs — which is why the dashboard reports a size on a reference device and a size range across configurations rather than one number.

There are three separate quantities in play, and conflating them is the most common analytical error in this whole subject:

The third quantity has a documented multiplier that surprises people. Android's Play Asset Delivery guidance states that to successfully install or update an app, Android requires a certain amount of free disk space, and that install-time asset packs have the same requirement as the base APK, requiring at least two times the size of all the asset packs. A user who has exactly enough space for your download can still fail the install.

Practically, this means one thing for reporting: track compressed download size from Console, not bundle size from CI, and put the storage-constrained metrics beside it. If you are building growth dashboards, our note on funnel analytics for apps covers where install-stage metrics belong relative to everything downstream.

Apple publishes hard build limits but no equivalent statement linking size to installs, so the two platforms cannot be reasoned about the same way. This asymmetry catches teams who assume a documented Android behaviour has an undocumented iOS twin.

Apple's maximum build file sizes reference gives the ceilings. For a minimum deployment target of iOS 9.0 and later, the maximum uncompressed app size is 4GB and the maximum executable file size is 80MB, that second figure applying to the total of all __TEXT sections in the binary. watchOS apps are capped at 75MB uncompressed. App Clip ceilings depend on how the clip is invoked, which is the part usually dropped when this figure is quoted. Apple gives 100MB for iOS 17 and later only for App Clips invoked digitally — from a website or Spotlight — and only where a reliable internet connection is available. App Clips supporting physical invocations, such as App Clip Codes, QR codes and NFC tags, remain capped at 15MB on iOS 16 and later.

Note the basis: Apple's headline figure is uncompressed app size, where Google's is compressed download size. They are not the same measurement and should never be compared like for like in a single slide.

One more Apple detail worth flagging to engineering, because it changes long-term planning: Apple's on-demand resources size limits reference notes that on-demand resources has been deprecated on Apple platforms as of iOS 27, iPadOS 27 and tvOS 27. If your iOS size strategy is built on ODR, it now has an expiry date, and the equivalent Android mechanisms in Play Asset Delivery do not.

The practical conclusion is that on iOS you are managing against hard build ceilings and user patience, while on Android you are managing against documented thresholds with documented consequences. The launch-sequencing implications of differences like this are covered in how iOS and Android launches actually differ.

In almost every audit we run, the download size is dominated by resources and native libraries rather than by application code. Engineers instinctively look at their own code first, which is the least productive place to start.

Android's reduce-app-size guide organises its advice along the same lines, with sections on understanding the APK structure, reducing resource count and size, reducing native and Java code, and maintaining lean APKs. The ordering is not accidental — resources come before code because that is usually where the mass sits.

What we look for, in the order we look for it:

• Uncompressed or duplicated image assets. The same illustration shipped at several densities, plus a PNG that should have been a vector, plus a second copy nobody removed when a screen was redesigned.
• Bundled media and fonts. Onboarding videos, sound effects, and full font families where two weights are used. These are typically the largest single files in the bundle and the easiest to move to a download.
• Native libraries for architectures you do not serve. App bundles handle this per configuration when splits are enabled, which is exactly why enabling them is the first recommendation rather than an optimisation.
• SDKs carried for one feature. An analytics or ads SDK pulled in for a single screen, still linked long after the screen was retired. Our review of analytics tooling choices has more on auditing what you actually still use.
• Unshrunk code and resources. Shipping without shrinking is a decision, usually an accidental one made once during a debugging session and never revisited.

Do not guess at the split. Play Console's App bundle explorer reports what is actually delivered per configuration, and the ranking it produces is frequently different from the ranking the team predicted in the planning meeting. In our portfolio the biggest single line item has been a bundled media asset more often than anything else, and it is almost never the thing engineering nominated first.

You move weight out of the initial download rather than deleting it, which is precisely what Play's delivery mechanisms exist to do. The product keeps every feature; the first-time user simply does not pay for the ones they have not reached yet.

The Play Feature Delivery documentation sets out the modes and, usefully, the reasoning. Its worked example is a marketplace app where only a fifth of users ever post an item for sale, and its recommendation is to make the selling flow an on-demand download so the majority never carry it.

Sequence matters here. Splits and shrinking are configuration changes measurable in a day. Modularisation is an architectural project measurable in sprints. Do the first two, re-read the Console number, and only then decide whether the third is justified — which is the same discipline we apply to every ASO engagement, where the cheap structural fixes are exhausted before anything expensive is proposed.

Most of the time. Size is a real and documented factor, but it is a floor condition rather than a growth lever, and teams reach for it because it is measurable and controllable rather than because the evidence points there.

Size is probably not your bottleneck when your download size is comfortably below 200MB, when the storage-constrained uninstall ratio in Console is unremarkable, when you sit mid-pack against peers, and when your store listing conversion rate is where the funnel is actually leaking. In that configuration a size project buys you a smaller number on a dashboard and nothing else.

The diagnostic order we use, before anyone opens the build configuration:

• Is store listing conversion the constraint? Icon, screenshots and the first lines of the description decide far more installs than megabytes do. Start with store listing conversion.
• Is technical quality the constraint? Crashes and ANRs suppress distribution and ratings in documented ways, and they hit harder than size.
• Is the traffic wrong? If the users arriving were never a fit, no amount of trimming changes the outcome.
• Is retention the constraint? An app deleted in week one has a retention problem regardless of what it weighed.

Size moves to the top of that list under specific conditions: you are above 200MB and therefore triggering the mobile-data dialog, your storage-constrained uninstall ratio is elevated, you are an obvious outlier against peers, or your growth depends on markets where data cost and device storage are binding constraints. Those are evidence-backed reasons. "Our app feels heavy" is not.

If you want the evidence assembled before the engineering argument starts — Console size metrics, the storage-constrained uninstall ratio, peer position and the listing conversion picture in one place — that is the kind of diagnostic we run at the start of an engagement. Tell us what you are seeing and we will tell you whether the megabytes are the story, and we will say so plainly when they are not. You can see how those diagnoses tend to land in our case studies.