What can an over-the-air update actually change?

The non-native pieces. Expo's wording is that an app updates its own non-native pieces, such as JS, styling and images, over the air. Its own list of what updates are for covers fixing a bug or crash in JavaScript code, updating copy, translations, UI styling or screen layouts, rolling a change out to a percentage of users, publishing from CI, and testing with internal teams before a production release. The native half of the app, the half compiled into the binary, is not in that list and cannot be reached from an update.

What is a runtime version and why does it matter here?

It is the compatibility contract between a build and an update. Expo describes a build as two layers: a native layer compiled into the binary, and an update layer that is swappable with other compatible updates. The runtime version pins which updates may run on which builds, and the platform and runtime version of a build and an update have to match exactly. You can set it by hand or let a policy derive it. The expo-updates reference lists three policies on 21 October 2026: appVersion, nativeVersion and fingerprint. The fingerprint policy hashes the project and moves the runtime version whenever anything that may affect the native runtime changes, which is the setting that makes a mismatch unlikely at the cost of building more often.

Does Google Play allow JavaScript updates outside the store?

Google writes the exception down, which Apple does not. The Device and Network Abuse policy in Play Console Help, read on 21 October 2026, says an app distributed via Google Play may not modify, replace or update itself using any method other than Google Play's update mechanism, and may not download executable code such as dex, JAR or .so files from another source. It then says this restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs, and that apps with interpreted languages loaded at run time, naming JavaScript, Python and Lua, must not allow potential violations of Play policies. So the carve-out exists and it is conditional on the content of what you ship.

Do I still need release notes if the change went out as an update?

Your store listing only has release notes when you submit a binary, so an update on its own has no What is New field to fill in. The obligation lands on the next submission instead. Guideline 2.3.1(a) wants new features, functionality and product changes described with specificity in the Notes for Review, and guideline 2.3.12 wants them in the What is New text, with a generic description allowed for simple bug fixes, security updates and performance improvements. Expo's own FAQ puts the same point more bluntly: your updates need to follow the App Store and Play Store guidelines, and this usually means changes to your app's behaviour need to be reviewed.

What happens if I publish an update the build cannot run?

The build accepts it, because the runtime versions matched, and then the code calls into native modules that are not there. Expo's runtime versions page describes the outcome: expo-updates may detect an error and attempt to roll back to the previously working update. The page also lists what to do instead of hoping. Use the fingerprint policy so the runtime version moves on its own, bump the runtime version by hand whenever you install or update native code, roll the update out to a small percentage of users and watch the error rate on the EAS dashboard, or point a preview build at a different channel on the same runtime and test there first. A published update can also be rolled back or replaced by republishing an earlier one on top of it.

Articles · GuidesUpdated October 2026

An update can change the JavaScript inside a shipped build, and guideline 3.2.2 is not the rule you were told it was.

Q: Which guideline does govern changing an app after it has been reviewed?

Three of them, and they do different jobs. Guideline 2.5.2 is the code rule: apps should be self-contained in their bundles and may not download, install or execute code which introduces or changes features or functionality of the app. Guideline 2.3.1(a) is the disclosure rule: all new features, functionality and product changes must be described with specificity in the Notes for Review section of App Store Connect, generic descriptions will be rejected, and the change must be accessible for review. Guideline 2.3.12 is the release notes rule: new features and product changes go in the What is New text, while simple bug fixes, security updates and performance improvements may rely on a generic description. Read on 21 October 2026.

Q: What needs a new build instead of an update?

Expo marks four things as build work on its EAS Update page, read on 21 October 2026: a change to native code or native dependencies, a change to app permissions such as camera or location, an update to the Expo SDK version, and anything that requires a new app binary version. For those, you build and submit a new binary. The mechanism behind the rule is the runtime version, which is the property that guarantees an update is compatible with the native code already inside a build.

Q: How quickly does an update reach users?

On a launch, not mid-session, unless you ask for it in code. Expo's app config reference, read on 21 October 2026, gives checkAutomatically a default of ON_LOAD, so the library checks every time the app is loaded. The download happens in two phases: the manifest first, then any assets listed in it that the device does not already have. The fallbackToCacheTimeout setting defaults to 0 and has to sit between 0 and 300000 milliseconds, which is five minutes. At the default, the app launches on what it already has and applies the new update on the next launch. There is also a JavaScript API with checkForUpdateAsync and fetchUpdateAsync if you want to drive the timing yourself.

Over-the-air update rules sit on two separate lines, and only one of them is technical. The technical line is the runtime version: an update can replace the JavaScript, the styling and the images inside a build, and it cannot reach the native code that build was compiled from. The store line is review: a change that adds a feature has to be described for App Review whether it arrives in a binary or in a bundle. Guideline 3.2.2 governs neither. It is titled Unacceptable, it lives in the business section, and we searched the full text of the guidelines on 21 October 2026 to be sure. Most people meet this question a week after publishing to the App Store.

What follows is what 3.2.2 actually lists, the clause that does govern downloading code into a shipped app, what Expo documents as shippable in an update, and the one sentence in Expo's own FAQ that settles the question better than any guideline number does.

Start here

The short version

Two layers, and only the top one is swappable.

Expo describes a build as two layers. A native layer that is compiled into the binary, and an update layer that is swappable with other compatible updates. An over-the-air update replaces the second one. The runtime version is the property that guarantees the swap is safe, and Expo states the consequence plainly: any time native code is updated, you are required to make a new build before publishing an update.

The stores then ask a different question. Not can this bundle load, but should this change have been reviewed. Apple answers that in 2.5.2, 2.3.1(a) and 2.3.12. Google answers it inside its Device and Network Abuse policy, with an exception for interpreted code that Apple does not publish. Neither of them uses the phrase over the air, so searching for it is how people end up quoting the wrong clause.

Does guideline 3.2.2 say anything about changing an app after review?

It does not. Guideline 3.2.2 is titled Unacceptable and it is the second half of section 3.2, Other Business Model Issues. It contains ten clauses, numbered with roman numerals, and two of them, (ii) and (vi), have been emptied out and now read Intentionally omitted. The eight that remain cover an interface for displaying third-party apps that looks like the App Store, artificially increasing ad impressions, collecting charity funds inside the app, arbitrarily restricting who may use the app, manipulating a person's rank on other services, binary options and derivatives trading, personal loan terms with a maximum APR of 36 percent, and forcing people to rate or download things to unlock functionality.

That is the whole list. There is no clause about code arriving after approval, no clause about bundles, and no clause about updates. The number gets quoted anyway, and the reason is probably that 3.2.2 is short, memorable and sits next to the payment rules people argue about. If a rejection letter cites 3.2.2, read the roman numeral before you touch your update pipeline, because the clause will be about how you make money.

We also searched for the phrase itself. Over the air, with and without hyphens, appears zero times in the App Review Guidelines. The word interpreted appears zero times. JavaScript appears twice, once in 2.5.6 about web browsers having to use WebKit and WebKit JavaScript, and once in 4.7 about mini apps. Neither is about updating your own app. So there is no clause to point at, in either direction, and anyone who tells you Apple explicitly permits or explicitly bans over-the-air updates is reading something that is not on the page.

Apple, App Store Review Guidelines, Last Updated 16 October 2026, read 21 October 2026

What does Apple say about downloading code into a shipped app?

The clause is 2.5.2, under Software Requirements. Apps should be self-contained in their bundles, may not read or write data outside the designated container area, and may not download, install or execute code which introduces or changes features or functionality of the app, including other apps. One exception is named, and it is narrow: educational apps built to teach or test executable code may, in limited circumstances, download code, and they have to make that source completely viewable and editable by the user.

Read as written, that clause has no room in it for a JavaScript bundle that adds a feature. There is no second sentence about interpreted code, and we checked the full text rather than our memory of older versions. Guideline 4.7 does allow software that is not embedded in the binary, specifically HTML5 and JavaScript mini apps and mini games, streaming games, chatbots and plug-ins. It is not a route for your own code, and 4.7.2 is the reason: your app may not extend or expose native platform APIs or technologies to that software without prior permission from Apple. A React Native bundle exists to call native APIs.

The one place Apple writes the ban outright is the Mac App Store, where 2.4.5(iv) forbids downloading additional code or resources that add functionality or significantly change the app from what we see during the review process, and 2.4.5(vii) says apps must use the Mac App Store to distribute updates and that other update mechanisms are not allowed. That wording is Mac only. It is also the clearest statement Apple publishes of where the line sits, and the phrase significantly change the app from what we see during review is worth keeping in your head.

Google wrote its exception down instead. The Device and Network Abuse policy in Play Console Help, read on 21 October 2026, says an app distributed via Google Play may not modify, replace or update itself using any method other than Google Play's update mechanism, and may not download executable code such as dex, JAR or .so files from another source. Then it carves out code that runs in a virtual machine or an interpreter, and adds that apps with interpreted languages loaded at run time, naming JavaScript, Python and Lua, must not allow potential violations of Play policies. The store mechanism it protects is the one that takes your app bundle vs apk upload and turns it into installs.

Check yours

Update, or new build

Pick the change you are about to make. The verdict below is the technical one and the review one, because they do not always agree.

Goes out as an update

The code: Copy sits in the JavaScript bundle, which is the swappable layer. Expo lists updating copy, translations, UI styling and screen layouts as update work.

The paperwork: No review notes needed. Guideline 2.3.12 lets simple bug fixes rely on a generic What's New description.

Based on Expo's own update guidance and the App Store Review Guidelines, both read on 21 October 2026. It is a starting point, not a ruling on your app.

What can an update change, and what needs a new build?

Expo publishes the list, so there is no need to guess. An app updates its own non-native pieces, such as JS, styling and images. On the yes side: fix a bug or crash in JavaScript code and deploy in minutes, update copy, translations, UI styling or screen layouts, roll a change out to a percentage of users, publish from CI, and test with an internal team before a production release. On the no side, four entries: a change to native code or native dependencies, a change to app permissions such as camera or location, an update to the Expo SDK version, and anything that requires a new app binary version. For those, you build and submit.

The enforcement mechanism is the runtime version, and you choose how it is set. The expo-updates reference, read on 21 October 2026, documents three policies. The appVersion policy ties the runtime to your version string, which means a forgotten version bump produces a mismatch. The nativeVersion policy combines the version with the iOS build number or the Android version code. The fingerprint policy hashes the project and moves the runtime version whenever anything that may affect the native runtime changes, which Expo recommends if you want incompatible updates to be extremely unlikely, at the cost of building more often. You can also set a string by hand and own the problem yourself.

Get it wrong and the failure is quiet rather than loud. A build with runtime version 1.0.0 will accept any update that also says 1.0.0, so an update that was written against a native library the build does not contain loads and then calls into nothing. Expo says expo-updates may detect an error and attempt to roll back to the previously working update. The safeguards it documents are a gradual rollout to a small percentage of users with the error rate watched on the dashboard, a rollback, republishing an earlier update on top of the bad one, or a preview build on the same runtime pointed at a different channel.

Timing is the last part people get wrong. By default the library checks on every load, downloads the manifest, then downloads the assets in it that the device does not already have. The fallbackToCacheTimeout setting defaults to 0 and is capped at 300000 milliseconds, which is five minutes, so at the default the app starts on what it has and runs the new update on the next launch. Expo asks you to keep updates as small as possible for the same reason that your binary has app thinning and size limits. A new photo asset in a bundle is a download on someone's commute.

Expo, EAS Update, read 21 October 2026, Markdown export dated 22 July 2026

Where is the line between a content update and a new binary?

Expo answers it in one sentence in its own FAQ, and it is the most useful sentence on the subject anywhere. You need to follow the rules of the platforms and app stores you are building for, which means your updates need to follow the App Store and Play Store guidelines, including the content of the updates and how you use them, and this usually means changes to your app's behaviour need to be reviewed. The example Expo gives is a critical bug: get the fix out, then follow up with a submission that has the fix built in.

Apple's own split matches that, and it is in the metadata rules rather than the software rules. Guideline 2.3.12 says new features and product changes must be described clearly in the What's New text, while simple bug fixes, security updates and performance improvements may rely on a generic description. Guideline 2.3.1(a) says all new features, functionality and product changes must be described with specificity in the Notes for Review section of App Store Connect, that generic descriptions will be rejected, and that the change has to be accessible for review. Apple has therefore already told you which changes it considers reviewable. Use that list.

So the practical test is a sentence test. Write the change as you would write it in What's New. If the honest version is fixed a crash on the checkout screen, it is an update and nobody needs to read it. If the honest version names something the app now does, that is a product change, and a product change belongs in a binary with review notes attached. Two more places Apple applies the same idea: 2.2 says significant updates to a beta build should go to TestFlight App Review before you hand them to testers, and 2.3.11 says material changes such as changing business models mean restarting pre-order sales.

There is a quieter obligation in the other direction too. The opening paragraph of section 4 says that even after your app has been approved you should keep updating it, and that apps which stop working or offer a degraded experience may be removed from the App Store at any time. Over-the-air updates are a good answer to that, because a broken screen can be fixed the same afternoon. A rejected submission costs you a review cycle rather than a fee, and the yearly bills are a different question, worked out in cost to publish an app.

Apple, App Store Review Guidelines, sections 2.2, 2.3 and 2.5, read 21 October 2026

One question, two rulebooks, different amounts of ink

The question	Apple, App Review Guidelines	Google Play, Device and Network Abuse	Same answer on both
Is downloading code that changes features allowed?	No. Guideline 2.5.2 says apps may not download, install or execute code which introduces or changes features or functionality	No, with an exception written into the policy for code run in a virtual machine or an interpreter	No
Is there a carve-out for JavaScript?	None in 2.5.2. The only exception named is educational apps that teach executable code	Yes. Interpreted languages loaded at run time, and JavaScript, Python and Lua are named	No
Must the app update only through the store?	Written outright only for the Mac App Store, in 2.4.5(vii)	Yes, in the policy text itself	No
Do the words over the air appear in the rulebook?	No occurrences in the full text on 21 October 2026	The policy says modify, replace or update itself instead	Yes
Must a new feature be described for review?	Yes, with specificity, in the Notes for Review field. Guideline 2.3.1(a)	Interpreted code must not allow potential violations of Play policies	No

Both documents read on 21 October 2026. Apple's page carries a Last Updated date of 16 October 2026. Google's policy page carries no date of its own.

Where this lands if a builder generated your app

Nothing about either line changes because an agent wrote the code. Newly generates a real React Native and Expo project that you own, with two-way GitHub sync, so you get the same two layers as any other Expo app: a native layer in the binary and an update layer above it. It runs the app on cloud iOS and Android simulators while it builds, uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month and there is no free tier.

It does not submit to the App Store for you, and that is a guideline rather than a missing feature. Guideline 4.2.6 rejects apps created from a commercialized template or app generation service unless they are submitted directly by the provider of the app's content, which is you. The same logic applies to updates. You own the project and the signing identity, so whether you add expo-updates and run a channel for production is your decision to make, and the Notes for Review are in your handwriting either way.

The honest shape of the first month is worth knowing in advance. Early changes to a new app are mostly native-layer changes, so the update path will not help much yet. Adding a camera, a push token, a payment SDK or an SDK bump each means a build. The update path earns its keep later, once the app is in the store and the work turns into copy, layout and the bug that only shows up on someone else's phone.

Questions people ask about over-the-air update rules

No. Guideline 3.2.2 is titled Unacceptable and it sits inside 3.2 Other Business Model Issues. It is a list of ten clauses, and two of them, (ii) and (vi), read Intentionally omitted. The other eight are about store-like interfaces for third-party apps, artificially increasing ad impressions, collecting charity funds inside the app, restricting who may use the app, manipulating a user's rank on other services, binary options and derivatives trading, personal loan terms with a maximum APR of 36 percent, and forcing users to rate or download things. None of them mentions changing an app after review. We searched the full text of the App Review Guidelines on 21 October 2026, on the page that carries its own Last Updated date of 16 October 2026, and the phrase over the air does not appear in it at all, with or without hyphens.

Build it, then decide what ships without review

Set the runtime version policy on day one and the rest of this stops being a judgement call. Native work takes a build, copy and layout take an update, and anything you would brag about in What's New takes a submission.

Start building