Checking a Build Against Store Size Limits and Cellular Caps
Shipping a mobile app means clearing gates that are measured in two different arithmetics. The store states its ceilings in plain decimal megabytes — a round 200 MB, a round 100 MB — and so does the size printed on your listing page. The tools that tell you how big the build actually is mostly count in powers of two and print mebibytes, often while still writing "MB" next to the number.
That gap is small, but it lands exactly where it hurts: a few percent below a hard ceiling. This page restates the store's megabyte figure as the mebibytes your tooling reports, so the comparison is honest before the upload rather than after the rejection.
MiB = MB ÷ 1.048576 — one megabyte is 0.95367431640625 MiB. Worked example: the 200 MB per-device download ceiling is 190.73 MiB. A build your analyzer calls "195 MB" is really 195 MiB, or about 204.5 decimal MB, and it is already over the line.Who Is Counting in Which Base
The store counts in decimal MB
Your build tools count in binary
ls -lh and du -h all divide by 1024 and then label the result "M". Read as decimal megabytes, every one of those numbers understates the real figure by roughly 4.86%.Download size is not install size
Putting a Size Ceiling Into Build-Tool Units
Enter the megabyte figure the store gave you
Type the cap, the listing size or the number a release manager quoted into the left field, which is already set to MB. A comma or a dot both work as the decimal mark, and any spaces pasted along with the value are ignored.
Compare the mebibyte result with your analyzer
The right-hand field fills in as you type, to as many as eight decimals. That is the figure to hold next to whatever your bundle analyzer or shell printed, because those tools were dividing by 1024 all along.
Copy the bare number into your size gate
The copy button beside each field puts the plain digits on the clipboard with no unit and no spacing attached, ready to paste into the threshold constant of a CI check that fails the pipeline when a build grows past budget. Ctrl+C inside a field does the same.
Go the other way with a measured build
Both fields are editable, so a mebibyte figure typed on the right returns the decimal megabytes the store would print. The swap button reverses the pair outright, and the searchable dropdown on either side reaches KiB for a single small module or GiB for a large asset pack.
App Bundle Sizes and the Ceilings They Have to Clear
Every row below is a decimal megabyte figure a mobile team runs into, restated in the mebibytes a build tool would report. Read the middle column as the target your analyzer output has to stay under.
| Store-side figure | Equivalent in MiB | Where it comes from |
|---|---|---|
| 50 MB | 47.68 MiB | A lean utility app's download on a mid-range handset |
| 100 MB | 95.37 MiB | The legacy APK-only download ceiling on Google Play |
| 150 MB | 143.05 MiB | The older bundle ceiling, still a common internal budget |
| 200 MB | 190.73 MiB | Current per-device compressed download cap; also where iOS asks before using cellular |
| 250 MB | 238.42 MiB | A mid-size game after density and ABI splits are applied |
| 300 MB | 286.10 MiB | Past the cap — needs asset or feature delivery to ship |
The 200 MB row is the one worth pinning to a wall. A team that budgets "190 MB" from the analyzer thinks it has 10 MB of slack; in the store's units that build is about 199.2 MB and the slack is under a megabyte. Working the ceiling backwards into MiB first turns an ambiguous budget into a number the tooling can actually enforce.
Type on whichever side your evidence is
A cap from the console goes in the left box; a size from the analyzer goes in the right one. Both directions are live, so you never have to remember which way the 1.048576 goes.
Clean numbers for a pipeline threshold
Copying gives the raw value with nothing attached, so a size-gate script or a release checklist gets a literal it can compare against without stripping units first.
Module and asset-pack scales in one list
The searchable unit lists on both sides carry KiB and GiB alongside MB and MiB, which covers a 40 KiB dynamic feature just as well as a multi-gigabyte download pack.
Unreleased build sizes stay on your machine
Sizes from an unannounced release are converted locally in the browser after the page loads, so nothing about an unshipped build leaves the device.
App Size and Download Questions
Why is the size on my store listing different from the artifact my build produced?
Because the listing describes a delivery, not your upload. The bundle you submit carries every screen density, every CPU architecture and every language; the store generates a slice for each device from it, so a user only ever pulls the resources their own hardware needs. On top of that the figure is compressed, and the console's estimate is deliberately conservative — real downloads often come in under it. Add the difference in counting base, and a build your tooling calls 180 MiB can appear on the listing as something noticeably different.
Which number does the 200 MB Google Play ceiling actually measure?
The largest compressed download any single device would receive from your bundle — not the size of the .aab file you uploaded, which can legitimately be several times bigger. Two further limits sit behind it: the cumulative compressed total one device may end up with, including on-demand modules and asset packs, is checked against 4 GB, and the whole published app has a much larger overall ceiling above that. In mebibytes the 200 MB gate is 190.73 MiB, which is the figure a build script should compare against.
Will iPhone users on cellular be blocked from installing if the app is over 200 MB?
Not blocked outright — that hard restriction was replaced years ago by a user setting whose default asks for confirmation once a download passes 200 MB. What matters for planning is that the check runs against the thinned, device-specific download rather than the size shown on the product page, so an app listed comfortably above the threshold can still install without a prompt on a phone whose slice comes in below it. The friction is a single tap, but in a paid-acquisition install flow taps cost conversions.
Does the ceiling include the space the app takes up once it is installed?
No. The gate is purely about the bytes transferred. Once installed, compressed resources are expanded, code is compiled ahead of time for the device, and the app starts writing caches and downloaded content of its own, so the on-device footprint routinely runs well above the download figure. Nobody rejects a release for that, but it is what users see in their storage settings when they go hunting for something to delete — which makes it worth tracking separately, in its own clearly labelled units, rather than assuming the store number covers it.
Should our internal size budget be written in MB or MiB?
Pick one, write the unit beside every number, and convert exactly once at the boundary. The pragmatic choice is to keep the budget in the units the gate uses — decimal MB — because that is what a rejection will quote back at you. Then translate it once into MiB, record that value (190.73 MiB for a 200 MB cap) as the threshold your analyzer output is checked against, and never let an unlabelled "MB" from a shell command into a release ticket again. A surprising number of size-budget arguments turn out to be unit arguments in disguise.
No comments yet. Be the first to comment!