What You Can and Can't Ship Over the Air Without Breaking Store Rules

Over-the-air updates are one of React Native's biggest advantages: a JavaScript fix can reach users in minutes instead of waiting for store review. They also raise a fair question that every product owner eventually asks: is this allowed? Couldn't someone use it to ship features Apple never reviewed?

The short answer is that both Apple and Google allow downloaded interpreted code like JavaScript, within limits. This guide explains the actual rules, what those limits mean in practice, and the habits that keep OTA updates firmly on the right side of them.

Key takeaways

• Apple's guideline 2.5.2 forbids downloading code that "introduces or changes features or functionality", and Apple's developer agreement allows interpreted code only when it doesn't change the app's primary purpose, create a storefront for other code, or bypass security.
• Google Play forbids apps updating themselves outside Google Play, with an exception for code running in an interpreter or virtual machine, such as JavaScript.
• Safe: bug fixes, copy and layout changes, small improvements within the reviewed purpose of the app.
• Risky or forbidden: turning the app into something different, hiding features from review, or bypassing in-app purchase rules over the air.
• Native changes can't ship over the air anyway. New permissions, native modules and SDK upgrades need a store build.

What Apple's rules say

App Review Guideline 2.5.2: "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps."

The Apple Developer Program License Agreement (section 3.3.1(B) in the current version) carves out interpreted code: it may be downloaded only if it doesn't change the app's primary purpose by providing features inconsistent with its intended and advertised purpose, doesn't create a store or storefront for other code or apps, and doesn't bypass signing, sandbox or other security features.

Read together, the line is clear enough: updating your JavaScript to fix and improve the app you shipped is the normal, intended use. Using OTA to deliver an app that's materially different from what was reviewed is not.

What Google Play's rules say

Google Play's Device and Network Abuse policy says an app may not modify, replace or update itself using any method other than Google Play's update mechanism, or download executable code such as DEX or native libraries from elsewhere. It explicitly excludes code that runs in a virtual machine or interpreter with indirect access to Android APIs, such as JavaScript. React Native's JavaScript bundle falls into that exception, while native code does not.

The practical line

The grey zone is new features. A new screen that fits naturally within the app's reviewed purpose is how many teams use OTA every week. A major new capability, a new business model or anything you wouldn't want App Review to discover later is better shipped through a store release, where it gets reviewed and listed in your release notes.

What can't go over the air at all

Even if the rules allowed it, these changes physically require a new build:

• New or upgraded native modules and SDKs.
• New permissions and purpose strings, Info.plist or Android manifest changes.
• Expo SDK and React Native version upgrades.
• App icon, splash screen, app name and bundle identifier.
• Native configuration such as push entitlements or associated domains.

EAS Update's runtime versions enforce part of this automatically: updates only reach builds with matching native code.

From the field: OTA hotfixes with EAS Update sit alongside store review, phased rollouts and crash triage in the release path I own. In practice, the rule I'd give any team is simple: OTA is for fixing and polishing the app you shipped; anything you'd want a reviewer or a user to notice belongs in a store release.

Habits that keep you safe

1. Use OTA for fixes and small improvements, and ship meaningful new features through the stores with release notes.
2. Never hide functionality from review with remote flags that stay off until approval. If it's in the build, show it to the reviewer.
3. Keep payments consistent with your store review. Don't use OTA to change how digital goods are sold.
4. Roll out OTA updates gradually and watch crash reports, exactly as you would a store release.
5. Keep a record of what each OTA update changed, in case you ever need to explain it.

A note on CodePush

Many older React Native apps used Microsoft's CodePush through App Center for OTA updates. Microsoft retired App Center in 2025, so those apps need a new OTA setup. EAS Update is the most common replacement, and the same store rules apply whichever service delivers the update.

FAQ

Are over-the-air updates allowed on the App Store?

Yes, within limits. Apple allows downloaded interpreted code such as JavaScript as long as it doesn't change the app's primary purpose, create a storefront for other code or bypass security. Fixes and improvements to the reviewed app are the intended use; changing what the app is isn't.

Does Google Play allow React Native OTA updates?

Yes. Google Play forbids apps from updating themselves outside Google Play, but excludes code running in an interpreter or virtual machine, such as JavaScript. Native code can't be downloaded and must ship through a Play Store update.

Can I add a new feature with an OTA update?

Small features that fit naturally within the app's reviewed purpose are common and generally accepted. Major new capabilities, business-model changes or anything that would change how a reviewer sees the app should go through a store release.

What happens if Apple thinks I misused OTA updates?

Apple can reject future updates or, for serious or repeated cases such as hidden features, remove the app or the developer account. Using OTA for fixes and improvements within the reviewed purpose, and showing reviewers everything in the build, avoids that risk.

Next steps

If you want over-the-air updates set up with clear rules for what goes OTA and what goes through the stores, I can configure the pipeline and the process together. Get in touch, or see my services.

Sources

• App Review Guidelines (2.3.1, 2.5.2, 3.1.1), Apple
• Apple Developer Program License Agreement, Apple
• Device and Network Abuse policy, Google Play Console Help
• EAS Update introduction, Expo
• App Center retirement, Microsoft Learn