Your app has several sizes, and the one you uploaded is the one nobody downloads.
The file you hand a store is not the file that lands on a phone, and both stores say so in their own documentation. On iOS your upload goes through app thinning, which cuts it into one variant per device, and the App Store product page then quotes the install size for whichever device is reading it. On Android the thing you upload cannot be installed at all: an app bundle is a publishing format, and Google Play builds the actual APKs from it. The number a Play customer sees is the download size for their own device. So the two stores show your customer two different quantities, measured at two different points in the pipeline, and neither of them is the number on your laptop. Every figure below comes from Apple's and Google's own documentation, read on 17 October 2026. If you are adding up the whole bill rather than the bytes, what it costs to publish an app has the fees.
What follows is which of these numbers is which, where each one is written down, and the single threshold both stores actually act on. Then the detail nobody warns you about. Your TestFlight build is larger than your App Store build, by Apple's own statement, so the first size you ever see for your own app is the wrong one.
See which number you are holdingThe short version
Upload size is an input. Download size and install size are the answers.
Three numbers, in the order they come into existence. The upload is the archive you send: an IPA on iOS, an app bundle on Android. Apple states that none of the binaries you create for debugging, or that you upload to App Store Connect, are suitable for measuring your app, because they hold files your users never receive, debug symbols for crash reporting among them. The download size is the compressed size that goes over the air, on cellular bandwidth or Wi-Fi. The install size is the disk space the app takes once it is unpacked. Download is always the smaller of the two.
Then the asymmetry that makes one app look like two. Apple puts the install size on your product page. Google Play shows the customer the download size. Nobody has done anything wrong. The two stores are quoting opposite ends of the same process, and if you compare an App Store listing against a Play listing you are comparing a zipped file against an unzipped one.
Why is the file you upload bigger than the app anyone downloads?
Because both stores take it apart and rebuild it per device. Apple calls this app thinning, and App Store Connect Help describes it as a process that creates variants of your app for different devices and operating system versions. It runs after you upload a build, not when you submit for review. Google calls its format an Android App Bundle, and the documentation is blunt about what that is: a publishing format that includes all your app's compiled code and resources, and defers APK generation and signing to Google Play. Play then generates and serves optimized APKs for each device configuration, so only the code and resources needed for a specific device get downloaded.
This has a consequence people hit before they read a single size number. The app bundle on your disk cannot be installed on a phone. It is not a bigger or smaller version of your app, it is the material Google Play builds your app out of. Expo says the same thing about its own default Android output in its build reference: that output is an Android App Bundle, the format is meant for distribution to the Play Store, and it cannot be installed directly on your device, which is why you have to ask the build for an APK when you want to install on a phone you are holding. Google also documents what happens if you try to assemble the pieces yourself: partial installs of sideloaded apps, meaning apps missing one or more required split APKs, fail on all Google certified devices and on anything running Android 10 or higher.
On the Apple side there is a second and stranger reason the upload is not a measurement. Apple says that none of the binaries you create for debugging, or that you upload from Xcode, are suitable for measuring your app's size: not the app bundle, not the archive, not the IPA. They contain resources and files that are not part of what users download, and Apple names debug symbols for crash reporting as the example. Then the size moves again, upward, after approval. App Store Connect Help states that when your app is approved for distribution it is encrypted with Digital Rights Management and recompressed, that the file size may be larger than the binary you uploaded, and that the exact final size for your app cannot be determined in advance.
So there is no single moment at which the number is settled. There is a figure you can estimate before you upload, a figure the store computes after you upload, a figure that changes when the store encrypts the binary, and a figure printed on a listing. Treating any one of them as the size of your app is where the confusion begins, and it is usually the largest one that gets quoted back at you.
Apple, App Store Connect Help, view builds and metadata, read 17 October 2026
Check yours
Which number are you holding?
Pick where the figure came from. Five of these are not the size your customer will see.
An .aab from the build
Nobody downloads this
An app bundle is a publishing format that defers APK generation and signing to Google Play. It cannot be installed on a phone at all. It is the heaviest file in the set and the least meaningful.
Every line here is Apple or Google describing its own pipeline, read on 17 October 2026.
Which number does each store show your customer?
Different ones, which is worth knowing before somebody tells you your app is twice the size of a competitor's. App Store Connect Help defines the two columns it prints for you. The install size is the amount of disk space the app consumes on the customer's device, and then it adds the sentence that matters here: the install size also appears on your app's product page in the Information section. The download size is the compressed size of the app that is downloaded over the air, using cellular bandwidth or Wi-Fi. The public figure on an App Store listing is therefore the larger of the two. Apple's reference on maximum build file sizes adds that it varies by the device viewing the page, showing the installation size for that specific device model, and that macOS is the exception, where the page shows a universal installation size.
Google Play shows the other one. Google Play Help tells customers to open the app, tap About this app or About this game, and scroll to the list of compatible active devices, which gives the compatibility status, the download size and the required OS. It also says that list only includes devices linked to their Google Account and active in the last 30 days. Two people can therefore see two different sizes for your app on the same afternoon, and both are correct, because they own different phones.
On your side of the glass each console has exactly one place to read it. In App Store Connect the path is the TestFlight tab, then the build, then Build Metadata, then App File Sizes under General Information, which prints a table of every variant with its install size and its download size. In Play Console the path is Monitor and improve, then Android vitals, then App size, which reports your download size on a reference device plus the range across all device configurations. Play Console Help notes that those are representative calculations based on your latest production release and the XXXHDPI ARMv8 device configuration, so it is one device standing in for a catalogue of thousands.
Before you have shipped to either store, Xcode will give you the same pair locally. Archive the app, export it with all compatible device variants chosen for app thinning, and the output folder holds one thinned IPA per variant alongside a file named App Thinning Size Report.txt. Apple's description of that report is the cleanest definition of the two numbers anywhere in its documentation: the uncompressed size is equivalent to the size of the installed app on the device, and the compressed size is the download size of your app. If you only ever learn one sentence from this page, learn that one.
Apple, App Store Connect Help, install size and download size per variant, read 17 October 2026
What is the real limit, and why does Google publish three of them?
Apple's ceilings are high and easy to state. Its reference on maximum build file sizes, read on 17 October 2026, gives a maximum uncompressed app size of 4 GB for iOS and iPadOS apps targeting iOS 9.0 and later, the same for tvOS and visionOS, 200 GB for macOS, and 75 MB for watchOS, which is the tight one. The maximum executable file size is 500 MB, counted as the total of all the TEXT sections in the binary. An app made of screens and a database will not come close to any of these.
The figure that actually bites on iOS is 200 MB. App Store Connect Help says that if any device variant exceeds the 200 MB over the air download limit, a yellow warning icon appears next to the build string in the Builds table and next to the variant size in the App File Sizes table, and that Apple emails you the same warning. Apple's guidance on reducing app size gives the customer side of it: the App Store limits the size of the apps people can install over a mobile connection, and if an app exceeds the limit they need to connect to a Wi-Fi network to install it.
Google's answer depends on which Google page you open, and we are not going to pretend otherwise. Reduce your app size, on Android Developers, last updated 16 October 2026, says Google Play enforces a compressed download size restriction of 200 MB for apps published with app bundles, that larger sizes are possible through Play Feature Delivery and Play Asset Delivery, and that apps published as signed APKs instead are restricted to 100 MB. About Android App Bundles, last updated 24 June 2026, says the total size of the compressed APKs required to install your app must be no more than 4 GB. Play Console Help gives a third shape again: 500 MB for the base module, 500 MB per feature module, 1.5 GB per asset pack, 4 GB cumulative for all modules and install-time asset packs, 30 GB for asset packs delivered on demand, and a total maximum compressed download size of 34 GB.
Those are three live Google pages, read on the same day, and they do not agree. We have not resolved which one governs, and we are not going to guess on a page somebody might build against. What all three permit, and what both stores stop warning about, is the same number: stay under 200 MB. Play Console Help supplies the customer facing reason. Above 200 MB, people on a mobile data connection get a non-blocking dialog when they install, telling them the app is large. Above 200 MB on iOS, Apple tells them to find Wi-Fi. Two companies, two mechanisms, one threshold, and it is nowhere near any of the hard ceilings above.
Android Developers, reduce your app size, last updated 16 October 2026, read 17 October 2026
Does a React Native and Expo project start out large?
It starts out carrying more architectures than any one phone needs, which is the honest version of the complaint. Google documents what sits inside an APK: a lib directory holding compiled code specific to the software layer of a processor, with a subdirectory for each platform type, named armeabi, armeabi-v7a, arm64-v8a, x86, x86_64 and mips. In a React Native and Expo project that directory is where the JavaScript engine and the native modules live, and there is one copy of all of it for every architecture the build targets. Add the compiled code, the resource table, your images and your JavaScript bundle, and the raw file weighs more than a list of your screens would suggest. If the weight is a deciding factor for you, Flutter against React Native compares the two on more than bytes.
The bundle format is the answer to that, and if you publish through Google Play it has already been applied without you asking. The customer receives the base APK plus the configuration APKs for their own architecture and screen density, not the whole set. A standalone APK is the opposite trade: one file that has to run on whatever installs it, so nothing is left behind. That is why a sideloaded build reads much larger than the Play download of the identical release, and it is the single most common reason somebody thinks their app is enormous when it is not.
Two engine level facts are worth knowing and not worth acting on this week. React Native uses Hermes by default and needs no configuration to enable it, and a release build compiles your JavaScript to Hermes bytecode at build time, which is a different artifact from the plain bundle a debug build loads. React Native's own documentation says that for many apps Hermes results in improved start-up time, decreased memory usage and smaller app size compared with JavaScriptCore. If you want the mechanics rather than the summary, Hermes and the new architecture goes through them.
And the floor moves between SDK versions, which is the other thing that makes a size look wrong. A jump after an upgrade is usually the platform, not your code, so the Expo SDK release notes are the first place to look when the number changes and your feature list did not. None of this needs a refactor on day one. The only question worth asking is whether you are anywhere near 200 MB, and for most apps built out of screens, forms and a database, the answer is no by a wide margin.
Android Developers, the structure of an APK, read 17 October 2026
One release, measured twice by two stores
| The question | App Store | Google Play | Same on both |
|---|---|---|---|
| What you upload | An IPA, through App Store Connect | An AAB, through Play Console | No |
| The store rebuilds it per device | Yes | Yes | Yes |
| The number on the public listing | Install size, for the viewing device | Download size, per linked device | No |
| Where you read both numbers | TestFlight, Build Metadata, App File Sizes | Android vitals, App size | No |
| Something changes at 200 MB | Yes | Yes | Yes |
| A documented hard ceiling | 4 GB uncompressed, 500 MB executable | Three different figures on three pages | No |
| Final size knowable before you ship | No | Calculated by Play Console on upload | No |
Where this lands if a builder generated your app
None of the arithmetic changes because an agent wrote the code. What changes is which file you are handed first, and it is the heaviest one. Newly is an AI app builder. You describe an app in plain English and it generates a real React Native and Expo project that you own, with two-way GitHub sync, so the lib directory and the JavaScript bundle described above are yours to open and inspect. It is $25 a month on effort-based credits, with no free plan.
It produces three artifacts, and two of them sit at the heavy end of the scale by design. It uploads iOS builds to TestFlight, which Apple states are larger than the App Store build of the same code. It publishes to Google Play internal testing, where the download arrives from Play rather than from your laptop, so that figure is the closest thing you get to a real one before launch. And it builds a standalone Android APK, which carries every configuration because it has to install anywhere. If the first size you see comes from the standalone APK or from a TestFlight install, you are reading the worst case rather than the shipping case.
One limit to be plain about. Newly does not submit to the App Store on your behalf, because Apple requires the app's content owner to submit. That means you are the one who opens App Store Connect, clicks through to App File Sizes, and reads the yellow 200 MB warning if there is one to read. No builder can take that reading off your hands, and no builder can tell you the final number in advance, because Apple says itself that the exact final size cannot be determined before the App Store has encrypted and recompressed the binary.
Questions people ask about app size
Because the file you are looking at is almost certainly not the file a customer downloads. Both stores take your upload apart and rebuild it per device. On iOS the upload goes through app thinning, which App Store Connect Help describes as a process that creates variants of your app for different devices and operating system versions. On Android the upload is an app bundle, which Android Developers describes as a publishing format that includes all your compiled code and resources and defers APK generation and signing to Google Play. The upload therefore contains every architecture and every density at once. A real download contains one of each.
Ship it first, then read the number that counts
Get a build into TestFlight and onto an internal testing track, then read App File Sizes and Android vitals. Those two tables are the only places either store tells you the truth about your app, and they take a minute each once a build exists.
Start building