React Native OTA Update Tools Compared (2026)

Microsoft retired the hosted App Center CodePush service on March 31, 2025, as described in its App Center retirement notice. Teams comparing CodePush alternatives for React Native in 2026 can choose Expo EAS Update, CodePush-compatible managed services, other managed OTA platforms, or self-hosted infrastructure.

This comparison is intended to help a team create a shortlist. It is not a ranking, and it does not assume that every product uses the same definition for a rollout, rollback, patch, active user, or successful install. Those details matter more than whether a feature appears in a pricing table.

The options below are representative rather than exhaustive. The comparison includes products with a documented React Native production path and enough public information to verify their integration and release-control model. Product behavior and plans were checked against public documentation on September 7, 2026. Verify current limits, platform support, and contract terms with each provider before making a production decision.

Disclosure: I am the founder of Bundle Drop, one of the products discussed below. Links point to first-party documentation so the comparison can be checked independently.

The short version

• If EAS already owns the release workflow, start with Expo EAS Update.
• If minimizing a CodePush migration matters most, start with Codemagic CodePush, AppsOnAir CodePush, or Revopush.
• If the team wants another managed SDK and promotion workflow, compare React Native Stallion and Bundle Drop against the exact controls it needs.
• If infrastructure ownership or customization is a requirement, evaluate Hot Updater or the standalone CodePush server.

The strongest fit depends on the workflow you already have and the responsibilities you want to own. If the first decision is managed versus self-hosted rather than a named product, start with Managed vs Self-Hosted OTA.

CodePush alternatives and React Native OTA tools compared

Option	Operating model	Integration and migration shape	Documented release controls	Pricing or ownership shape
Expo EAS Update	Managed service around the open-source Expo Updates client and protocol	Adopt expo-updates, EAS CLI, runtime versions, channels, and branches	Per-update or branch rollouts; rollback to a previous or embedded update	Hosted usage includes MAU and edge-bandwidth meters
Codemagic CodePush	Managed CodePush service within Codemagic	CodePush SDK, deployment keys, familiar Staging and Production deployments	Target binary versions, percentage rollout, promotion, and rollback	Choice of successful-install or fixed-MAU pricing
AppsOnAir CodePush	Managed CodePush-style service	CodePush-shaped CLI and release workflow	Target binary version, percentage rollout, rollback, and code signing	Check the current commercial plan with AppsOnAir
React Native Stallion	Managed OTA cloud, with self-hosting offered on a separate On-Premise plan	Adopt the Stallion SDK, CLI, dashboard, and promotion workflow	Percentage rollout, pause, rollback, adoption reporting, and plan-dependent patch delivery	Public plans combine MAU and bandwidth allowances
Revopush	Managed CodePush-compatible service	Existing CodePush-style deployments and SDK compatibility, with Revopush tooling	Percentage rollout, server and client rollback, signing, and release analytics	Public plans combine MAU and egress allowances
Hot Updater	Open-source, self-hosted, plugin-based stack	Adopt the Hot Updater client and configure database, storage, and related plugins	Stable percentage or custom cohorts, channels, rollback, bundle diffing, and archive fallback	Software plus the infrastructure and operational work the team owns
Standalone CodePush server	Archived, self-hosted CodePush server	Preserve the CodePush protocol and operate the server, storage, and delivery path	Classic deployments, target binary ranges, rollout, promotion, and rollback	Unsupported software plus infrastructure, maintenance, security, and on-call ownership
Bundle Drop	Managed OTA service for supported Expo and bare React Native workflows	Adopt the Bundle Drop SDK and CLI with explicit per-platform runtime versions and channels	Stable percentage cohorts, property targeting, newest-first fallthrough, dashboard rollback, and local crash protection	Capacity-oriented plans without an MAU meter

The table summarizes documented concepts, not semantic equivalence. For example, two products may both offer percentage rollout while using different identity, fallthrough, or recovery rules. Run a release through a test binary before treating any two controls as interchangeable.

Expo EAS Update

EAS Update is the hosted path around Expo's update client and protocol. It works with Expo projects and can be integrated into React Native Community CLI projects after Expo modules and the required Metro configuration are added. Expo's getting-started documentation covers both project shapes.

Compatibility is expressed through runtimeVersion. Hosted workflows add channels and branches, with per-update and branch rollouts for gradual exposure. Expo also documents rollback to a previous update or the embedded update. Its bundle diffing requires SDK 55 or later, is enabled by default from SDK 56, and keeps embedded-bundle baseline diffing experimental and opt-in at the time of this review.

This option fits especially well when a team already uses EAS Build and wants builds, credentials, and updates inside the same product family. Teams should still model how channels map to branches, how runtime versions are derived, and how MAU and bandwidth usage behave at their scale.

CodePush-compatible managed services

CodePush-compatible services reduce migration distance for applications already using deployment keys, target binary versions, and the CodePush client workflow. Compatibility is valuable, but it should be validated against the exact React Native versions, New Architecture configuration, signing requirements, and CI commands used by the application.

Codemagic CodePush

Codemagic documents the familiar split between iOS and Android applications, Staging and Production deployments, deployment keys, and the CodePush SDK. Its production controls include release promotion, target app versions, percentage rollout, and rollback.

It is a practical candidate for teams already using Codemagic CI/CD or teams that want a small conceptual change from App Center CodePush. Its public pricing documentation offers both successful-install and fixed-MAU approaches, so the appropriate comparison depends on release frequency and fleet activity.

AppsOnAir CodePush

AppsOnAir exposes a CodePush-style release CLI with target binary versions, percentage rollout, mandatory-release behavior, and rollback. Its CodePush FAQ also documents deployment metrics and code signing.

This path is worth evaluating when preserving the existing CodePush mental model is a priority. Confirm the current SDK compatibility matrix, support arrangement, hosting terms, and plan limits directly during evaluation.

Revopush

Revopush documents CodePush SDK compatibility, hosted deployments, New Architecture and Expo integration, rollout, rollback, signing, and CI/CD integrations. Its newer delivery model can build a diff against the bundle embedded in an IPA, APK, or AAB rather than requiring a previous OTA release as the only patch baseline; the Revopush 2.0 documentation explains that model.

It fits teams that want a CodePush-shaped migration and managed service while placing substantial weight on differential delivery and release analytics. Current public plans use MAU and egress allowances, which should be modeled using real bundle sizes and expected adoption.

React Native Stallion

Stallion uses its own SDK, CLI, dashboard, and release-promotion workflow. Its documentation covers percentage-based phased rollout, pause and rollback, release-adoption reporting, signing, and patch generation.

That makes it a candidate for teams that are comfortable changing the client integration in exchange for a managed workflow with built-in testing and promotion concepts. Its public pricing combines MAU and bandwidth allowances across hosted plans, with a separate On-Premise option. Stallion's current patch setup guide lists SDK 2.4 or later and a Pro or Enterprise plan as requirements.

Do not assume that a phased rollout behaves identically across providers. Stallion documents how it evaluates the latest and previous eligible release and how its user identifier affects cohort membership. Compare those rules with the release history your team expects to keep active.

Hot Updater and self-hosted CodePush

Hot Updater and the standalone CodePush server both give the application team infrastructure control, but they represent different kinds of ownership.

Hot Updater is a plugin-based open-source system. Teams choose and configure providers for the control plane and artifacts, integrate the client, and operate the resulting stack. Its current rollout documentation covers stable percentage and custom cohorts. During bundle diffing, the client verifies base, patch, and final-output hashes and can fall back to the complete archive; optional RSA-SHA256 signing authenticates delivered artifacts.

Microsoft created the standalone CodePush server to preserve the established model after App Center's retirement, then archived the repository in May 2025. It is read-only, provided as-is, and has no Microsoft support. Its familiar protocol may still matter to a large installed base, but the team owns the server, data stores, artifact delivery, security maintenance, monitoring, backups, and compatibility with mobile clients that cannot be upgraded on demand.

Self-hosting is a sound choice when infrastructure control, data location, or customization is a requirement and the platform team is prepared to own the complete release path. It is not automatically the lower-cost path once maintenance and incident response are included.

Bundle Drop

Bundle Drop uses explicit, per-platform runtime versions to separate native compatibility lanes. Managed publishing makes release eligibility a server decision. Within a matching project, channel, platform, and runtime lane, published releases are considered newest-first; a device excluded by property rules or its stable rollout bucket can fall through to an older eligible release.

Property targeting accepts typed values supplied by the application, such as a beta flag, subscription tier, or country. These values narrow delivery eligibility; they are not an authorization boundary. The exact OR matching behavior, stable install buckets, and fallthrough sequence are documented in How staged rollouts, targeting, and rollback fit together.

Delivery may use an optimized patch or a verified full bundle without changing which release is eligible. Dashboard rollback changes future selection, while native crash protection can return a device to a previously working bundle when a newly activated update repeatedly fails to become healthy. The integration guides cover installation, managed publishing, and rollback.

Bundle Drop is a reasonable shortlist candidate when a team wants these selection semantics, maintains Expo or bare React Native applications, or wants to avoid pricing tied directly to audience size. It is not the natural answer for a team committed to the Expo Updates protocol, for an organization that must self-host the service, or for an application that needs to retain its existing CodePush client without a native integration change.

How to choose without overfitting to a feature matrix

Start with the constraints that would make an option unsuitable:

1. Client and runtime compatibility. Confirm the exact React Native or Expo versions, JavaScript engine, old or New Architecture setup, and native entrypoints used by the production application.
2. Migration distance. Decide whether preserving CodePush concepts is important or whether adopting a new client, protocol, and runtime model is acceptable.
3. Release selection. Test channels, runtime matching, staged cohorts, targeting, promotion, pause, and the fallback behavior when a device does not qualify for the newest release.
4. Recovery. Separate server rollback from on-device protection after a bad bundle has already been activated. Test both with a deliberately failing release.
5. Artifact delivery. Measure the full first update as well as later patches. Verify integrity, interrupted downloads, missing baselines, and full-bundle fallback.
6. Observability. Confirm that downloads, installs, active bundle identity, failures, and rollback outcomes can be tied to one release.
7. Cost and ownership. Model MAU, successful installs, bandwidth, retained artifacts, seats, support, and self-hosted operating work using the application's actual release pattern.

For the end-to-end mechanics behind these questions, see React Native OTA Updates: How Production Delivery Works. It provides a provider-neutral test model for compatibility, delivery, activation, observation, and recovery.

A practical evaluation sequence

Choose two or three candidates, then use the same small test application and acceptance criteria for each:

1. Integrate the production client into iOS and Android release builds.
2. Publish a harmless JavaScript and asset change to an internal track.
3. Confirm exact native compatibility, artifact identity, and source-map handling.
4. Expand a partial rollout and verify that the same installations remain in the cohort.
5. Exclude a device from the newest release and observe the documented fallback behavior.
6. Interrupt a download, corrupt a test artifact if the setup permits it, and confirm the current bundle remains active.
7. Activate a deliberately failing update, exercise local recovery, then perform a server-side rollback.
8. Estimate a year of service or infrastructure cost using realistic release sizes, frequency, and audience growth.

The result should be a written operating decision, not only a vendor score. Record which system owns compatibility, which team owns incidents, what evidence allows a rollout to advance, and how a bad release is removed from both future selection and already-affected devices.

Common questions

What replaced Microsoft App Center CodePush?

There is no single Microsoft-hosted replacement. Current CodePush alternatives include hosted CodePush-compatible services, Expo EAS Update, managed platforms with their own clients, and self-hosted systems. The appropriate path depends on migration distance, release controls, and infrastructure ownership.

Does EAS Update work with bare React Native or React Native CLI?

Yes. Expo documents EAS Update integration for React Native Community CLI projects after Expo modules, Expo CLI and Metro configuration, and the required native entrypoint changes are added. It is not limited to applications created with Expo tooling.

Is there an open-source or self-hosted CodePush alternative?

Yes. Hot Updater is a current plugin-based self-hosted option. Expo's update client can also target a custom server implementing its protocol. Microsoft's standalone CodePush server remains available as archived, unsupported source for teams prepared to maintain it.

Which OTA tools support React Native's New Architecture and Hermes?

Several providers document support, but this should not be reduced to one universal checkmark. Validate the exact React Native or Expo version, Hermes build inputs, Bridgeless configuration, native entrypoints, and release build used by the application. Support boundaries change as React Native evolves.

Can a React Native OTA update change native code?

No. An OTA release can replace compatible JavaScript and assets that the installed binary already knows how to run. Native modules, permissions, entitlements, JavaScript-engine changes, and generated native configuration require a new binary. See When an OTA Update Isn't Enough for the detailed boundary.

How do React Native OTA services charge?

Current models include MAU, successful installs, bandwidth or egress, retained storage, plan capacity, enterprise contracts, and the infrastructure cost of self-hosting. Model the application's real update size, frequency, fleet activity, and retention rather than comparing only the entry price. Why We Don't Price by Monthly Active Users explains Bundle Drop's capacity-based pricing decision and its tradeoffs.