The cellular download limit is 200 MB, and Apple keeps it on the build metadata page.
As of 21 October 2026, Apple documents a 200 MB over-the-air download limit for iPhone and iPad apps. The sentence is in App Store Connect Help, inside the section about reading the file sizes of an uploaded build. It is not on the page called Maximum build file sizes, which is where everybody looks, and it is not in the iPhone User Guide either. Go over it and nothing is rejected. You get a yellow warning icon in two places in App Store Connect and an email, and people on cellular have to find Wi-Fi before they can install your app. That is the whole mechanism. Most people meet it while publishing to the App Store.
What follows is where the figure lives, what it has been in the past, which of your four size numbers it is tested against, and what Apple does and does not say about the customer's side of it. Every figure below carries the date it was read.
Start hereThe short version
One number warns you, a different number stops you.
Apple publishes four size figures for an iPhone app and they do different jobs. 200 MB is a warning about how customers get the app. 4 GB uncompressed and 500 MB per executable are the ceilings a build has to stay under. 100 MB is the App Clip cap on iOS 17 and later. Confusing the first with the second is the usual mistake, and it sends people optimising for a threshold that nothing enforces at upload time.
The practical reading is simple. Under 200 MB and your app installs anywhere, on any connection. Over it and you have a commercial problem rather than a technical one, because a proportion of the people who tap Get are away from Wi-Fi at that moment and will not come back.
What is the cellular download limit Apple documents today?
200 MB, read on 21 October 2026. The sentence sits in App Store Connect Help, on the View builds and metadata page, under the heading about viewing the file sizes of a build. Apple writes that if any of the device variant sizes exceed 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 also sends you an email with this information. Apple help pages carry no last-updated stamp, so the read date is the only date available.
The figure has moved before. Apple's developer news post of 19 September 2017, titled Higher Limit for Over-the-Air Downloads, says the cellular download limit went up from 100 MB to 150 MB so that customers could download more apps from the App Store over their cellular network. That is the last change Apple announced in its news feed that turned up in a search of it. The step from 150 MB to 200 MB appears in the help documentation without a matching announcement. So the honest statement is that 200 MB is the figure Apple documents now, and that a figure which has already moved twice deserves a fresh look before you build a plan around it.
Where the number is absent is worth knowing too, because it explains why the internet disagrees with itself about this. App Store Connect Help has a reference page titled Maximum build file sizes. Read the same day, it lists 4 GB uncompressed and 500 MB per executable for iOS 9.0 and later, the App Clip caps, and the equivalents for macOS, tvOS, visionOS and watchOS. It says nothing at all about cellular or over-the-air downloads. Anyone who checks the page with the obvious title comes away with 4 GB and no warning threshold.
Apple, App Store Connect Help, View builds and metadata, read 21 October 2026
Check yours
Which limit are you actually near
Tick what is true of your build. Each answer names the Apple page the figure comes from, all read on 21 October 2026.
Nothing ticked. A small app hits none of these, and the only size number you ever read is the one on your product page.
What happens when a device variant goes over 200 MB?
Two things on your side, one thing on the customer's. On your side, App Store Connect puts a yellow warning icon next to the build string in the Builds table and next to the offending variant size in the App File Sizes table, and you can click the icon to read the full warning. Apple emails you the same thing, which matters because the icon is easy to miss if somebody else did the upload. Nothing about the build becomes invalid. It can still go to testers and still go to review.
On the customer's side, Apple's Xcode documentation is the page that answers it. Reducing your app's size explains that download speeds vary even with good coverage and that a data plan may cap high-speed data, so the App Store limits the size of the apps people can install over a mobile connection. Then the consequence, stated plainly: if an app's size exceeds the limit, users need to connect to a Wi-Fi network to install it. The same page tells you to keep your app well below the limit to maximise your possible install base and to minimise installation time.
What Apple does not do is describe the customer's screen. The iPhone User Guide for iOS 27 has a page called Change settings and restrictions in the App Store on iPhone. Read on 21 October 2026, it walks you to Settings, then Apps, then App Store, and lists the settings there: Location, Siri, Search, Cellular Data, App Downloads, App Updates, In-App Content, Video Autoplay, In-App Ratings and Reviews, Offload Unused Apps. Cellular Data is described as a switch for letting the App Store use cellular, and App Downloads as automatically installing apps you bought on your other devices. No megabyte figure appears on that page, and neither does any size prompt. The same is true of the guide's View or change cellular data settings page. So the behaviour you can cite with confidence is the developer-facing one: over the limit means Wi-Fi.
Fixing it is an upload, not an appeal. You trim the build, archive again, and send a new binary, which means a fresh build number under the same version string. If that distinction is fuzzy, the version vs build number rules are the thing to settle first, because App Store Connect rejects a repeat build number before it ever weighs the file.
Apple, Xcode documentation, Reducing your app's size, read 21 October 2026
Which size counts, the download or the install?
The download, compressed, per variant. App Store Connect Help gives both definitions in the same paragraph. The install size is the amount of disk space the app takes on the customer's device, and it is the number that shows up on your 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 200 MB warning is raised against device variant sizes, so the figure that decides your fate is the largest variant, not a mean across the range.
Variants exist because of app thinning. After you upload, Apple builds a separate copy of your app for different devices and operating system versions, and each copy carries only the assets and slices that copy needs. The table in App Store Connect has a row per variant with a device type, an install size and a download size. There is also a Universal row, which is the copy that runs everywhere and goes to volume purchases through Apple School Manager or Apple Business Manager, to mobile device management, and to older clients. Universal is normally the fattest row, so a build can sit comfortably under 200 MB on every real device and still show a warning.
Two numbers you cannot pin down in advance. Apple notes that an app approved for distribution is encrypted with Digital Rights Management and recompressed, that the result may be larger than the binary you uploaded, and that the exact final size cannot be determined ahead of time. A TestFlight build is also larger than an App Store build of the same code, because TestFlight carries extra data that the store copy drops. Neither gap is big, and both mean you should leave headroom rather than land on 199 MB and declare victory. The path to the real numbers is in the app sidebar: TestFlight, then the platform, then the build, then Build Metadata, then App File Sizes under General Information. Apple lists the required role as Account Holder, Admin, App Manager or Developer.
A separate trap is the word over-the-air, which does two jobs in this corner of the industry. Apple uses it for the store download itself. React Native and Expo teams use it for pushing a JavaScript bundle to an app that is already installed. The 200 MB figure has nothing to do with the second one, and the second one has its own constraints and its own store policy, which the over the air update rules cover properly.
How do you get a React Native build under 200 MB?
Measure first, and measure the right artefact. Apple is explicit that none of the binaries you make for debugging or upload will tell you the truth: not the APP bundle, not the XCARCHIVE, not the IPA you send to App Store Connect, because all three carry files customers never download, such as the DSYM files for crash reporting. During development the only accurate route is an app size report on your Mac. Archive the app, export it as Ad Hoc, Development or Enterprise, choose all compatible device variants for app thinning, sign it and export. The output folder contains a file called App Thinning Size Report.txt with a compressed and an uncompressed figure for every variant. Compressed is the download, uncompressed is the installed footprint.
That same export runs from the command line, which is the version worth wiring into a release script. Apple documents an xcodebuild invocation with an export options property list, and says to include the thinning key set to thin for all variants. Then you have a size number per build instead of a surprise after an upload. Once the app is on the store or in TestFlight, App Store Connect becomes the better measurement, because it reports the real variants and flags the ones over the limit.
For a typical generated React Native app the weight is rarely in the JavaScript. It is in what you bundled: full resolution images and video sitting in the project rather than on a server, fonts in several weights, a map or payments or video library pulled in for one screen, and localisation assets for languages nobody selected. Each native module you add arrives with its own compiled code, and compiled code is the part the 500 MB executable ceiling measures. The cheapest win is moving large media to a URL. After that, delete the native modules you stopped using and settle on one font family. Where media has to ship inside the app, Apple's Maximum build file sizes page points at Background Assets for hosting larger assets managed separately from the build, and its On-demand resources size limits page records that on-demand resources are deprecated as of iOS 27.
Apple, Xcode documentation, Reducing your app's size, read 21 October 2026
Four size figures Apple publishes, and one it does not
All five rows below were read on 21 October 2026. The last column is the one people get wrong, because only three of these figures can actually stop a build from being accepted.
| The figure | What it measures | Where Apple states it | Caps the build |
|---|---|---|---|
| 200 MB over the air | Per device variant, compressed download | App Store Connect Help, View builds and metadata | No |
| 4 GB uncompressed app | Whole app, iOS and iPadOS 9.0 and later | App Store Connect Help, Maximum build file sizes | Yes |
| 500 MB executable | Total of all __TEXT sections in the binary | App Store Connect Help, Maximum build file sizes | Yes |
| 100 MB App Clip | Main bundle per variant, iOS 17 and later | App Store Connect Help, Maximum build file sizes | Yes |
| No published figure | What the customer is told on the phone | Nothing on the iPhone User Guide App Store page | No |
Where this lands if a builder generated your app
The limit does not care who wrote the code. Apple measures the variants it builds from the binary you upload, and the warning arrives in the account that owns the app. What changes with a generated app is how early you can see the number, because the first real measurement needs a build, and a build needs signing and an upload.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can produce a standalone Android APK, with two-way GitHub sync so the project is never trapped in the tool. It does not submit to the App Store for you, because Apple requires the owner of the content to submit. It is $25 a month, with no free tier. For size, the useful consequence is the TestFlight upload: once a build is in App Store Connect you get the real variant table and the warning icon, which is the only honest measurement short of running an app size report yourself.
The habit worth forming is checking App File Sizes on the first TestFlight build rather than the last one, because the fixes get harder as the app grows. Size also has a cost side that nobody budgets for, since a large app burns more of a tester's data allowance and more of your bandwidth during a beta. The cost to publish an app covers the fees that are fixed, so you can see which parts of the bill you control.
Questions people ask about the iOS cellular download limit
200 MB. Apple states it in App Store Connect Help, on the View builds and metadata page, read on 21 October 2026: if any of the device variant sizes exceed 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. Apple also sends you an email with the same information. The figure is tested against the download size of each variant created by app thinning, not against the size of the project on your Mac.
Get a build uploaded, then read the real number
The variant table in App Store Connect settles this in a minute, and it costs one TestFlight upload to see. Everything before that is an estimate.
Start building