How over-the-air (OTA) updates work in React Native
A clear explanation of how CodePush-style over-the-air updates work in React Native — the update check, download, install-on-restart flow, and how rollback protects users.
React Native apps are mostly JavaScript running on top of a native shell. That split is what makes over-the-air (OTA) updates possible: you can replace the JavaScript bundle on a device without shipping a new native binary through the app store. Here's how the CodePush-style flow actually works.
The bundle is just a file
When you build a release, the packager produces a single JavaScript bundle plus assets. The native app loads that bundle at startup. An OTA update is simply a newer bundle that the app downloads and loads instead of the one baked into the binary.
The update lifecycle
- Check. On launch (or on a schedule), the client asks the server: "I'm running binary version X and bundle label Y — is there anything newer for my deployment key?"
- Match. The server checks the latest release for that deployment, confirms it targets the device's binary version, and applies rollout and targeting rules.
- Download. If there's a match, the client downloads the new bundle in the background — often a differential download of only what changed.
- Install on restart. The update is staged and applied on the next app restart, so the running session isn't disrupted.
- Confirm. After the app boots successfully on the new bundle, the client reports success. If it crashes before confirming, the client rolls back to the previous bundle automatically.
Why binary targeting matters
An OTA update can only safely run against the native code it was built for. If a JavaScript change calls a native module that only exists in binary 1.4.0, you must not serve it to a device still on 1.3.0. That's why every release carries a target binary range — get it wrong and either nothing applies, or worse, updated JS talks to native code that isn't there.
What you can and can't ship OTA
- Can: JavaScript logic, UI, copy, images and other assets, most bug fixes.
- Can't: new native modules, permission changes, anything requiring a native rebuild. Those still go through the store.
In practice the large majority of releases are JavaScript-only, which is why OTA is such a leverage point: most fixes reach users in minutes, not days.
Rollback is the safety net
The confirm-or-rollback step is what makes OTA safe to use aggressively. Because a bundle that crashes on first run is reverted automatically, a bad release is self-healing on the device — and a good service lets you pull it for everyone else instantly.
[Ship your first OTA update with Pulsar →](/codepush-alternative)