CodePush in React Native

Last updated on May 6, 2026

CodePush used to be the default answer for React Native over-the-air updates. That answer needs more context now. Microsoft retired Visual Studio App Center on March 31, 2025, and the hosted App Center workflow that many CodePush tutorials depended on is no longer a safe long-term default.

Quick Answer

You can still use over-the-air updates in React Native, but do not start a new app by blindly following old App Center CodePush tutorials. For a modern React Native app, choose one of these paths:

Path	Best for	Tradeoff
EAS Update	Teams that want a maintained OTA service for JavaScript, styles, and assets	Requires expo-updates and an EAS workflow
Self-hosted CodePush-compatible service	Teams already invested in CodePush and willing to own infrastructure	You own hosting, keys, releases, monitoring, and migration risk
App Store / Google Play releases only	Apps with infrequent changes or strict native release control	Slower bug-fix delivery

OTA updates are useful, but they do not replace native releases. Any change that touches native code, permissions, entitlements, SDK versions, icons, splash screens, app extensions, or bundled native assets still needs a new store build.

What Changed With CodePush?

Older React Native tutorials usually assumed this flow:

1. create an App Center account;
2. create CodePush apps and deployments;
3. install react-native-code-push;
4. publish updates through App Center CLI or CodePush CLI.

That flow is outdated because App Center has been retired. Microsoft published retirement guidance and pointed CodePush users toward a special version that can run independently from App Center, but that is not the same as having a hosted App Center product behind your updates.

Microsoft's standalone CodePush server repository is archived and provided without Microsoft support, so it should be treated as self-hosted infrastructure, not as a managed service replacement. If you are maintaining an existing CodePush integration, audit it before the next production release:

• where are deployment keys stored?
• which service serves update bundles?
• who owns the update server?
• how are bad updates rolled back?
• does the app block incompatible updates by native version?
• is update rollout visible in monitoring?

If you cannot answer those questions, treat the integration as release risk.

What OTA Updates Can And Cannot Do

OTA is best for small non-native changes:

• JavaScript bug fixes;
• copy changes;
• feature flag changes;
• styling changes;
• bundled images and assets that are part of the JS update;
• emergency UI fixes.

OTA should not be used for:

• native dependency upgrades;
• React Native version upgrades;
• CocoaPods or Gradle changes;
• permission changes;
• App Store privacy or entitlement changes;
• app icon and splash screen changes;
• SDK integrations that require a new binary;
• changes that must pass App Review before users see them.

This distinction matters because app stores review the native binary users install. An OTA update must stay compatible with that binary.

Ship faster with All Access. Get the React Native templates, admin panels, updates, and launch bonuses that help you build faster.

Explore All Access

Recommended OTA Strategy For New React Native Apps

For new React Native apps, a pragmatic update strategy looks like this:

1. Ship a stable native binary through App Store Connect and Google Play.
2. Use OTA only for JavaScript and asset updates that are compatible with that binary.
3. Gate updates by runtime/native version.
4. Roll out gradually.
5. Monitor crashes and app start failures after every update.
6. Keep a rollback command ready.
7. Make a store release whenever native code changes.

If you use EAS Update, the basic setup is:

npx expo install expo-updates
eas update:configure

Then publish an update to a channel:

eas update --channel production --message "Fix login button alignment"

EAS Update works with projects that use Continuous Native Generation and with existing React Native projects that have expo-updates installed. It still follows the same OTA limitation: it updates non-native pieces.

If You Already Use CodePush

Do not rip it out blindly. First, map the current production behavior:

Question	Why it matters
Which deployment receives production users?	Prevents publishing to the wrong channel.
Which native versions can load each update?	Prevents crashes from incompatible bundles.
Where is the update server hosted?	App Center retirement changed hosted assumptions.
How do rollbacks work?	Bad OTA updates need a fast escape hatch.
How are updates monitored?	A broken JS bundle can affect every user on launch.

Then choose a migration plan:

• keep a self-hosted CodePush-compatible flow if your team can operate it;
• migrate to EAS Update if you want a maintained service;
• reduce OTA usage and rely on store releases if the app is regulated or native-heavy.

Safe Release Checklist

Before publishing any OTA update:

• test the update on a release build, not only debug;
• test cold start after installing the update;
• test both iOS and Android;
• verify the update does not require a native build;
• publish to a staging or preview channel first;
• roll out gradually;
• monitor crashes and error reporting;
• keep rollback instructions next to the release command.

For store submissions, use the full React Native App Release Checklist.

Useful Links

• Microsoft App Center retirement notice
• CodePush standalone server repository
• EAS Update documentation
• Using EAS Update in an existing native app

Looking for a custom mobile application?

Our team of expert mobile developers can help you build a custom mobile app that meets your specific needs.

Get in Touch

FAQ

Is CodePush dead?

The old App Center-hosted workflow is retired. CodePush-compatible approaches can still exist, but you need to understand who hosts the update service and who supports it.

Can OTA updates change native code?

No. OTA updates are for JavaScript, styling, and assets that are compatible with the installed native binary. Native changes still need a new App Store or Google Play build.

Should every React Native app use OTA updates?

No. OTA is valuable for fast fixes, but it adds release infrastructure. If your app changes rarely or most work is native, store releases may be simpler.

Conclusion

CodePush was an important part of the React Native ecosystem, but the App Center retirement changed the operational picture. The modern decision is not "install CodePush or skip OTA." The decision is whether your app needs OTA updates, who will operate that update channel, and how you will prevent incompatible updates from reaching users.

If you are building on top of one of our React Native templates, start with a clean store release flow, then add OTA only when you have a concrete reason and a rollback plan.