Your app is big because of assets and native code, not the JavaScript you wrote.
You reduce app size by cutting media, images, fonts and native libraries, and by letting each store split the download per device. In a React Native project the JavaScript bundle is rarely the problem. The numbers that matter are not the ones people quote either. Apple caps an iOS app at 4 GB uncompressed with an 80 MB limit on compiled code. Google Play caps the base module of an app bundle at 500MB. Almost nobody hits those. What people do hit is 200 MB, where both stores start telling users the download is large. Every figure below comes from Apple's and Google's own documentation, read on 10 October 2026. Size is also one of the few things on the app performance list that a user sees before they ever open your app.
What follows is what an app is actually made of, the real limits on each store, where the 200 MB line bites, and which changes pay for the effort in a React Native codebase. Then the part nobody expects: your store listing already shows a different number to every device.
Start hereThe short version
What actually makes an app big?
Google Play splits your download into five buckets, and the names are a decent map of any mobile app. Code and DEX, which is your compiled Java or Kotlin. Resources, meaning the resource table and everything in the res directory, so strings and images. Assets, the files in the assets directory such as sound and video. Native libraries, the compiled code that is not Java or Kotlin. Then Other.
In a React Native app, your JavaScript lands in Assets as one precompiled Hermes bytecode file. Your dependencies land in Native libraries, once per architecture. That is the shape of the problem: a single map or video SDK can outweigh every line of JavaScript in the project, and a folder of unoptimised PNGs can outweigh both. Cut in that order, and measure after each cut.
What are the real size limits on each store?
Apple publishes a table of maximum build file sizes, and it has two columns because two different things are capped. For iOS and iPadOS with a minimum deployment target of iOS 9.0 or later, the maximum uncompressed app size is 4 GB and the maximum executable file size is 80 MB, which Apple defines as the total of all __TEXT sections in the binary. The second number is the one that surprises people, because it limits compiled code rather than the whole download. watchOS is 75 MB for the whole app. tvOS and visionOS get 4 GB with a 500 MB executable. macOS gets 200 GB.
Google Play measures everything as compressed download size, worked out by Play Console the moment you upload a bundle. The base module is capped at 500MB, each feature module at 500MB, each asset pack at 1.5GB. All modules and install-time asset packs together cap at 4GB, asset packs delivered on-demand or fast-follow at 30GB, and a single published app at 34 GB in total. Two extra rules sit under the table: an app larger than 1GB must target a minimum SDK version of Android Lollipop, API level 21, or higher, and an app bundle can carry at most 100 asset packs.
One caution on Google numbers, because its own pages disagree. An older size reduction guide still describes a 200 MB restriction on apps published with app bundles. The Play Console article on size limits, which is the one titled after staying within them, gives the 500MB and 4GB figures above and puts 200 MB somewhere else entirely: at the point where users get warned. If you are anywhere near either number, read your own figure in Play Console rather than trusting a guide, including this one.
Apple, App Store Connect Help, maximum build file sizes, read 10 October 2026
Google, Play Console Help, Google Play app size limits, read 10 October 2026
Where does the 200 MB mobile data line bite?
This is the threshold people actually meet, and both stores land on the same figure from opposite directions. Google is explicit: if your app is above 200MB in size, users on a mobile data connection see a non-blocking dialog when installing from Google Play, telling them the app is large for their device. Nothing is refused. A sentence appears between the person and your app at the exact moment they decided to try it.
On iOS the same number is a setting the user owns rather than a rule you break. Apple's iPhone User Guide describes App Downloads under Settings and App Store, where someone chooses whether to be asked for permission for downloads over 200 MB or for every app. Apple prints the 200 MB figure in that guide, and uses the same three choices for Books downloads. There is no documented hard cap on an App Store download over cellular, so a 300 MB app still installs once the person taps through. Checked 10 October 2026.
Treat 200 MB as a design budget rather than a limit. It is the one number on this page that a real user experiences, it is identical on both stores, and it is reachable by accident: a handful of bundled videos and an unshrunk Android build will get you there without any single file looking suspicious. Google also says the quiet part out loud on the same page, recommending you keep your app as small and optimized as possible to help your install metrics, and noting that most developers should stay well below the published limits.
Google, Play Console Help, Google Play app size limits, read 10 October 2026
Does the Android App Bundle already do some of this for you?
Yes, and it is the largest single win on Android. Google Play generates and serves optimised APKs for each device configuration out of your bundle, so a phone downloads the one screen density, the one architecture and the one language set it needs. If you are still uploading what an APK is rather than a bundle, every device gets all of it, and you are held to the legacy ceiling of 100MB instead of starting at 500MB for the base module. New apps have had to publish as app bundles since August 2021.
What the bundle will not do is tidy up after you. It does not remove a dependency you stopped importing, shrink a 4 MB hero image or strip debug symbols from a native library. That is what R8 and resource shrinking are for, and they are off by default in an Expo release build. Expo exposes them through its build properties plugin as enableMinifyInReleaseBuilds and enableShrinkResourcesInReleaseBuilds, and its documentation says the second should be used in combination with the first. One related switch is already set correctly for you: Expo leaves legacy packaging off, which keeps native libraries compressed and makes updates smaller.
Read the result rather than assuming it. Play Console shows your download size per release under Monitor and improve, Android vitals, App size, with a breakdown by bundle version code across your last five releases, split into Code and DEX, Resources, Assets, Native libraries and Other. All of those figures are representative calculations for the XXXHDPI ARMv8 device configuration, or the nearest one your app supports, so they are a consistent yardstick rather than one user's download. Before uploading, bundletool estimates the same thing locally with a similar but not identical calculation.
Google, Play Console Help, Google Play app size limits, read 10 October 2026
What are the biggest wins in a React Native project?
Four things, in this order. Ship an Android app bundle, which is already the default output when building with EAS, so this is usually a win you have without knowing it. Keep Hermes, which React Native documents as the default engine needing no configuration, and which it says gives smaller app size along with improved start-up time and lower memory use next to JavaScriptCore. Turn on R8 and resource shrinking for release builds. Then audit assets, which is where the real weight is.
Assets reward attention because nothing about the app has to change. Convert images to WebP. Drop densities you do not support. Replace a bitmap with a shape or a vector where you can. Ship two font weights instead of five. Move bundled video out of the binary: Google Play has asset packs of up to 1.5GB each, and Apple has Background Assets, which it describes as a way for iOS, iPadOS, macOS, tvOS and visionOS apps to host larger assets managed separately from the build. Both keep weight off the first download, which is the one that decides whether a person waits.
Measure the JavaScript bundle last, because it is usually the smallest piece and the most tempting to optimise. Expo Atlas visualises a production bundle and shows which libraries own it, and it has to be run against a production export rather than a dev server, because development mode disables optimisations that production turns on. The same work pays off twice: a smaller bundle is also less to parse, which lands on startup time.
Apple, App Store Connect Help, maximum build file sizes, read 10 October 2026
Check yours
What is making your app big
Tick what is true of your project. The order below is roughly the order these pay off in a React Native app.
Nothing ticked. Then measure before you cut anything: the breakdown in Play Console tells you whether your weight is code, resources, assets or native libraries, and the answer decides which of these is worth an afternoon.
The same app, measured two different ways
| The question | App Store | Google Play | Same on both |
|---|---|---|---|
| The ceiling you can actually hit | 4 GB uncompressed, iOS 9.0 and later | 500MB base module, 4GB with install-time asset packs | No |
| Still shipping the older format | No equivalent, every iOS app is thinned | 100MB maximum APK size, legacy rule | No |
| A limit on compiled code alone | 80 MB for all __TEXT sections in the binary | None published separately from the download | No |
| Where the mobile data warning starts | A user setting, asks over 200 MB | Non-blocking dialog above 200MB | Yes |
| The format splits the download per device | Yes | Yes | Yes |
| Large assets can live outside the build | Background Assets | Asset packs, up to 1.5GB each | Yes |
| Where you read your own number | App Store Connect, file sizes of an uploaded build | Android vitals, App size | Yes |
The row that catches people is the listing itself. Apple says the size on your App Store product page varies depending on the device viewing it: the universal installation size on macOS, and the installation size for that specific device model everywhere else. An app using Apple-Hosted Background Assets shows an "Up to" size instead. So there is no single number to quote, on either store, and a screenshot of your own listing is not what a stranger sees.
Where this lands if a builder generated your app
Generated code gets no exemption from any of the above. The limits belong to the build, and on iOS you are still the one who presses submit, because App Store Review Guideline 4.2.6 rejects apps made from a commercialised template or app generation service unless the provider of the content submits them directly.
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, uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and keeps a two way GitHub sync so the code is yours to read. It costs $25 a month, with no free tier. For size, the useful part is what a generated project starts as: a plain Expo app with Hermes on, no media bundled, and the Android output already an app bundle. A new app from a prompt is small by default because there is nothing in it yet.
It grows the way any app grows. Ask for offline video, a mapping screen or a charting library and native code arrives with it. The honest limit: no builder audits your assets or decides that a 4 MB splash image should be 200 KB. Ask for the feature, then open the App size page after the next release and see what it cost you. That habit, release by release, is the whole discipline.
Questions people ask about reducing app size
For iOS and iPadOS apps with a minimum deployment target of iOS 9.0 or later, Apple's App Store Connect reference gives a maximum uncompressed app size of 4 GB and a maximum executable file size of 80 MB, which it defines as the total of all __TEXT sections in the binary. watchOS is 75 MB. tvOS and visionOS are 4 GB with a 500 MB executable. macOS is 200 GB. Apple also notes that iOS, iPadOS, macOS, tvOS and visionOS apps can use Background Assets to host larger assets that are managed separately from the build. Read on 10 October 2026.
Ship it small, then keep it small
Set 200 MB as the budget, check the number after every release, and spend the effort on assets and native libraries rather than on the JavaScript. That is the whole job.
Start building