Guide

React Native OTA Updates

An over-the-air update ships new JavaScript and assets to an app that is already installed, without going through app-store review. For a React Native app that means most bug fixes, copy changes, styling and logic can reach users in minutes instead of days. This page covers what that actually involves — what you can and cannot ship, how rollouts and rollbacks behave, where store policy sits, and how to set it up.

What an OTA update can and cannot replace

The dividing line is the native binary. Everything inside the JavaScript bundle and its assets can travel over the air. Anything that changes the compiled app cannot.
  • Can: screens, business logic, styles, images and other bundled assets
  • Cannot: a new native module, a new permission, an SDK bump, or an Info.plist change
  • Shipping JavaScript that calls a native API the installed binary lacks will crash the app — binary version targeting exists to prevent exactly that
  • OTA only applies to release builds; a debug build loads JavaScript from Metro and ignores the downloaded bundle

How the update cycle works

The mechanics are the same across every implementation worth using, and worth understanding before you pick one.
  • The app asks the server whether a newer bundle applies to its binary version and deployment
  • If one does, it downloads the bundle — usually straight from object storage rather than through the API
  • The bundle is verified against its published hash before anything is unpacked
  • It is swapped in on the next restart, and a build that never confirms it booted is reverted automatically

Staged rollouts

Shipping to 100% of your users at once means a bad bundle reaches everyone at once. A staged rollout releases to a slice first, so the blast radius of a mistake is small enough to survive. See the staged rollouts guide for the commands.
  • Release to a percentage, watch the failure rate, then widen
  • Bucketing should be deterministic per device and per release — otherwise a device flips between "update available" and "no update"
  • Each release should sample an independent slice, rather than always hitting the same unlucky users

Rollback: the part most implementations get wrong

If a bad bundle is already on devices, changing which release is "current" does not help those devices — they will not ask for something older than what they are running. The fix has to arrive as something newer.
  • A correct rollback republishes the last good bundle as a new mandatory release at 100%
  • The bad release is disabled at the same time so nothing new picks it up
  • Because the stored bundle is reused rather than rebuilt, this is immediate
  • Read the details in the rollback guide

Store policy

Both stores permit over-the-air updates of interpreted code within limits: the update must not change the app's core purpose or introduce features you did not disclose at review. Bug fixes, content and logic changes are ordinary and expected. Shipping what is effectively a different app is not. This is guidance, not legal advice — check the current App Store Review Guidelines and Google Play policy for your case.

Setting it up

The quickstart takes you from an account to a shipped bundle. From there, Expo and bare React Native each have their own setup guide, and CI/CD covers publishing from a pipeline.

Frequently asked questions

Are OTA updates allowed by the App Store?
Yes, within limits. Apple permits changes to interpreted code provided they do not change the app's primary purpose or add undisclosed functionality. Bug fixes and content updates are routine; shipping a materially different app is not.
How fast do users get an update?
Publishing takes seconds. Devices receive it on their next update check, and the new bundle applies on restart — or immediately, if you configure it that way.
What happens if a device downloads a broken bundle?
It is verified against its SHA-256 before being unpacked, so a corrupted download never runs. If a bundle installs but the app never confirms a successful boot, the device reverts to the previous one on its own.
Do I still need to ship to the store?
For anything native, yes — new modules, permissions, SDK upgrades. OTA updates reduce how often store releases are on the critical path for a fix, not to zero.
Does this work with the New Architecture?
Yes. The SDK is verified against release builds on both Android and iOS.

Keep reading

Ship a fix without waiting for review.

Free to start. Publish a bundle, stage it to a percentage of devices, and roll it back for everyone if it goes wrong.