React Native CodePush Alternative: The OTA Move

Why are you looking for a CodePush alternative?

Almost certainly because CodePush is going away. Microsoft’s CodePush (via App Center) was the go-to for over-the-air React Native updates for years, but it has been retired, the repo is archived, and App Center’s CodePush service is being sunset, so every app that relied on it needs a new home for OTA updates. That is the real reason this search exists, and the honest answer is that the replacement is not a like-for-like drop-in; it is choosing a new OTA strategy that fits how your app is built.

The honest framing first: OTA updates let you ship JavaScript-layer fixes without an App Store review, and that is both their power and their boundary. They can update your JS bundle and assets; they cannot change native code, add a native module, or bump native dependencies, which still require a binary release. Any “CodePush alternative” that implies it can push native changes is misrepresenting what OTA is, and Apple’s rules (updates must not materially change the app’s purpose) bound what you should push regardless.

What are the alternatives, and which fits?

The choice depends mostly on whether you are on Expo:

Option	Best for	Note
EAS Update	Expo (and bare RN) apps	The natural successor; Expo’s official OTA
Self-hosted (expo-updates protocol)	Teams wanting to own the server	More control, more to run
Re.Pack / module-federation approaches	Advanced, modular delivery	Heavier; for specific architectures
App-version-gated config	Simple toggles without code push	Not true OTA, but covers many needs

For most teams, EAS Update is the answer: it is Expo’s official OTA service, works with the expo-updates library that is already the modern standard, and handles the channel-and-rollout model CodePush users expect. A team that wants to own the infrastructure can self-host the expo-updates protocol. And a surprising number of “I need code push” needs are actually “I need to toggle a feature or fix a config remotely,” which a remote-config approach solves without shipping new code at all, the same config-driven control as a force-update gate.

What does shipping OTA responsibly require?

Restraint and honest update etiquette, because pushing code straight to users skips the review safety net. The disciplines: staged rollouts (release to a small percentage first, watch for crashes, then widen, never 100% blind), a kill switch or rollback (a bad OTA update must be revertable fast, the whole point of OTA cuts both ways), and respecting the user’s session (do not force-restart mid-task to apply an update; apply on next launch or at a safe moment, the restart-etiquette every OTA build needs).

And the boundary must be honest: OTA is for JS-layer fixes and content, not for sneaking past App Review. Apple’s review guidelines permit OTA updates that do not materially change the app, and an app that ships a fundamentally different experience via OTA is courting rejection, so the responsible use is bug fixes, copy changes, and incremental tweaks, with anything native or substantial going through a real release. This is the same don’t-abuse-the-mechanism discipline as any update or force-refresh flow.

What completes the migration off CodePush?

The move and the model. Migrating means swapping the CodePush SDK for expo-updates / EAS Update (or your chosen path), re-creating your channels (production, staging) in the new system, and re-establishing the rollout process, with an agent handling the mechanical SDK swap and config. And keeping the mental model straight: a release pipeline now has two lanes, binary releases (App Store, for native and major changes) and OTA updates (for JS fixes between them), and knowing which lane a given change belongs in is the discipline that keeps OTA safe.

The screens are unaffected by the OTA mechanism, that is the point, so a free VP0 design is the same starting point, and the update strategy is the delivery layer beneath, chosen to fit whether you are on Expo and how much infrastructure you want to own.

Key takeaways: a CodePush alternative

• CodePush is retired: the repo is archived and App Center’s service is sunsetting, which is why the search exists; plan a real migration.
• EAS Update is the natural successor: Expo’s official OTA via expo-updates, for Expo and bare RN, with self-hosting for teams that want control.
• OTA is JS-layer only: it ships bundle and asset fixes without review; it cannot change native code, which still needs a binary release.
• Ship OTA responsibly: staged rollouts, a fast rollback/kill switch, and restart etiquette that does not interrupt the user mid-task.
• Two lanes in the pipeline: binary releases for native and major changes, OTA for JS fixes between them; know which lane each change belongs in.

Frequently asked questions

What is the best CodePush alternative for React Native? EAS Update for most teams: it is Expo’s official over-the-air service via the expo-updates library, works for Expo and bare React Native, and handles the channels and staged rollouts CodePush users expect. Teams wanting to own the server can self-host the expo-updates protocol, and many “code push” needs are actually remote-config toggles. A free VP0 design is the same starting point throughout.

Why do I need a CodePush alternative? Because CodePush is retired: Microsoft archived the repository and is sunsetting the App Center CodePush service, so apps relying on it must move to a new OTA solution. The replacement is not a like-for-like drop-in but a choice of OTA strategy, with EAS Update the natural successor for most React Native apps.

Can OTA updates change native code? No: over-the-air updates ship JavaScript-bundle and asset changes only, so they cannot change native code, add a native module, or bump native dependencies, all of which require a binary App Store release. Any alternative implying it can push native changes is misrepresenting what OTA is.

How do I ship OTA updates responsibly? With staged rollouts (release to a small percentage, watch for crashes, then widen), a fast rollback or kill switch for a bad update, and restart etiquette that applies updates on next launch or at a safe moment rather than interrupting the user mid-task. OTA skips the review safety net, so the rollout discipline replaces it.

Is it allowed to update an app over the air on iOS? Yes, within limits: Apple permits OTA updates that do not materially change the app’s purpose, so bug fixes, copy changes, and incremental tweaks are fine, but shipping a fundamentally different experience via OTA courts rejection. Keep native and substantial changes in real binary releases and use OTA for JS-layer fixes between them.