Documentation

CodePush alternatives and Pakta migration

Compare standalone CodePush, EAS Update and Pakta after App Center retirement. Plan SDK replacement, native releases, targeting and recovery.

Updated 2026-09-15

On this page

What replaces App Center CodePush?

Pakta is a React Native OTA option for teams willing to replace their update SDK and ship a new native build. It is not a drop-in CodePush server: rn-update, .ppk artifacts and Pakta application/channel targeting use a different integration contract. Existing CodePush binaries cannot receive Pakta updates just by changing a deployment key.

Microsoft retired App Center CodePush on March 31, 2025. Microsoft also published a standalone server, so the hosted-service retirement does not mean all CodePush-based options disappeared. See the retirement notice and standalone CodePush server.

Compare migration paths

PathWhat changesWhat to validate
Standalone CodePushHosting, endpoint and potentially client configurationServer operations and exact SDK/runtime compatibility
Expo EAS UpdateMove to expo-updates and the EAS workflowNative integration, runtime versions and channels
PaktaMove to rn-update, register native baselines and publish .ppk updatesNative integration, target identity and device recovery

Microsoft's original React Native CodePush repository is archived and states that it does not support the New Architecture. Check the exact fork and version if retaining a CodePush client. For the Expo path, use Expo's migration guide.

Map concepts before changing code

CodePush conceptPakta workflowMigration consequence
Deployment keyApplication appKey plus native channel identityCredentials and identifiers cannot be reused
Target binary versionRegistered native package and channel/version targetRegister the exact new installer first
Release bundleCLI-generated .ppkRebuild from source; do not upload old CodePush artifacts
Install mode and readiness notificationUpdate strategy and health confirmationRecheck activation and startup health behavior
Rollout and rollbackTarget percentage and recovery deploymentTest device behavior, not just console state

This is a workflow mapping, not API compatibility. Read SDK integration and channels for the actual contracts.

Migrate to Pakta in stages

  1. Inventory your React Native version, native modules, Hermes configuration, installed binary versions, deployment keys and startup hooks. Retain the source and sourcemaps of the last stable release.

  2. On a migration branch, remove CodePush's JavaScript wrapper and native bundle-loading integration. Follow Pakta native setup or Expo setup. Give one update system ownership of bundle selection.

  3. Create Pakta applications for the target platforms. Configure an internal native channel and connect the root provider, activation strategy and health confirmation.

  4. Build and install a new Release binary. Register that exact APK/IPA as described in first release.

  5. Publish a one-label update to the internal channel. Verify the update hash, cold startup, offline startup and recovery to a stable package.

  6. Distribute the new native build through your normal release process. Track adoption separately from the old CodePush population, then gradually publish compatible Pakta updates.

What happens to existing installations?

An app that only contains CodePush still needs a native upgrade to include rn-update. Do not count those devices as eligible for Pakta releases. Keep an explicit plan for users who have not upgraded, including the supported recovery route available to their installed binary.

Cancelling a Pakta rollout does not remove updates already installed. See recovery behavior before the first production deployment.

How should you decide?

Preserving a client protocol, adopting Expo's update ecosystem and choosing Pakta's release workflow are different requirements. Verify one Release build end to end before migrating production. Continue with React Native OTA fundamentals, Expo Updates vs Pakta or Quick start.