What happened to App Center CodePush?
Microsoft retired Visual Studio App Center on March 31, 2025. The original microsoft/react-native-code-push repository was archived on May 20, 2025 and is read-only. The historical SDK and server source still exist, but the original hosted App Center delivery service is no longer the maintained default it once was.
Verify the timeline in Microsoft’s App Center retirement documentation and the archived React Native CodePush repository.
The realistic replacement paths
| Path | Best fit | Migration shape | Main trade-off |
|---|---|---|---|
| NitroPush | React Native or Expo teams wanting a modern native SDK, explicit release control, signing, and rollback. | Replace the SDK, wire a deployment key, ship a new store binary, and move CI to the NitroPush CLI. | Not a wire-compatible App Center endpoint swap. |
| EAS Update | Teams aligned with Expo and its runtime-version, channel, branch, and EAS workflow model. | Remove CodePush, install expo-updates, configure EAS Update, and submit a new binary. | Adopts Expo’s update model and MAU/bandwidth billing. |
| CodePush-compatible host | Teams prioritizing the smallest SDK and workflow change. | Usually swap the package or service endpoint and deployment credentials. | Compatibility and maintenance depend on the chosen fork/provider. |
| Self-hosted server | Organizations with strict infrastructure control and an operations team. | Operate API, database, storage, CDN, auth, observability, and SDK compatibility. | You own reliability, scaling, security patches, backups, and on-call response. |
Why teams evaluate NitroPush
Modern React Native and Expo integration
One JavaScript API with an Expo config plugin and documented bare-native hooks.
Health-confirmed rollback
An update is not trusted as healthy until the app reaches notifyAppReady().
Bundle signing
ECDSA P-256 signatures are produced with your private key and verified on-device.
Native lifecycle analytics
Observe update outcomes even when JavaScript fails before it can report.
Optional delta delivery
Serve a verified binary patch when it is compatible and meaningfully smaller.
Explicit release routing
Separate projects, environments, platforms, app versions, and rollout percentages.
Where EAS Update may be the better choice
EAS Update is a strong choice when an application already uses Expo’s build, workflow, preview, channel, and runtime-version model. Expo publishes extensive migration documentation, supports bare React Native integration, and provides adoption monitoring and rollout tools. NitroPush should not be selected merely to avoid Expo terminology if the wider EAS platform already fits the team.
Review the official CodePush-to-EAS migration guide and EAS Update introduction.
Where a CodePush-compatible host may be better
If preserving the exact legacy client behavior and deployment concepts is the overriding requirement, a maintained CodePush-compatible provider can reduce application-side migration work. Evaluate its support for current React Native versions, New Architecture, security updates, signing, rollouts, analytics, operational ownership, and the provider’s long-term maintenance model.
Migration questions to answer before choosing
- Which installed binary versions still point at the retired service?
- Does the replacement require a native SDK change and therefore a store release?
- How does it prevent a bundle from calling unavailable native APIs?
- Can the private signing key remain under your control?
- What proves that an installed bundle booted successfully?
- Can a release start at a small percentage and expand without rebuilding?
- Are analytics recorded if JavaScript crashes during startup?
- How are MAUs, bandwidth, storage, seats, and overages billed?
How to evaluate a CodePush replacement
React Native version and architecture support
An OTA client sits inside the native application and touches startup, bundle resolution, lifecycle events, and application restart behavior. Ask each provider which React Native releases it tests, whether it supports the New Architecture, and how quickly it validates new React Native and Expo releases. “React Native compatible” is not specific enough for a production dependency.
Native compatibility boundaries
The provider must prevent JavaScript built for a new native contract from reaching an older binary. Look for an explicit target such as a runtime version, target binary version, or app version—not a convention that depends entirely on release-engineer memory. Test both an allowed update and a deliberately incompatible one.
Rollback semantics
A dashboard rollback changes what future update checks receive. Device-side recovery addresses a different problem: an update already downloaded and activated but failed during startup. A credible replacement should explain both paths, when the previous bundle is retained, what counts as a healthy launch, and what happens offline.
Release integrity
Checksums detect corruption. Cryptographic signatures prove that an authorized private key produced the update. Confirm which key algorithm is used, where signing occurs, whether the service ever receives the private key, what the device verifies, and how key rotation affects older installed binaries.
Progressive delivery
Percentage rollout is valuable only when bucketing is stable and observable. Verify whether devices remain in a consistent cohort, whether a rollout can pause, how a release expands, and whether rollback affects only the current release or mutates release history.
Operational visibility
“Published” is not the same as downloaded, installed, activated, or healthy. Prefer a system that distinguishes those states and records failures outside JavaScript. If telemetry starts only after React renders, the most important failed-startup events may never arrive.
Artifact and bandwidth model
Compare full bundle delivery, asset reuse, compression, and binary patches separately. Ask what happens on the first OTA after a store release, when a device skips several releases, when the base hash is unknown, and when patch verification fails. A reliable delta system must keep a complete fallback.
Exit and ownership
Document how to export release metadata, rotate credentials, remove the SDK, or move to another provider. Self-hosting increases infrastructure control but does not automatically make a system portable; proprietary clients and manifests can still create migration work.
Alternative categories in more detail
EAS Update
Expo’s service uses the expo-updates runtime and organizes delivery around runtime versions, channels, and branches. It works for Expo projects and can be integrated into existing native React Native applications. It is strongest when teams also value Expo previews, builds, workflows, fingerprints, Orbit, and the surrounding EAS experience.
Maintained CodePush-compatible services
Providers such as Bitrise CodePush and other compatible hosts focus on preserving familiar CodePush deployments and client behavior. They can be attractive when reducing migration scope matters more than changing the update model. Verify the exact client package, endpoint change, current React Native coverage, signing implementation, support terms, and whether the provider requires a new native binary.
Independent React Native OTA platforms
Products including NitroPush, Stallion, Revopush, and other active vendors offer their own mix of SDKs, patch delivery, dashboards, analytics, and commercial models. Similar marketing terms can hide different semantics, so compare the device protocol and failure behavior rather than counting checkmarks.
Open-source and self-hosted projects
Hot Updater, CodePush server forks, and Expo Updates protocol implementations can be appropriate when a team is prepared to own databases, object storage, CDN behavior, authentication, signing, observability, backups, upgrades, and incident response. Include engineer time and operational risk in cost estimates; cloud infrastructure alone is not the total cost.
Build nothing and use store releases
OTA is not mandatory. Teams with infrequent releases, strict policy constraints, or no appetite for another production delivery system may prefer normal store releases plus remote configuration. The slower hotfix lane may be an acceptable trade for simpler operations.
A safe provider-selection proof of concept
- Create the same small React Native test application for every shortlisted provider.
- Ship a native build with a known embedded bundle and a versioned native method.
- Publish a compatible JavaScript update and record check, download, install, and activation behavior.
- Publish an incompatible update and verify it is never selected.
- Interrupt the network during manifest and bundle downloads.
- Attempt to install a payload with an invalid checksum and an invalid signature.
- Activate a bundle that fails before the health-confirmation point and verify device recovery.
- Roll out to a small stable cohort, restart the same devices, and verify cohort stability.
- Measure the full first OTA and later delta or reused-asset payloads independently.
- Document the provider-removal process before approving production use.
Common CodePush replacement questions
Can an existing CodePush app switch providers without a store release?
Only when the installed client can already communicate with the replacement endpoint and trust its configuration. Moving to a different native SDK such as NitroPush or expo-updates requires a new binary. Plan for users who delay that store update.
Can OTA update native code?
No. React Native OTA systems update JavaScript and compatible assets executed by the installed native runtime. New native modules, permissions, entitlements, or incompatible APIs require a native build.
Is self-hosting automatically safer?
No. It can improve control and data residency, but security then depends on your patching, key management, authentication, network configuration, backups, monitoring, and incident response.
Should every update install immediately?
Usually not. Normal updates can activate at a natural restart or resume boundary. Immediate installation is disruptive and should be reserved for tested cases where urgency outweighs session continuity.
Recommended next step
Inventory your existing CodePush deployments and native integration first. Then follow the CodePush-to-NitroPush migration guide in a staging binary. If you are deciding between update models, use the side-by-side CodePush vs EAS Update vs NitroPush comparison.