Is shipping over-the-air JavaScript updates against App Store rules?

This is the single most common objection developers raise before adopting any over-the-air update tool: will pushing new JavaScript to a shipped app get it rejected or pulled? The short answer is: it depends on what the update does and how the store applies its policies. React Native OTA is not a blanket exemption on either store. The long answer is worth understanding, because the relevant boundary is functional, not merely technical.

This is a practical explainer, not legal advice. Store policies change; always check the current text before you rely on it.

What Apple actually says

Two provisions matter. App Store Review Guideline 2.5.2 says apps should not download, install, or execute code that introduces or changes features or functionality. Read alone, that sounds restrictive for OTA. Separately, the Apple Developer Program License Agreementaddresses interpreted code in section 3.3.1(B): it may be downloaded only when it meets conditions including that it:

• does not change the primary purpose of the app by adding features inconsistent with its intended, advertised, and reviewed purpose;
• does not create a store or storefront for other code or apps; and
• does not bypass signing, the sandbox, or other OS security features.

A React Native JavaScript bundle runs inside the submitted native shell and can use only native capabilities included in that installed build. That is an important technical boundary, but it is not a compliance guarantee: App Review can still assess the app's actual behavior, metadata, and the effect of a particular update. Keep OTA changes within the purpose users and reviewers saw, and treat material feature changes as a reason to seek a new review rather than relying on an OTA path.

What Google actually says

Google Play's Device and Network Abuse policysays apps may not update themselves outside Play and may not download executable code, while carving out code that runs in a virtual machine or interpreter with indirect Android API access. It also says runtime-loaded interpreted languages must not enable policy violations. A React Native bundle may be technically consistent with that distinction, but the policy is not a blanket approval of every remotely delivered change.

The scary cases, decoded

The fear usually traces back to a few enforcement stories that are routinely misremembered. The durable lesson is simpler than any one anecdote:

• Changing or bypassing the reviewed native implementation carries a different and higher risk than delivering a compatible JavaScript bundle.
• Letting unreviewed, arbitrary runtime code reshape what the app does is much harder to square with the app's submitted purpose than delivering a narrowly scoped, reviewed fix.

Where the line actually is

The test is functional, not binary. The current App Review Guidelinesand the program agreement both matter, and Apple retains review discretion. "Any remote code is bad" is too simple; so is "JavaScript OTA is always fine." Stay inside these guardrails:

• Do not use OTA to change your app's primary purpose or ship features it was not reviewed for.
• Do not build a code marketplace or storefront inside the app.
• Do not bypass OS security, the sandbox, or signing.
• Keep every native module in the submitted binary; OTA changes only JavaScript and assets.

Staying on the JavaScript side of the native boundary helps keep a change technically compatible; it does not decide compliance by itself. That boundary still determines what you can and can't ship over the air. Signing your bundles adds integrity on top of that, which we cover in the OTA security threat model.