CodePush is dead. Here's what actually works for React Native OTA updates.

Microsoft announced App Center's retirement in April 2024. The service went dark on March 31, 2025. CodePush was bundled into App Center, so it died on the same day.

There was no successor. Microsoft pointed users at GitHub Actions for CI, App Insights for analytics, and a vague "consider alternatives" page for CodePush. Teams that built their release process around it had a year to migrate. Many didn't.

This post is what to do now. The options that exist, what they cost, what they require, and which one to pick based on what your app actually needs.

First: are your users still getting updates?

Before you read about migration, check whether you have a live problem. Open your app's AppDelegate.m (or AppDelegate.swift) and your MainApplication.java. Look for any reference to CodePush, CodePushUpdateManager, or an App Center deployment key.

If you find one, run this against the App Center API base URL:

You'll get a connection error or a 404. That's the dead endpoint. Every install of your app pointing at it has been quietly running the bundle it was last shipped with — for over a year now, depending on when you last released.

This is the silent failure mode of the migration. The app works. Crashes don't spike. Users don't email support. They just stop receiving the JavaScript fixes you push. The version on their phone is whatever was current when CodePush stopped responding.

What exactly died, and what didn't

The hosted CodePush service died. That's the bit Microsoft ran — the API, the CLI, the web dashboard, the rollout controls. All gone.

The React Native client SDK didn't die. react-native-code-push is still on npm. The source is still on GitHub under Microsoft's org, in archived mode. The Objective-C and Java code that fetches and swaps bundles still works. It just needs something to talk to.

The CodePush server source code didn't die either. Microsoft open-sourced it. There are at least two actively maintained forks: lisong/code-push-server and microsoft/code-push-server (archived, but the code is still readable). You can stand one up yourself.

The CodePush CLI died with the service it talked to. You'd need a fork or a new client built against your self-hosted server.

The real options in 2026

Four real paths. Pick one based on what your team actually needs.

Option 1: EAS Update (bare workflow)

EAS Update is Expo's hosted OTA service. It works in bare React Native apps — you don't have to adopt Expo's managed workflow.

What you do:

1. Install expo and expo-updates in your bare project. Yes, Expo in a non-Expo app — the modules can coexist.
2. Run npx expo install expo-updates and follow the expo-updates bare install docs. Native config edits: a few lines in Info.plist, AndroidManifest.xml, and your app's bridge setup.
3. Log into EAS, create a project, get an update channel.
4. Run eas update --branch production to publish a new JavaScript bundle.

The trade-off you're making: expo-updates is a real native module. It increases your app size by a few hundred KB. It adds a dependency on Expo's release cycle — when they bump expo-updates, you'll eventually need to follow. You're not adopting the managed workflow, but you are adopting a piece of the Expo platform.

For most teams this is fine. Expo maintains the library, the documentation is current, the rollout controls (channels, branches, runtime versions) are exactly what CodePush gave you.

Pricing as of 2026: free tier with 1,000 monthly active updates, then per-update pricing. Read the current page before committing — Expo has adjusted it several times.

What "runtime version" means and why it matters

EAS Update enforces a runtime version on every update. A bundle published for runtime 1.2.0 won't install on an app shipping runtime 1.1.0. This is how it prevents the classic OTA disaster: pushing a JS bundle that calls a native API the installed binary doesn't have.

You set the runtime version in app.json (or expo-updates config). Bump it every time you change native code. Forget to bump, and you can ship a JS update that bricks the previous binary on launch. Bump unnecessarily, and you split your audience.

CodePush had something similar with target binary version. The mechanism is the same. Get it right.

Option 2: Self-host an open-source server

The path for teams that can't use a hosted service. Compliance constraints, data residency requirements, an enterprise customer that needs everything in their VPC.

lisong/code-push-server is the most actively maintained fork. Node.js backend, MySQL or PostgreSQL, S3-compatible storage for bundles. It implements the CodePush API surface, so the existing react-native-code-push client works against it once you swap the endpoint.

What you sign up for:

• Initial setup: a few days. Stand up the server, configure storage, point a domain at it, swap the client's server URL via the CodePush options in your native config.
• Operational tail: indefinite. Monitor uptime. Build a rollback story. Document staged rollout procedures. Train someone besides you to operate it.
• SDK risk: react-native-code-push is archived. It won't get new features. If a future React Native version breaks it — say, a New Architecture change — nobody is publishing a fix.

Self-hosting makes sense when the alternative is "we can't use OTA at all." It doesn't make sense as a cost-saving move. The engineering time costs more than EAS Update for nearly every team.

Option 3: Smaller hosted services

A handful of hosted alternatives exist. The ones worth a serious look:

• hot-updater — open source, self-hostable on AWS/Cloudflare/Supabase. Active maintenance, growing user base. You're hosting it, but on your existing cloud, not a dedicated server.
• Pushy — Chinese-market origin, but works globally. Mature product, simpler pricing than EAS for small apps. Documentation translated but uneven.
• Microsoft's archived server, run by you — see Option 2.

Pick from this group only if you have a concrete reason EAS Update doesn't fit. The smaller the ecosystem, the more time you'll spend integrating versus shipping.

Option 4: Roll your own

A minimum viable OTA service is three things: a signed JavaScript bundle, an HTTPS endpoint that returns the current bundle's manifest, and a CDN that serves the bundle itself.

On the client side, React Native exposes the bundle loader. You can read the current bundle hash on app launch, fetch the manifest, compare, download the new bundle to disk, and reload. There are existing libraries that do most of this — react-native-bundle-fetcher-style packages, or you can write it against RCTBundleURLProvider directly.

The hard parts aren't the happy path. They're:

• Staged rollouts — pushing a bundle to 10% of users, watching crash rates, deciding whether to continue
• Mandatory vs optional updates — and how to enforce mandatory without bricking the app if the download fails
• Bundle integrity — signing, verifying, refusing to install a tampered bundle
• Targeting — runtime version, app version, geo, A/B test cohorts
• Rollback — reverting a bundle without requiring users to delete and reinstall
• Observability — knowing what bundle every user is running, in aggregate

Each of those is a few weeks of work. The full system is a quarter of an engineer-year for a year, then ongoing maintenance. EAS Update is a hosted product because OTA done well isn't a weekend project.

Apple and Google policy: what OTA updates can actually do

Apple's App Store Review Guideline 3.3.2 allows scripted content updates as long as the change "does not result in a binary that materially alters the purpose of the app." That's the legal language. The practical interpretation:

• Allowed: bug fixes, copy changes, layout adjustments, feature flag flips, A/B test variants, new screens built from primitives the binary already has
• Not allowed: new native modules, new permissions, new payment flows, new entitlements, anything that requires updating Info.plist or the entitlements file

Google Play has equivalent language in its Device and Network Abuse policy. Same shape, same limits.

The thing that gets apps pulled isn't the technical capability of OTA — it's shipping new functionality that should have gone through review. If your OTA channel becomes "the way we ship features," your next major release will get flagged. Use it for fixes and tuning. Ship features through the stores.

How to pick

Decision tree:

1. Are you bare React Native and not blocked by compliance? Use EAS Update. It's the path most teams should take.
2. Are you blocked by compliance (data residency, HIPAA, FedRAMP)? Self-host lisong/code-push-server or evaluate hot-updater on infrastructure you control.
3. Do you have a specific reason EAS doesn't work (pricing at huge scale, an enterprise customer with infrastructure mandates)? Look at hot-updater, then Pushy, then build.
4. Are you on Expo managed workflow? EAS Update is the default. There's no decision to make.

The wrong answer for almost everyone is "roll your own." It's the answer that feels engineering-pure and ends up being a multi-year side project that competes with shipping features.

Frequently Asked Questions