Migrate React Native OTA from CodePush & App Center to Stallion

If your React Native app still uses CodePush, you're likely already thinking about what comes next.

Microsoft retired the hosted App Center CodePush service on March 31, 2025. Hosted App Center CodePush is no longer available. Teams that relied on Microsoft's hosted CodePush service now need to evaluate a compatible CodePush fork or move to another OTA platform.

React Native Stallion provides a managed OTA workflow for teams that want to keep shipping React Native JavaScript updates without operating their own OTA infrastructure.

This guide walks through the migration from CodePush to Stallion, what changes in your application, and how to publish and test your first OTA release.

Get Started Free →

View the CodePush Migration Documentation →

Why Move From App Center CodePush?

The important distinction is between CodePush as a technology and Microsoft's hosted App Center CodePush service.

Microsoft retired the hosted App Center service in 2025. If your application was using Microsoft's hosted CodePush infrastructure, those update services are no longer available.

Teams can continue with compatible CodePush forks or self-hosted implementations, but these become the team's responsibility to operate and maintain, including hosting, storage, networking, availability, monitoring, upgrades, and ongoing compatibility.

Stallion provides a managed alternative while keeping the basic React Native OTA workflow familiar.

Instead of operating the update infrastructure yourself, you can use Stallion's:

• React Native SDK for receiving and installing OTA releases
• CLI for creating and publishing bundles
• Console for managing releases, users, rollouts, and adoption
• Testing workflow for validating releases before production
• Rollback controls for recovering from problematic releases
• Patch Updates for reducing transfer size when applicable
• Bundle Signing for cryptographic update verification

The goal of the migration is not to change how your team builds React Native applications. It is to replace the OTA delivery layer with a managed workflow.

Teams evaluating a CodePush migration may also consider Expo EAS Update, which provides a mature OTA workflow with channels, rollouts, runtime targeting, bundle diffing, and code signing on eligible plans. Stallion provides the same core OTA workflow while adding capabilities such as dedicated in-app OTA testing, any-to-any on-demand differential patch generation, regional hosting, and broader infrastructure control.

What Changes When You Move to Stallion?

The core concept remains the same: your native application contains an OTA-capable runtime, and compatible JavaScript updates can be delivered after the native application has been installed.

The tooling around that workflow changes.

The migration does not mean rewriting your React Native application.

You replace the CodePush SDK and its native integration with Stallion's SDK and configure the Stallion release workflow.

Before You Start

Before beginning the migration, make sure you have:

• A React Native application currently using CodePush
• Access to the application's Android and iOS native projects
• A Stallion account
• A Stallion project and bucket/environment for your releases
• A plan for testing the first migrated release
• Access to your CI/CD pipeline if OTA publishing is automated

It is also a good idea to keep the existing CodePush integration available until you've successfully validated the Stallion-enabled native build.

npm uninstall react-native-code-push

npm install react-native-stallion

yarn add react-native-stallion

npm install --save-dev stallion-cli

@Override
protected String getJSBundleFile() {
    return Stallion.getJSBundleFile(getApplicationContext());
}

- (NSURL *)bundleURL {
#if DEBUG
    return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
#else
    return [StallionModule getBundleURL];
#endif
}

override func bundleURL() -> URL? {
    #if DEBUG
        RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
    #else
        StallionModule.getBundleURL()
    #endif
}

npx stallion publish-bundle \
  --upload-path=<org-name>/<project-name>/<bucket-name> \
  --platform=<android-or-ios> \
  --release-note="Migrated from CodePush"

Internal testing
      ↓
Small production rollout
      ↓
Expanded rollout
      ↓
100% production

What Happens to Your Existing Users?

This is one of the most important parts of an OTA migration.

An application that is currently running the old CodePush integration does not automatically become a Stallion-enabled application.

The migration therefore normally requires a native app release containing the Stallion SDK.

Once users install that Stallion-enabled native build, subsequent compatible OTA releases can be delivered through Stallion.

A simplified migration looks like this:

Existing production app
        │
        │ App Store / Play Store / other native distribution
        ▼
Stallion-enabled native build
        │
        ▼
Stallion OTA releases
        │
        ├── Release 1
        ├── Release 2
        ├── Release 3
        └── Future OTA releases

You should therefore plan the migration around your normal native release cycle rather than treating it as a purely JavaScript-only migration.

CodePush Concepts → Stallion Concepts

The terminology changes slightly, but the underlying workflow remains familiar.

The exact implementation is different, so don't copy CodePush API calls into a Stallion integration unchanged. Follow Stallion's current SDK and CLI documentation for the corresponding implementation.

What You Gain After Migration

Moving away from the retired hosted CodePush service is not just a hosting change.

Stallion adds capabilities around the OTA release lifecycle.

On-demand differential patch generation

Stallion supports binary-safe differential patches with on-demand generation between any two compatible Stallion versions. This allows teams to generate patches across version gaps when multiple releases remain active in the field.

In Stallion's documented benchmark scenarios, update artifacts have been reduced by up to 98%. Actual patch size depends on the changes between releases.

Learn About Patch Updates →

Regional data hosting

For supported enterprise deployments, Stallion can keep OTA data within a selected geographic region to help teams meet data-residency and infrastructure requirements.

Enterprise deployment options

Stallion supports managed cloud, regional hosting, self-hosted, and on-premise deployment options, depending on the enterprise deployment requirements.

Release and rollout controls

Manage releases from the Stallion Console and control how updates move from testing into production.

This gives teams a more structured release path instead of treating OTA publishing as a single upload operation.

In-app testing

Authorized testers can test available OTA releases from within the application.

This can shorten the feedback loop for JavaScript changes because every test iteration does not require another native build.

Rollback controls

If a release causes problems, rollback controls provide a way to move users away from the problematic release according to your configured release strategy.

Bundle signing

Stallion supports customer-managed bundle signing so applications can verify the authenticity and integrity of signed OTA artifacts before installation.

This adds a cryptographic verification layer to the OTA release pipeline.

Learn About OTA Bundle Signing →

CI/CD integration

Stallion's CLI can be incorporated into existing CI/CD workflows, allowing teams to publish and promote OTA releases as part of their existing engineering process.

You don't need to replace your existing CI/CD platform to automate OTA publishing.

Migrating From CodePush Doesn't Mean Rebuilding Your Release Process

One advantage of a managed OTA platform is that your existing engineering workflow can remain largely intact.

Your team can continue using:

• React Native
• Your existing source control
• Your existing CI/CD provider
• Your existing native build process
• App Store and Play Store distribution
• Existing monitoring and crash-reporting tools

Stallion becomes the OTA delivery and release-management layer.

For many teams, the practical migration is therefore:

Replace the OTA layer, not the entire mobile development stack.

Common Migration Issues

The app still loads the Metro bundle

Make sure the Stallion native bundle-loading configuration is applied to the release build.

Debug builds commonly continue using Metro while release builds use the OTA bundle provider.

Check the native integration for your React Native version.

The OTA update is not downloaded

Check:

• Project configuration
• Application credentials
• Bucket/environment
• Platform
• App/runtime compatibility
• Network connectivity
• Whether the release is available to the current installation

The update was downloaded but isn't running

An OTA update may need to be applied and the application restarted before the new JavaScript bundle becomes active.

Check the Stallion SDK update state and your application's installation/restart flow.

The release is incompatible with the installed native app

OTA updates cannot introduce native modules, native configuration, or runtime capabilities that aren't already present in the installed native binary.

If your change requires native code, release a new native application build first.

Production users are still on CodePush

That's expected until those users install the Stallion-enabled native build.

Plan the native migration release carefully and monitor adoption of the new binary.

A Safer Migration Strategy

For a production application, don't switch everything at once.

A safer sequence is:

1. Integrate Stallion

Add the SDK and native configuration.

2. Create a migration build

Release the Stallion-enabled native application through your normal distribution process.

3. Test internally

Verify OTA download, installation, restart, assets, APIs, and native integrations.

4. Publish a low-risk OTA update

Use a small JavaScript change to validate the complete production workflow.

5. Monitor adoption

Confirm that the Stallion-enabled application is reaching your users.

6. Move future OTA releases to Stallion

Once the migration is validated, use Stallion as the primary OTA delivery layer.

This approach reduces migration risk while giving your team a clear rollback point at each stage.

React Native Stallion gives you a managed OTA platform with the tools needed to publish, test, roll out, monitor, and roll back React Native releases.

You can start with a small migration, validate the workflow with your existing application, and expand from there.

Get Started Free →

Read the Complete CodePush Migration Guide →