Migrate from CodePush

A React Native or Expo app leaves CodePush by replacing the CodePush client with @hotcodepush/react-native-code-push at its next native release. The store build that carries the new SDK is the switch, and the binaries before it keep taking CodePush updates until their users move. You keep delta updates and your signing key. What differs, side by side, is on the site's CodePush alternative page.

HotCodePush serves no CodePush-compatible endpoint, so the CodePush client cannot be pointed at a new server URL. App Center and CodePush retired on 2025-03-31.

This guide is for the React Native and Expo apps that used react-native-code-push or Bitrise's fork @bitrise/code-push-sdk (From Bitrise CodePush). The service behind it may be App Center, Bitrise CodePush, a self-hosted code-push-server or a compatible one. A Cordova app on CodePush starts at the Cordova SDK's Installation page instead.

AI-assisted migration (recommended)Copy Anchor Link

Install the HotCodePush skills:

npx skills add hotcodepush-team/skills

Then paste the prompt into your coding agent:

Migrate this app from CodePush to HotCodePush: install the skills with `npx skills add hotcodepush-team/skills`, then run the hotcodepush-migrate skill, following https://hotcodepush.com/docs/migrate/codepush.

The agent removes the CodePush client, runs init, maps channels, the signing key and the binary ranges, and reports a checklist for the store release. It never touches App Center or your CodePush server, and the first release waits for the store build. Agent skills explains what the agent does.

PrerequisitesCopy Anchor Link

• You have a HotCodePush account and an organization. npx hotcodepush init creates both, as the quickstart shows.
• The app is a React Native app on the New Architecture, or an Expo app that runs in a development build. The minimum versions are on Supported versions.
• You have the private key file your CodePush releases were signed with, if the app signed. Sign your bundles explains what the key does here.
• A store release lies ahead: the swap ships in a native build, so plan an App Store and a Play Store submission.
• Node.js is on every machine that makes a native build, since the build step runs the CLI from an Xcode phase and a Gradle task.

StepsCopy Anchor Link

If you already removed the client and ran init, skip to step 3.

1. Remove the CodePush clientCopy Anchor Link

npm uninstall react-native-code-push

Remove the wrapper, every call and every option per the SDK calls below. Delete the deployment key, the public key and any server URL from Info.plist and strings.xml.

Put the two host files back to what React Native's template generates for your version: the Swift file that overrides bundleURL() and MainApplication.kt. The CLI recognises the template's lines and stops with the manual step on a file it does not recognise. An Expo app removes the config plugin entry its CodePush setup added to app.json, and the next prebuild regenerates the native projects.

2. Run initCopy Anchor Link

npx hotcodepush init

init signs you in, picks or creates the organization and the app with its production channel, installs the package, writes hotcodepush.json and wires the build step. It asks whether to generate a signing key: answer no if you bring the CodePush key, which step 3 adds. Decline the first release as well.

• React Native: init installs @hotcodepush/react-native-code-push, runs pod install and adds the Xcode phase "Create HotCodePush binary" and one apply from line to android/app/build.gradle. It edits one line in each host file, and the React Native SDK's Installation page shows them for a project it could not edit.
• Expo: init installs @hotcodepush/expo-ota-updates and adds it to the plugins of app.json, and the config plugin wires the build step at npx expo prebuild. The prebuild refuses while the app depends on expo-updates without updates.enabled set to false. The app runs in a development build or a release build, never in Expo Go. The Expo SDK's Installation page has the details.

hotcodepush.json replaces what CodePush put into Info.plist and strings.xml: the build step writes it into the app on every build, and nothing is pasted into the native projects. The React Native SDK's Configuration page lists every key the file takes.

3. Add your signing keyCopy Anchor Link

Skip this step if your CodePush releases were not signed. HotCodePush signs with the same kind of RSA key pair, so the pair you have carries over:

npx hotcodepush signing-key add --private-key-path codepush-private.pem

signing-key add reads the PEM on your machine, registers the public key with the app and appends it to publicKeys in hotcodepush.json. The private key stays where it is: every upload names it with --private-key-path, or CI sets the file's content as HOTCODEPUSH_SIGNING_KEY. The build step writes publicKeys into the binary, which is what CodePushPublicKey did by hand.

4. Create the channels your deployments hadCopy Anchor Link

production exists. Each further deployment becomes a channel:

npx hotcodepush channel create --name staging --discoverable

--discoverable lets the app switch to the channel by name with setChannel({ name }), as Channels describes. Without it the channel is reachable by its id alone. A build flavour that follows staging sets HOTCODEPUSH_CHANNEL=staging in its build environment, as Set up environments and tenants shows.

5. Ship the store release that carries the SDKCopy Anchor Link

Build the release as before: an Xcode archive, a Gradle release variant or a cloud build such as EAS Build. The build step runs binary create inside the build and registers the build with HotCodePush, so the machine needs npx hotcodepush login or HOTCODEPUSH_TOKEN in its environment. Under CI a store build without a token fails. npx hotcodepush binary list shows the registered builds, and you submit them to the stores.

Metro serves a debug build's JavaScript, so a debug build takes no updates: test the next step in a release build.

6. Release from your pipelineCopy Anchor Link

npx hotcodepush release create --bundle-version "$(git rev-parse --short HEAD)" --yes

With HOTCODEPUSH_TOKEN and, for a signing app, HOTCODEPUSH_SIGNING_KEY in the environment, this is the whole pipeline step. The upload runs react-native bundle or expo export:embed per platform itself. Ship every commit is the pipeline this line sits in.

Open the app on a device that runs the new store build: the release applies within about a minute (How an update reaches a device). If nothing happens, see Troubleshooting.

7. Run both until the fleet movesCopy Anchor Link

A binary carries one client: a CodePush release never reaches a HotCodePush build, nor the reverse. Keep the CodePush pipeline releasing while the old builds have users. The Binaries page and binary list show each new build's devices. Stop the old pipeline once the old builds are below the share you will leave behind, and delete the CodePush server or account last.

CLI commandsCopy Anchor Link

A release is numbered per channel, #43 of production, and the label --bundle-version gives a bundle is free text beside it. The CLI reference lists every command. release and its flags are on the release page.

SDK callsCopy Anchor Link

The React Native SDK's API page has every method, event and type. Choose an apply strategy compares the strategies the InstallMode values map to.

Before and afterCopy Anchor Link

The codePush() wrapper goes, and the component is exported plain:

import codePush from "react-native-code-push"; 

function App() {
  return <Root />;
}

export default codePush({ 
  checkFrequency: codePush.CheckFrequency.ON_APP_RESUME, 
  installMode: codePush.InstallMode.ON_NEXT_RESUME, 
  minimumBackgroundDuration: 60, 
})(App); 
export default App; 

The options the wrapper took move into hotcodepush.json:

{
  "appId": "<your app id>",
  "channel": "production",
  "applyStrategy": "next_resume",
  "nextResumeMinimumBackgroundSeconds": 60
}

notifyAppReady() goes: the first render confirms the release. An app that confirms a release by hand sets readySignal: manual and calls notifyReady(), which also says whether this start follows a rollback. The call and its effect leave the entry file:

import { useEffect } from "react"; 
import codePush from "react-native-code-push"; 

export function App() {
  useEffect(() => { 
    codePush.notifyAppReady(); 
  }, []); 
  return <Root />;
}

You keep delta updatesCopy Anchor Link

HotCodePush precomputes a delta per base, the previous bundle and each embedded bundle, and a device without a matching pack takes the full one. CodePush diffed file by file, so a changed Hermes bundle travelled whole. Here it travels as a byte-level patch, so a small change moves little.

The store build uploads its embedded bundle, so the first update after a native release is a delta. See How an update reaches a device.

What else differsCopy Anchor Link

• Addresses: a CodePush deployment key was both the address and a bearer token in the binary. Here appId is public, and a channel is addressed by name in the configuration and by an unguessable id at runtime. Everything in a channel is readable by every device on it.
• The fingerprint replaces the target binary version: it rides on every release, so a release never lands on a build whose native code differs. A --binary-version range over the store version narrows it. See Compatibility.
• The readiness gate has no off switch: a release that has not rendered within readyTimeoutSeconds, 10 by default, is rolled back and marked failed there. It is never tried there again, and the next start fires updateRolledBack.
• Rollback is a release, and rollouts are sticky: release rollback publishes the previous bundle as a new release, mandatory by default, and release revoke ends a release outright. A device keeps its release when the percentage falls, and auto-pause halts a release whose failure rate climbs. See Roll out gradually.
• No dialog and no Windows: there is no updateDialog, and a mandatory release applies at once under mandatoryApplyStrategy: immediate. The SDK ships for iOS and Android.

From Bitrise CodePushCopy Anchor Link

Bitrise's @bitrise/code-push-sdk is a fork of the CodePush client with the same JavaScript API, native module and native keys. The steps and the SDK calls above apply, and four things differ:

• The package: npm uninstall @bitrise/code-push-sdk, and in an Expo app remove the @bitrise/code-push-sdk/expo entry from plugins. An app that kept react-native-code-push against Bitrise's server follows step 1 as written.
• One more key: delete CodePushEnableDeltaUpdates from Info.plist and the <bool name="CodePushEnableDeltaUpdates"> line from strings.xml. It is a <bool>, so a search for <string name="CodePush misses it, and deltas need no switch here.
• An app per platform: deployments belong to Bitrise's per-platform Release Management apps, so an iOS Staging and an Android Staging become one staging channel.
• The pipeline: in Bitrise CI, one Script Step that runs release create replaces both codepush-publish@1 Steps, and a HOTCODEPUSH_TOKEN Secret replaces BITRISE_API_TOKEN. The store build Workflow needs the token too, and the Bitrise recipe has the full Workflow.

The CLI, bitrise :codepush as a plugin or codepush standalone, replaces appcenter codepush with its own flags:

Next stepsCopy Anchor Link

• Ship every commit has the pipeline that releases every merge with the one CLI line, named by its commit.
• Roll out gradually: start a release at a small percentage, let it progress and let auto-pause stop a bad one.
• Choose an apply strategy: pick when a downloaded update takes effect, the decision InstallMode used to make.
• React Native SDK reference documents every hotcodepush.json key, method, event, type and reason of the SDK you installed.