NextPushnextpush
Get started
All posts
NextPush Team9 min read

OTA updates on the React Native New Architecture with @code-push-next/react-native-code-push

Microsoft's react-native-code-push never ran on Fabric and TurboModules. The community package does. Current version, React Native support matrix, install and NextPush configuration, a migration checklist, and the pitfalls: Hermes detection in the CLI, bridgeless mode, sync timing and device testing.

React Native has shipped with the New Architecture enabled by default since 0.76 in October 2024, and since 0.82 it is the only architecture. Microsoft's react-native-code-push never made that jump. If your app is on a current React Native and you want CodePush-style updates, the package you install is @code-push-next/react-native-code-push. This post covers what it is, which versions pair with which React Native, how to point it at NextPush, how to migrate from the Microsoft package, and the handful of things that bite people in production.

Why the Microsoft SDK stopped at the bridge

The original SDK was built on the bridge. On both platforms it registers a legacy native module, and when an update is ready to install it restarts JavaScript by asking the bridge to reload from a new bundle path. Fabric and TurboModules change how native modules are registered and called, and bridgeless mode removes the bridge object the SDK relied on to restart. Microsoft's compatibility table stops at React Native 0.71 and its README says plainly that it will not support the New Architecture. The last release, 9.0.1, is from December 19, 2024; every version on npm is marked deprecated; the repository was archived on May 20, 2025, along with the standalone server. There was never going to be a port.

Nothing about the CodePush protocol itself is tied to the bridge. The update check, the download, the reportStatus call, deployment keys, rollouts and rollbacks are HTTP and JSON. A client that speaks the same protocol with a New Architecture native layer works against any CodePush server, including NextPush, with no server-side change.

The community package

@code-push-next/react-native-code-push is that client. Facts checked at the time of writing against the npm registry and the package README:

  • Latest version 10.4.3, published August 10, 2026 (10.4.0 in February, 10.4.1 in April, 10.4.2 in June).
  • Repository: github.com/codemagic-ci-cd/react-native-code-push. It started under the CodePushNext organisation and now lives under Codemagic's; the npm scope is unchanged.
  • Same JavaScript API as the Microsoft package: codePush() higher-order component, codePush.sync(), checkForUpdate(), CheckFrequency, InstallMode, SyncStatus.
  • Both architectures from 10.0 up to React Native 0.81; from React Native 0.82 the New Architecture is the only one, and the package follows.
  • No react-native peer dependency range is declared; the package is developed against React Native 0.86. The only peer dependency is an optional expo.
  • An Expo config plugin, @code-push-next/react-native-code-push/expo, takes ios and android objects with CodePushDeploymentKey and CodePushServerURL. It needs a prebuild or a development build; Expo Go cannot load it.

Compatibility table from the README:

React Native Package version
0.76 to 0.79 10.0 or later
0.80 10.1 or later
0.81 10.3 or later
0.82 and later 10.4 or later (New Architecture only)

Use the newest release that matches your React Native. The maintainers note in the README that their new development goes into Codemagic Patch and recommend it for new projects; the package is still receiving releases, four of them in 2026 so far.

Install and point it at NextPush

The steps below are the ones from the NextPush documentation. They are identical to the original CodePush setup with the package name changed.

1. Install

npm install @code-push-next/react-native-code-push
# or
yarn add @code-push-next/react-native-code-push

cd ios && pod install

2. Native setup

Follow the platform setup in the package README: the Android MainApplication change and the iOS AppDelegate change. If you have done this for Microsoft's package before, it is the same edit.

3. Point the SDK to NextPush

Android, android/app/src/main/res/values/strings.xml:

<string moduleConfig="true" name="CodePushDeploymentKey">YOUR_DEPLOYMENT_KEY</string>
<string moduleConfig="true" name="CodePushServerUrl">https://api.nextpush.center</string>

iOS, ios/<YourApp>/Info.plist:

<key>CodePushDeploymentKey</key>
<string>YOUR_DEPLOYMENT_KEY</string>
<key>CodePushServerURL</key>
<string>https://api.nextpush.center</string>

Deployment keys are shown on the app page in the NextPush dashboard. Note the casing difference between the two platforms (CodePushServerUrl on Android, CodePushServerURL on iOS); it is inherited from the original SDK and both are correct.

4. Use it in JavaScript

import codePush from "@code-push-next/react-native-code-push";

function App() {
  // ...
}

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

5. Release

nextpush release-react -a companyName/AwesomeApp -d Production

Migrating from react-native-code-push

If the app already has Microsoft's package, the migration is a dependency swap. Work through this list in order.

  1. Remove react-native-code-push and install @code-push-next/react-native-code-push.
  2. Replace every from "react-native-code-push" import with from "@code-push-next/react-native-code-push". There are no API renames.
  3. Check MainApplication and AppDelegate: the import paths in the native files change with the package name. The README has the current lines.
  4. Add CodePushServerUrl / CodePushServerURL if they are not there. The Microsoft default points at an endpoint that stopped answering on March 31, 2025.
  5. Re-run pod install and rebuild the native app for both platforms.
  6. Ship the new binary. Existing deployment keys and the release history on the server keep working; this is a client change only.

Older installs that still run the Microsoft package keep whatever server URL they were built with. If that was NextPush, they keep receiving updates from the same deployment; the protocol and the key have not changed. If it was App Center's default endpoint, they have not received an update since March 2025 and never will.

Pitfalls

Hermes bytecode and the CLI's detection

nextpush release-react (like the code-push CLI it is forked from) decides whether to compile the bundle to Hermes bytecode by looking for enableHermes: true inside the project.ext.react block of android/app/build.gradle, and for hermes_enabled => true in ios/Podfile. Those are the React Native 0.70-and-earlier patterns. Since React Native 0.71, Hermes is switched on with hermesEnabled=true in android/gradle.properties, and the Podfile reads :hermes_enabled => flags[:hermes_enabled]. CLI releases up to 1.1.0 read neither, so on a current project they conclude Hermes is off and upload plain JavaScript. The next CLI release reads gradle.properties (and treats React Native 0.70+ as Hermes by default) for Android; the iOS Podfile pattern is still not detected.

The update still loads, because Hermes can compile source at runtime, but you lose the ahead-of-time compilation you get in the store build: slower startup and a larger download. Until you are on a CLI that detects your setup, tell it explicitly:

nextpush release-react -a companyName/AwesomeApp -d Production --useHermes

-h is the short alias. Put it in your release script and forget about it. If you need extra Hermes compiler flags, --extraHermesFlags is passed through.

Bridgeless mode and 0.82+

From React Native 0.82 there is no legacy architecture and code-push-next 10.4 is New Architecture only. If your app pins an older package version for an older React Native, upgrade both together, not one at a time; a 10.3 client on a 0.82 app is the combination the table rules out.

codePush.sync() timing

The defaults (CheckFrequency.ON_APP_START, InstallMode.ON_NEXT_RESTART) are safe but slow to roll out. ON_APP_RESUME with ON_NEXT_RESUME and a minimumBackgroundDuration of a few minutes is the common production choice: the update is applied the next time the user brings the app back from the background after a real pause, so nothing changes under their fingers. Avoid InstallMode.IMMEDIATE on the first render unless the update is marked mandatory and you want the restart; it is a jarring experience and it is also the setting most likely to produce a visible restart loop if a bad bundle gets out. If you call sync() yourself instead of using the higher-order component, call it once the app is interactive, not inside a useEffect that runs before navigation is ready.

Target binary version

A release targets the binary version the CLI reads from Info.plist and build.gradle unless you pass -t. If a device on 1.4.0 never sees your update, check the deployment history: a release targeted at 1.3.0 is invisible to it. Semver ranges (-t "~1.4") are supported.

Testing on a device

Use the Staging deployment key in a release build (debug builds load from Metro, not from the server), release to Staging, and watch nextpush deployment history companyName/AwesomeApp Staging. Allow 60 to 90 seconds after a release before expecting a device to see it: NextPush serves update checks through a CDN cache and a new release becomes visible when that cache expires. If you kill and reopen the app within that window and see nothing, that is expected; it is not a sign that the keys are wrong. Once Staging is right, nextpush promote companyName/AwesomeApp Staging Production moves the same bundle to Production without rebuilding it.

Dependency risk, stated plainly

The client we recommend is maintained by Codemagic, which sells its own update product and says in the README that new development happens there. That is a dependency risk for everyone on this package, NextPush and its customers included. Our position: we track the upstream and keep a fork ready. If the package stops receiving releases for a React Native version our customers need, we will publish and maintain the fork under our own scope and say so in the docs. Until then the upstream package is the right thing to use, and the four releases in 2026 suggest it is in no hurry to stop.

Summary

  • Microsoft's SDK is deprecated, archived and bridge-only. On React Native 0.76 and later, use @code-push-next/react-native-code-push 10.x; on 0.82 and later, 10.4 or newer.
  • Setup is the original CodePush setup plus two strings: the deployment key and https://api.nextpush.center.
  • Pass --useHermes to nextpush release-react on React Native 0.71 and later unless your CLI is newer than 1.1.0 (Android detection fixed there); for iOS keep passing it.
  • Test on a release build against Staging, give the CDN a minute, then promote.

Sources