Migrate from Stallion

A React Native or Expo app leaves Stallion at its next store release: the build that carries @hotcodepush/react-native-code-push is the switch. Stallion's projects become channels, its exact app version becomes the fingerprint, and the signing key carries over. What differs, side by side, is on the site's Stallion alternative page.

The builds before the switch keep checking Stallion for their app version, so both run until their users move. An Expo app imports from @hotcodepush/expo-ota-updates instead, and everything else on this page reads the same.

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 Stallion to HotCodePush: install the skills with `npx skills add hotcodepush-team/skills`, then run the hotcodepush-migrate skill, following https://hotcodepush.com/docs/migrate/stallion.

The agent removes Stallion, runs init, maps channels, the signing key and the binary ranges, and reports a checklist for the store release. It never touches Stallion, 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. Stallion ran on older versions, so upgrade first.
• You have stallion/secrets/private-key.pem, if the app signed. A fresh key from init works too.
• A store release with a new app version lies ahead: Stallion matches the exact version, so the old releases stay with the old builds.
• 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 Stallion and ran init, skip to step 4.

1. Freeze a branch for the old buildsCopy Anchor Link

git branch stallion-fleet

A bundle built from the migrated code imports a native module the old binaries lack. Hotfixes for them come from a branch that keeps the old client.

2. Remove StallionCopy Anchor Link

npm uninstall react-native-stallion

The CI job's npm install -g stallion-cli line goes with it. An Expo app also uninstalls expo-stallion-plugin and removes its entry from app.json. Remove withStallion, the hooks, sync(), restart() and the listeners per the SDK calls below. Then delete what the native projects carried:

• StallionProjectId, StallionAppToken and StallionPublicSigningKey in Info.plist and in every flavour's strings.xml, with the .xcconfig variables behind them.
• Stallion.getJSBundleFile() in MainApplication.kt and StallionModule.getBundleURL() in the Swift bundleURL(): put both files back to the template, which init recognises (Installation).

3. Run initCopy Anchor Link

npx hotcodepush init

init signs you in, creates the app with its production channel, installs the package and wires the build step. Answer no to the signing key if you bring Stallion's, and decline the first release. An Expo app gets @hotcodepush/expo-ota-updates and its config plugin. The prebuild refuses while expo-updates is installed without updates.enabled set to false (Expo installation).

4. Add the signing keyCopy Anchor Link

npx hotcodepush signing-key add --private-key-path stallion/secrets/private-key.pem

Skip this step if the app did not sign. Stallion's key is RSA-2048 in PKCS #8, which signing-key add takes. It fills publicKeys in hotcodepush.json, which replaces StallionPublicSigningKey. The private key stays where it is, and CI holds its content as HOTCODEPUSH_SIGNING_KEY in place of --private-key (Sign your bundles).

5. Create a channel per projectCopy Anchor Link

npx hotcodepush channel create --name staging --discoverable

Stallion gave each environment a project with its own id and app token. Here one app holds one channel per environment, with production from the start.

A flavour build sets HOTCODEPUSH_CHANNEL=staging in its build environment instead of a per-flavour strings.xml (Set up environments and tenants). Protect production with channel update --channel production --protected, so only Owners and Admins release to it, as Stallion's console promotion did.

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

Build the release as before, with the app version bumped. The build step registers the build as a binary with its fingerprint, so the machine needs npx hotcodepush login or HOTCODEPUSH_TOKEN. Under CI a store build without a token fails, and npx hotcodepush binary list shows the registered builds you submit to the stores.

7. Release from your pipelineCopy Anchor Link

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

This line replaces publish-bundle per platform, the grep for the hash, release-bundle and update-release. In the environment, HOTCODEPUSH_TOKEN replaces --ci-token on every command, and HOTCODEPUSH_SIGNING_KEY the key file (Ship every commit).

Add --rollout-percent 0 to start dark as Stallion did, then widen with release rollout. On a device running the new build the release applies within about a minute (How an update reaches a device). If nothing happens, see Troubleshooting.

8. Run both until the fleet movesCopy Anchor Link

Old builds keep checking Stallion for their app version, so keep the plan and the projects alive while they have users. Their releases still come from release-bundle --app-version <old>, from the branch of step 1 only.

Stallion's adoption dashboard and binary list show the shift. Stop the old pipeline once the old builds are below the share you will leave behind.

What maps to whatCopy Anchor Link

CLI commandsCopy Anchor Link

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.

Before and afterCopy Anchor Link

The withStallion wrapper goes and the component is exported plain: the SDK checks at start, on resume and every 900 seconds on its own. A restart prompt reads useUpdates() where it read useStallionUpdate(), and applyUpdate() restarts where restart() did:

import { HotCodePush, useUpdates } from '@hotcodepush/react-native-code-push';
import { Pressable, Text, View } from 'react-native';

export function RestartPrompt() {
  const { lastSync, state } = useUpdates();
  if (state.nextRelease === null) {
    return null;
  }
  const notes = lastSync?.status === 'downloaded' ? lastSync.notes : null;
  return (
    <View>
      <Text>{notes ?? `Version ${state.nextRelease.bundleVersion} is ready`}</Text>
      <Pressable onPress={() => void HotCodePush.applyUpdate()}>
        <Text>Restart now</Text>
      </Pressable>
    </View>
  );
}

The prompt needs "applyStrategy": "manual" in hotcodepush.json. Without the key a downloaded update applies at the next start, as Stallion did. A mandatory release follows mandatoryApplyStrategy, immediate by default: set it to manual to keep a modal that cannot be dismissed, and read isMandatory on state.nextRelease (Choose an apply strategy).

What differsCopy Anchor Link

Next stepsCopy Anchor Link

• Choose an apply strategy decides when a downloaded update takes effect, and who restarts the app after a mandatory release.
• Roll out gradually: start a release at a small percentage, let it progress and let auto-pause stop a bad one.
• Ship every commit has the pipeline that releases every merge with the one CLI line.
• React Native SDK reference documents every hotcodepush.json key, method, event and type of the SDK you installed.