Upgrading to BetterCodePush 1.0: what changes and what to do
1.0 moves to a new update protocol, so apps need one new store build. Here is what happens to the builds already in your users' hands, and the six steps to upgrade.
BetterCodePush 1.0 ships a new update protocol. It is what makes 1.0 faster and safer: devices pick their release from a small catalog on the CDN, downloads shrink to binary patches, and every rollout and rollback change reaches devices within seconds. It is also a breaking change. There is no compatibility mode, so every app needs one new store build made with the 1.0 SDK.
What happens to builds already in the stores
- They keep running the bundle they have today. Nothing is rolled back and nothing breaks.
- They stop receiving updates. The old SDK treats the missing endpoint as "no update" and keeps its current bundle.
- Releases you publish for the new build are never delivered to old builds, so you cannot accidentally push a 1.0 bundle to a binary that cannot run it.
In practice: publish your last fix for the old builds before you upgrade, then ship the new build and move forward on 1.0.
Upgrade in six steps
1. Upgrade the packages
npm install --save-dev @bettercodepush/cli@latest
npm install @bettercodepush/react-native@latest
# Expo apps also:
npm install @bettercodepush/expo@latestThe CLI needs Node.js 22.23.4 or newer on the 22 line, 24.22.1 or newer, or 26.12.1 or newer.
2. Regenerate the configuration
Your account, organizations, app IDs and API keys stay the same. Re-run init, or pass the app IDs as flags in CI:
npx bettercodepush init --ios-app-id app_... --android-app-id app_...Leave out the flag for a platform you do not ship and init skips it.
3. Wrap your root component
import { BetterCodePush } from "@bettercodepush/react-native";
export default BetterCodePush.init({}).wrap({
updateStrategy: "appVersion",
})(App);init({}) needs no URL: it reads the app ID that init or the Expo config plugin embedded in the native project. updateStrategy must match the one in bettercodepush.config.ts.
Expo apps register the @bettercodepush/expo config plugin and regenerate the native projects with npx expo prebuild --clean.
4. Check signing
If you sign bundles, the public key must be registered on each app in the console and embedded in the native build. A signed release is rejected by an app without the key, and an app with the key rejects an unsigned release, so set both sides before you build.
5. Verify and build
npx bettercodepush doctorFix every error it reports, then build and submit the new binary to the stores.
6. Deploy as before, with one renamed command
deploy works as it did. There is no rollback command any more: disabling a release is the rollback, and devices fall back to the previous compatible release, then to the bundle built into the app.
npx bettercodepush bundle disable "$RELEASE_ID" --yes
# changed your mind:
npx bettercodepush bundle enable "$RELEASE_ID" --yesWhat does not change
The hosted URLs, your account and API keys, and the SHA-256 and RSA signature checks on every bundle. The full walkthrough, including Expo specifics, is in the getting-started guide. For what is new in 1.0, read the 1.0 announcement.