This article is written by Karl Suhajda
The React Native New Architecture is no longer optional. From React Native 0.82 onwards it is mandatory, the legacy architecture is gone, and every team still running it is now carrying technical debt that will need to be resolved.
For most teams, the migration conversation quickly turns to tooling. Does our CI/CD pipeline still work? Does our crash reporter still integrate correctly? Do our analytics tools need updating? And for teams relying on over-the-air updates (OTA), does OTA delivery still work the same way after the migration?
The short answer is yes. OTA updates work with the New Architecture. The delivery mechanism is unaffected by the changes JSI, TurboModules, and Fabric introduce. But the longer answer, the one that matters for teams planning or mid-way through a migration, involves understanding what specifically changed, what stayed the same, what you need to verify before pushing your first OTA update post-migration, and what mistakes teams are making right now that cause unnecessary incidents during the transition.
This post covers all of it.
What the New Architecture actually changed
To understand how the New Architecture affects OTA updates, it helps to understand what it changed about the React Native runtime itself.
The legacy architecture communicated between JavaScript and native code through a bridge, an asynchronous serialisation layer that passed messages back and forth between the two sides. Every interaction between your JavaScript code and a native module went through this bridge. It worked, but it was a source of latency, memory overhead, and subtle timing issues that became more pronounced as apps grew in complexity.
The New Architecture replaced the bridge with the JavaScript Interface (JSI), a C++ layer that allows JavaScript and native code to hold direct references to each other and call across the boundary synchronously without serialisation. This is a fundamental change to how the two layers communicate.
Alongside JSI, the New Architecture introduced two other significant changes. TurboModules replaced the legacy native module system, with modules now loaded lazily on demand rather than all at once at startup, improving startup performance significantly. Fabric replaced the legacy UI renderer, the component responsible for turning your React component tree into native UI elements.
Finally, Hermes, the JavaScript engine developed specifically for React Native, became the default and only supported engine in the New Architecture. If your app was still running on JavaScriptCore, the migration requires moving to Hermes.
What stayed the same for OTA updates
Here is what matters for OTA deployment: despite all of these changes to how JavaScript and native code communicate, the JavaScript bundle delivery mechanism is unchanged.
OTA updates work by replacing the JavaScript bundle on a user’s device. The bundle is compiled JavaScript, your application code, component tree, logic, assets, and configuration. The New Architecture changed how that bundle communicates with native code at runtime. It did not change how the bundle is packaged, delivered, or applied to a device.
From an OTA delivery perspective, pushing an update works the same way it did before. You compile a new bundle. It gets delivered to devices through the CodePush update service. The next time the user opens the app, the new bundle is loaded. The JSI, TurboModules, and Fabric layers that sit below the bundle handle the runtime communication. They are not part of what OTA updates replace.
This is the practical answer to the question most teams ask: yes, your OTA update workflow will continue to work after migrating to the New Architecture.
Already on the New Architecture?
Codemagic CodePush supports React Native 0.76 and above, full New Architecture compatibility, no additional configuration required.
Start your free trial at codemagic.io/codepush
What you do need to check
Saying OTA updates work with the New Architecture is accurate. Saying nothing needs to be verified would not be. There are specific things your team should confirm before pushing your first OTA update after a New Architecture migration.
SDK version compatibility
Codemagic CodePush supports React Native 0.76 and above. If your migration target is within that range, and for any team migrating in 2026 it will be, you are covered. If you are upgrading from a significantly older React Native version as part of the same migration, confirm your CodePush SDK version is compatible with the target React Native version before starting the migration.
Native module dependencies in your bundle
The New Architecture changes how native modules are initialised and called. If your app includes JavaScript code that calls native modules in ways that depend on legacy bridge behaviour, for example assuming asynchronous bridge timing in ways that relied on the old serialisation model, those assumptions may break after migration.
This is not specifically an OTA issue, but it is worth auditing before your first OTA push post-migration. Any JavaScript code that interacts with native modules should be reviewed for New Architecture compatibility as part of your migration testing.
Hermes compatibility
If your app was running on JavaScriptCore prior to migration, the move to Hermes may surface JavaScript incompatibilities that were silently handled differently on the previous engine. Hermes has stricter handling of certain JavaScript patterns.
Run your full test suite on Hermes before your first OTA push post-migration. If you have JavaScript code that behaves differently on Hermes than it did on JavaScriptCore, you want to discover that in staging rather than in a production OTA update.
Your staging environment post-migration
Your staging channel should be migrated to the New Architecture before you attempt any OTA pushes to production post-migration. If staging is still running the legacy architecture while production is on the New Architecture, your staging validation is no longer representative of production, which defeats its entire purpose.
Migrate staging first. Validate OTA delivery in staging on the New Architecture. Only then migrate production and begin OTA pushes.
The migration checklist for OTA teams
Work through this before pushing your first OTA update after a New Architecture migration.
Before migrating
- Confirm your CodePush SDK version is compatible with your target React Native version
- Audit JavaScript code that calls native modules for bridge-dependency assumptions
- Confirm your staging channel is on the New Architecture before production
- Back up your current stable production bundle — you want a clean rollback point before the migration
During migration testing
- Run your full test suite on Hermes and resolve any incompatibilities
- Push a test OTA update to your staging channel on the New Architecture build
- Confirm the update delivers correctly and the app launches cleanly
- Test your rollback process in staging, revert to the pre-migration bundle and confirm the app works
Before first production OTA push post-migration
- Confirm staging OTA validation is complete and clean
- Confirm your rollback bundle is the post-migration stable build, not the pre-migration build
- Start with your lowest-risk rollout percentage, 5%, regardless of your confidence level
- Monitor crash rate and error logs with extra attention for the first 48 hours post-migration
What teams are getting wrong during migration
The mistakes that cause unnecessary incidents during New Architecture migrations tend to fall into a small number of patterns. Understanding them helps you avoid them.
Assuming OTA tooling migrates automatically
The New Architecture migration is primarily a native-layer change. OTA tooling, the CodePush SDK, deployment channels, and update configurations, does not automatically migrate with it. Teams sometimes complete the native migration and assume their OTA infrastructure came along for the ride.
It did not. You need to explicitly verify OTA delivery in your staging environment on the New Architecture build before assuming it works.
Not testing OTA delivery in staging post-migration
The most common source of post-migration OTA incidents is teams that verified the app itself worked after migration but did not specifically test the OTA update delivery path. The app working correctly in staging does not confirm that an OTA bundle can be pushed to, delivered to, and applied on a staging device on the new build.
Test the delivery path specifically and explicitly. Push a test bundle to staging. Confirm it downloads. Confirm it installs. Confirm the app launches with the new bundle. Confirm the rollback works. This takes 20 minutes and prevents the class of incident that comes from an unverified assumption.
Mixing native and JavaScript changes in the same OTA push during the migration window
During the migration period, after you have shipped the New Architecture native binary to the store but before your full user base has updated to it, you may have users on both the old and new native builds simultaneously.
An OTA update pushed during this window reaches both populations. If the JavaScript bundle you are pushing makes assumptions about the New Architecture runtime, calls that depend on JSI behaviour, TurboModule initialisation patterns, or Fabric rendering, it may behave incorrectly on devices still running the legacy architecture binary.
During the migration window, keep OTA updates strictly backwards-compatible with both native build versions. Wait until your legacy-architecture user base has dropped to a negligible percentage before pushing OTA updates that assume New Architecture runtime behaviour.
Updating the rollback target too early
After migrating to the New Architecture, your rollback target updates to the new stable build. This is correct and expected. But some teams update their rollback configuration immediately on migration day, before they have confirmed the new build is genuinely stable in production.
Keep your pre-migration bundle available as an emergency rollback point for at least 48 to 72 hours after production migration. If a significant problem emerges in the first hours after the native migration, you want the option to revert fully, not just to the last OTA push on the new architecture.
The Hermes engine: what OTA teams specifically need to know
Since Hermes is now the default and only supported JavaScript engine in the New Architecture, it is worth addressing Hermes specifically for teams managing OTA updates.
Hermes compiles JavaScript to bytecode at build time rather than at runtime. This is what makes it fast, there is no JIT compilation cost on the device. But it also means that the bytecode format is tied to the Hermes version bundled in your native binary.
The practical consequence for OTA: an OTA bundle compiled against a different version of Hermes than the one in your native binary may not load correctly. In practice this means your OTA bundles should be compiled using the same React Native version and therefore the same Hermes version as your current production native binary.
This is generally handled automatically if you are using a consistent toolchain. But if your CI/CD pipeline builds OTA bundles in a different environment than it builds your native binary, different Node version, different React Native CLI version, different dependency versions, it is worth explicitly confirming the Hermes versions match.
Summary
The React Native New Architecture changes how JavaScript and native code communicate at runtime. It does not change how OTA updates are packaged, delivered, or applied. Codemagic CodePush is fully compatible with React Native 0.76 and above, covering all New Architecture builds.
What teams need to do is verify, not assume. Migrate staging before production. Test OTA delivery specifically in staging on the new build. Confirm Hermes compatibility in your JavaScript code. Test your rollback process before pushing to production. Be conservative with OTA bundle contents during the migration window when both native build versions are active.
The teams that come through New Architecture migrations without OTA incidents are not the ones with the most confidence. They are the ones who treated verification as non-negotiable.
Frequently Asked Questions
Do OTA updates work with the React Native New Architecture?
Yes. OTA updates work with the React Native New Architecture. The delivery mechanism, compiling a JavaScript bundle and pushing it to devices, is unaffected by the changes JSI, TurboModules, and Fabric introduce. Codemagic CodePush is fully compatible with React Native 0.76 and above, covering all New Architecture builds. What teams need to do is verify rather than assume, test OTA delivery specifically in staging on the new build before pushing to production.
Is Codemagic CodePush compatible with the React Native New Architecture?
Yes. Codemagic CodePush supports React Native 0.76 and above, which covers the full New Architecture. No additional configuration is required beyond confirming your CodePush SDK version is compatible with your target React Native version.
What should I test before pushing an OTA update after a New Architecture migration?
Push a test OTA bundle to your staging channel on the New Architecture build. Confirm it downloads, installs, and the app launches correctly with the new bundle. Test your rollback, revert to the previous bundle in staging and confirm the app works. Run your full test suite on Hermes and resolve any incompatibilities. Only proceed to production OTA pushes once staging validation is complete and clean.
Can I push OTA updates during the React Native New Architecture migration window?
You can, but with a specific caution. During the migration window, some users will be on the old native binary and some on the new one. An OTA bundle pushed during this period reaches both populations. Keep OTA updates strictly backwards-compatible with both native build versions during this window. Wait until your legacy-architecture user base has dropped to a negligible percentage before pushing OTA bundles that assume New Architecture runtime behaviour.
How does the Hermes engine affect OTA bundle delivery?
Hermes compiles JavaScript to bytecode at build time. That bytecode format is tied to the Hermes version in your native binary. OTA bundles should be compiled using the same React Native, and therefore the same Hermes, version as your current production native binary. If your CI/CD pipeline builds OTA bundles in a different environment from your native binary, confirm the Hermes versions match to avoid bundle loading errors.
Migrating to the New Architecture and want to make sure your OTA setup survives the transition?
Codemagic CodePush supports React Native 0.76 and above. Our onboarding team can walk you through the validation steps specific to your setup.
Talk to the team at codemagic.io/contact-sales
