iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
React Native over-the-air (OTA) updates are one stage of a release pipeline—not a way to replace every native app release. An OTA service can deliver JavaScript and asset changes only when the installed app already contains a compatible update client. A reliable process also needs compatibility rules, a tested path to production, controlled rollout, monitoring, and a recovery plan. If a change requires native code or cannot be delivered under the platform’s rules, ship a new native build instead.
What React Native OTA updates can—and cannot—deliver
An OTA update lets a compatible installed app fetch JavaScript and assets from an update service. The app’s native binary must already include a client that knows how to find, validate, and apply those updates. With EAS Update, that client is expo-updates. Expo documents integration for existing React Native projects, including bare projects that keep their native Android and iOS projects; adding the library still requires a new native build so the installed app contains it.
OTA is therefore suited to changes that fit the native capabilities and compatibility boundary of the installed binary. It does not change native code already shipped in that binary. If a change alters the JavaScript/native interface, adds or changes native functionality, or otherwise requires new native code, the pipeline needs a new native build and the appropriate store or distribution release.
How a production OTA pipeline works
1. Build the native app with an update client
Configure the app binary with the update client, update-service configuration, and compatibility information. The client is part of the installed app; publishing an update cannot retroactively install it into binaries that lack it. For EAS Update, Expo’s documented approach uses expo-updates. Other implementations need their own compatible client and service configuration.
#1 Best Overall
2. Define which binaries an update may reach
In EAS Update, an update targets a platform and a runtime version, and both must match the installed build. Android and iOS are distinct targets. The runtime version represents the boundary between the JavaScript bundle and the native interface it expects. When a native change alters that interface, use a new runtime compatibility set and ship a native build for it; do not route the old binary to JavaScript that expects a different interface.
Expo’s deployment guidance recommends the appVersion runtime-version policy by default. That is Expo’s guidance for EAS Update, not a universal runtime-version rule for every OTA system. Whatever policy you choose, document how native interface changes create a new compatibility boundary.
Rank #2
3. Route a tested candidate through staging
Release routing is part of the system, not an afterthought. In EAS Update, channels and branches help route updates to builds and organize release flows. A practical pipeline keeps preview or staging separate from production: publish a candidate to the intended test audience, verify it on representative installed builds, then promote or republish the tested artifact according to the project’s configuration.
Keep staging and production environment variables and signing configuration aligned enough that a candidate behaves as expected after promotion. In the usual EAS workflow, a build’s channel is embedded when the native binary is built. A later OTA publication cannot casually redirect that already-installed binary to a different channel, so choose and verify the build’s routing before distributing it.
Rank #3
4. Limit exposure while you learn
EAS Update supports percentage-based rollout for an individual update. Start with a limited audience, examine operational signals, and increase exposure in stages if they remain healthy. A percentage rollout limits how many users initially receive an update; it does not establish that the update is correct or compatible.
5. Monitor adoption and failures
Publication is not the end of the release. Expo’s production guidance calls for watching rollout adoption, crashes or fatal errors, trends, update size and bandwidth, and compatibility with persisted application state. Monitor the signals that matter for your app and have a way to distinguish an update-related regression from unrelated changes.
Rank #4
Persisted state deserves particular attention: a JavaScript bundle can match a binary’s runtime version yet still mishandle data written by an earlier app version. Test upgrades from realistic prior states, not only a fresh install, and plan how the new code behaves when it encounters older stored data.
Recommended Free Tools
6. Know how to recover
Before release, identify the recovery action and who can take it. For EAS Update, the deployment workflow includes rollback or revert options; know whether the chosen operation returns users to a prior published update or to the update embedded in the native binary. Recovery depends on the client, service, and release state, so verify the exact behavior for your setup rather than assuming every OTA system rolls back in the same way.
Apple policy is a release constraint, not a blanket OTA answer
Apple App Review Guideline 2.5.2 says apps may not download, install, or execute code that introduces or changes features or functionality, with a limited exception for certain educational apps using code to teach, develop, or test executable code under stated conditions. The guideline is not a blanket statement that all OTA updates are allowed or that all are prohibited. Whether a particular update is permitted depends on what it changes and the app’s distribution context.
Review the current guideline and applicable distribution rules for your app before relying on OTA delivery, especially for changes that could introduce or alter functionality. This is a platform-policy consideration, not legal advice. A team should not treat technical compatibility as proof of policy compliance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choosing an approach after CodePush
Microsoft announced that App Center would shut down on March 31, 2025. Expo’s August 2024 migration discussion described several paths: stop using OTA, use a standalone or self-hosted CodePush version, run a self-hosted service conforming to Expo’s Updates V1 Protocol, or use hosted EAS Update. Expo’s current bare React Native guidance says CodePush is retired and incompatible with React Native’s New Architecture, so it should not be treated as a supported default for new work.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →| Approach | What it means | What to verify |
|---|---|---|
| Stop using OTA | Deliver changes through native app releases instead of remote updates. | Whether the team’s release cadence and distribution process meet its needs. |
| Self-hosted CodePush version | Operate a standalone or self-hosted version rather than relying on the retired App Center service. | Current maintenance, React Native version and architecture compatibility, security, and operational ownership. Expo’s current guidance warns of incompatibility with the New Architecture. |
| Self-hosted Updates V1 Protocol service | Run a service conforming to Expo’s Updates V1 Protocol. | Native integration, compatibility behavior, signing and security, monitoring, rollout and rollback, and the burden of operating the service. |
| Hosted EAS Update | Use Expo’s hosted update service with the documented expo-updates integration, including for existing React Native projects. |
Runtime and platform targeting, routing, staged rollout and recovery behavior, and whether its operating model fits the team. |
This is a decision map, not a current feature or price ranking. Before choosing any hosted or self-hosted service, check its present maintenance status and support for your React Native version and architecture. Compare native integration, compatibility targeting, staging and promotion controls, health visibility, rollback behavior, signing and security, operational burden, and commercial terms.
A release checklist for each OTA publication
- Binary readiness: Confirm the intended installed builds include and are configured for the update client.
- Compatibility: Verify the target platform and runtime version against the builds that should receive the update.
- Artifact validation: Test the candidate on representative builds and with realistic persisted data.
- Routing: Confirm the build’s embedded channel and the intended branch or release route.
- Controlled exposure: Start with a limited rollout where supported and define the signals required before expansion.
- Recovery: Know how to stop or revert the rollout and whether recovery returns to a previous OTA update or the embedded update.
- Policy: Check the current platform rules for the specific functionality being delivered.
Expo engineering author Jacob Clausen wrote in an Expo production article dated February 18, 2026, that “Expo’s OTA update service (EAS Update) can get an update to your users in just minutes.” That speed makes a controlled release process more important, not less: compatibility, exposure, observation, and recovery need to be planned before publication.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
