For years, the React Native bridge was the invisible backbone of every mobile app built with the framework. It sat between your JavaScript code and the native iOS or Android layer, ferrying messages back and forth, translating function calls, and making the whole cross-platform model work. In React Native 0.85, it is gone from the codebase entirely.
The change has been building since React Native 0.74 made Bridgeless Mode the default and 0.76 promoted the New Architecture to stable. With 0.85, released in April 2026, there is no fallback to the bridge, no interoperability layer, no compatibility shim of any kind. Every app and every library targeting React Native 0.85 or later must run on the New Architecture or it will not run at all.
Our mobile team put together a 17-page investigation report on what this change actually means in practice. The findings below come from that work. If you have worked with us on cross-platform builds before, you know we treat framework migrations as part of the engagement. Our team's perspective on cross-platform tradeoffs is laid out in our framework comparison for cross-platform mobile development.
The bridge handled a specific job in React Native, and understanding that job makes the impact of removing it concrete.
It was an asynchronous message-passing layer between the JavaScript thread and the native thread. When your React Native code called a native API (accessing the camera, reading from storage, triggering a haptic response), that call was serialized into JSON, passed across the bridge, deserialized on the native side, executed, and the result was sent back the same way.
This worked, but it had real costs. Every cross-boundary call involved JSON serialization overhead. The asynchronous-only model made certain patterns difficult or impossible, like reading layout synchronously in an effect. The single-threaded nature of the bridge created bottlenecks under load.
Beyond performance, the bridge was also what allowed older libraries to keep working as React Native evolved. Code written years ago using the legacy Native Module system could still function in newer versions because the bridge preserved backward compatibility. That compatibility is now gone.
The shift to the New Architecture did not happen overnight. It is worth walking the version history because each release moved the deadline closer.
Bridgeless Mode arrived as an experimental opt-in in React Native 0.73 and became the default in 0.74. React Native 0.76, released in October 2024, promoted the New Architecture to stable and made it the default for new projects. Version 0.82, released in October 2025, became the first React Native that runs entirely on the New Architecture, with no way to disable it. Version 0.84 was the last release where the Bridge interoperability layer was still functional, which meant teams could still run legacy modules through interop. Then 0.85, released in April 2026, removed the Bridge from the codebase outright.
For teams that have been deferring migration, 0.84 was the last safe stopping point. Upgrading to 0.85 commits you to the New Architecture for everything.
Without the bridge, React Native relies on two core systems to handle communication between JavaScript and native code: JSI and Turbo Modules.
JSI (JavaScript Interface) is a lightweight C++ layer that gives JavaScript direct references to native objects, without JSON serialization. It enables synchronous calls when needed, reduces overhead on every native interaction, and supports multiple JavaScript engines.
Turbo Modules are the replacement for legacy Native Modules. They use JSI under the hood, load lazily (only when first called, not at startup), and use Codegen to generate type-safe bindings between JavaScript and native code at build time instead of runtime.
The rendering side is handled by Fabric, the new native renderer, which replaces the legacy UI Manager and brings concurrent rendering support and synchronous layout reads.
Together, these changes address the core limitations of the bridge model and enable React Native to properly support React 18 features like Suspense and Transitions.
The investigation report is most useful for teams planning their own migration. The impact falls into three categories: custom native modules, third-party libraries, and code that was relying on the interop layer to keep working without a proper migration.
Any custom native module written using the legacy NativeModules API needs to be rewritten as a Turbo Module. The rewrite involves a few steps:
For teams with a small number of custom modules, this is manageable. For apps with deep native integrations, it requires careful auditing before you touch anything.
Most teams will feel the most friction here. Any third-party library that wraps native functionality through the old bridge is broken in 0.85. The library either needs to have published a New Architecture-compatible version, or you need to find an alternative.
The React Native Directory now flags library compatibility with the New Architecture. Before upgrading, audit every native dependency in your project against this list. Expo Doctor can automate part of this audit if you run npx expo-doctor against your dependencies.
If the migration path looks heavy from this audit alone, our complete guide to mobile app development planning and costs covers how we typically scope work like this, with realistic timelines and budget bands.
Between 0.76 and 0.84, React Native provided an interoperability layer that allowed legacy Native Components to run inside New Architecture apps without being fully migrated. This bought time for the library ecosystem to catch up.
In 0.85, that layer is removed. Libraries that were relying on interop compatibility to keep functioning in New Architecture apps without a proper migration are now broken.
This is the most common source of surprises in 0.85 upgrades. A library that appeared to work fine under the interop layer in 0.84 stops working entirely in 0.85.
We use the following process for these migrations. It is not the only sequence that works, but it is the one that has consistently kept our team out of debugging spirals on production apps.
Start with a dependency audit. Before writing any code, build a complete picture of your native dependencies. For each one, identify whether a New Architecture-compatible version exists, whether it is actively maintained, and whether migration is needed.
Once the audit is clear, do the work on a dedicated branch. Migration introduces instability, and isolating it from your main development branch makes it much easier to revert or pause if something goes sideways. Accept that the branch may exist for a while.
Migrate module by module. A full codebase migration in one pass almost always makes debugging worse, because you cannot isolate which change introduced a regression. Move one native module at a time, test it, and only then move to the next.
Use Codegen from the start. Codegen is not optional in the New Architecture, since it generates the type bindings that JSI needs. Get comfortable running it early and integrating it into your build process.
Test on both platforms simultaneously. iOS and Android behave differently during migration, and issues that are silent on one platform often surface on the other.
For a typical production app with moderate native dependencies, our team found the migration takes two to four weeks. Apps with extensive custom native code or a large number of native library dependencies can take considerably longer. If you are weighing whether to take this on internally or work with an outside team, our guide on how to evaluate and hire an app agency covers what to look for in a partner.
Our investigation documented several issues that do not have obvious solutions in the official documentation.
Event listener cleanup behavior has changed. Pressable components have shown a number of subtle regressions on Android under the New Architecture, including cases where Pressable gets stuck or stops responding. In our project, we saw event listeners outlive their components inside a hidden Activity on Android, which required us to add manual cleanup.
Several deprecated C++ type aliases related to ShadowNode and ContextContainer have been removed. If you have any C++ native code touching these, it needs to be updated to use direct types.
The setAccessibilityFocus API is deprecated; replace it with sendAccessibilityEvent and pass "focus" as the event type.
For teams hitting issues not covered in the official migration guide, the React Native New Architecture Working Group discussions have been the most reliable source of community-sourced solutions.
If your app is on React Native and you have not engaged with the New Architecture migration yet, your upgrade path now has a hard deadline built into it. Staying on older versions means missing security patches, performance improvements, and compatibility with newer React features.
If you are building or maintaining a React Native library, 0.85 makes New Architecture compatibility a requirement, not an enhancement. Libraries that have not migrated are now incompatible with the current stable release.
If you are starting a new React Native project in 2026, none of this is a concern. New projects scaffold with the New Architecture by default.
For teams at NineTwoThree working on client projects, we treat the 0.82 and later migration as a standard part of any React Native upgrade engagement. The bridge is gone, and building with what is here is the only path forward. Our mobile app development practice handles this work as part of broader engagement scopes.
If your team is navigating this migration and needs an experienced partner, get in touch with NineTwoThree. We have worked through the specifics and can help you scope, plan, and execute the upgrade without throwing off your release schedule.
For years, the React Native bridge was the invisible backbone of every mobile app built with the framework. It sat between your JavaScript code and the native iOS or Android layer, ferrying messages back and forth, translating function calls, and making the whole cross-platform model work. In React Native 0.85, it is gone from the codebase entirely.
The change has been building since React Native 0.74 made Bridgeless Mode the default and 0.76 promoted the New Architecture to stable. With 0.85, released in April 2026, there is no fallback to the bridge, no interoperability layer, no compatibility shim of any kind. Every app and every library targeting React Native 0.85 or later must run on the New Architecture or it will not run at all.
Our mobile team put together a 17-page investigation report on what this change actually means in practice. The findings below come from that work. If you have worked with us on cross-platform builds before, you know we treat framework migrations as part of the engagement. Our team's perspective on cross-platform tradeoffs is laid out in our framework comparison for cross-platform mobile development.
The bridge handled a specific job in React Native, and understanding that job makes the impact of removing it concrete.
It was an asynchronous message-passing layer between the JavaScript thread and the native thread. When your React Native code called a native API (accessing the camera, reading from storage, triggering a haptic response), that call was serialized into JSON, passed across the bridge, deserialized on the native side, executed, and the result was sent back the same way.
This worked, but it had real costs. Every cross-boundary call involved JSON serialization overhead. The asynchronous-only model made certain patterns difficult or impossible, like reading layout synchronously in an effect. The single-threaded nature of the bridge created bottlenecks under load.
Beyond performance, the bridge was also what allowed older libraries to keep working as React Native evolved. Code written years ago using the legacy Native Module system could still function in newer versions because the bridge preserved backward compatibility. That compatibility is now gone.
The shift to the New Architecture did not happen overnight. It is worth walking the version history because each release moved the deadline closer.
Bridgeless Mode arrived as an experimental opt-in in React Native 0.73 and became the default in 0.74. React Native 0.76, released in October 2024, promoted the New Architecture to stable and made it the default for new projects. Version 0.82, released in October 2025, became the first React Native that runs entirely on the New Architecture, with no way to disable it. Version 0.84 was the last release where the Bridge interoperability layer was still functional, which meant teams could still run legacy modules through interop. Then 0.85, released in April 2026, removed the Bridge from the codebase outright.
For teams that have been deferring migration, 0.84 was the last safe stopping point. Upgrading to 0.85 commits you to the New Architecture for everything.
Without the bridge, React Native relies on two core systems to handle communication between JavaScript and native code: JSI and Turbo Modules.
JSI (JavaScript Interface) is a lightweight C++ layer that gives JavaScript direct references to native objects, without JSON serialization. It enables synchronous calls when needed, reduces overhead on every native interaction, and supports multiple JavaScript engines.
Turbo Modules are the replacement for legacy Native Modules. They use JSI under the hood, load lazily (only when first called, not at startup), and use Codegen to generate type-safe bindings between JavaScript and native code at build time instead of runtime.
The rendering side is handled by Fabric, the new native renderer, which replaces the legacy UI Manager and brings concurrent rendering support and synchronous layout reads.
Together, these changes address the core limitations of the bridge model and enable React Native to properly support React 18 features like Suspense and Transitions.
The investigation report is most useful for teams planning their own migration. The impact falls into three categories: custom native modules, third-party libraries, and code that was relying on the interop layer to keep working without a proper migration.
Any custom native module written using the legacy NativeModules API needs to be rewritten as a Turbo Module. The rewrite involves a few steps:
For teams with a small number of custom modules, this is manageable. For apps with deep native integrations, it requires careful auditing before you touch anything.
Most teams will feel the most friction here. Any third-party library that wraps native functionality through the old bridge is broken in 0.85. The library either needs to have published a New Architecture-compatible version, or you need to find an alternative.
The React Native Directory now flags library compatibility with the New Architecture. Before upgrading, audit every native dependency in your project against this list. Expo Doctor can automate part of this audit if you run npx expo-doctor against your dependencies.
If the migration path looks heavy from this audit alone, our complete guide to mobile app development planning and costs covers how we typically scope work like this, with realistic timelines and budget bands.
Between 0.76 and 0.84, React Native provided an interoperability layer that allowed legacy Native Components to run inside New Architecture apps without being fully migrated. This bought time for the library ecosystem to catch up.
In 0.85, that layer is removed. Libraries that were relying on interop compatibility to keep functioning in New Architecture apps without a proper migration are now broken.
This is the most common source of surprises in 0.85 upgrades. A library that appeared to work fine under the interop layer in 0.84 stops working entirely in 0.85.
We use the following process for these migrations. It is not the only sequence that works, but it is the one that has consistently kept our team out of debugging spirals on production apps.
Start with a dependency audit. Before writing any code, build a complete picture of your native dependencies. For each one, identify whether a New Architecture-compatible version exists, whether it is actively maintained, and whether migration is needed.
Once the audit is clear, do the work on a dedicated branch. Migration introduces instability, and isolating it from your main development branch makes it much easier to revert or pause if something goes sideways. Accept that the branch may exist for a while.
Migrate module by module. A full codebase migration in one pass almost always makes debugging worse, because you cannot isolate which change introduced a regression. Move one native module at a time, test it, and only then move to the next.
Use Codegen from the start. Codegen is not optional in the New Architecture, since it generates the type bindings that JSI needs. Get comfortable running it early and integrating it into your build process.
Test on both platforms simultaneously. iOS and Android behave differently during migration, and issues that are silent on one platform often surface on the other.
For a typical production app with moderate native dependencies, our team found the migration takes two to four weeks. Apps with extensive custom native code or a large number of native library dependencies can take considerably longer. If you are weighing whether to take this on internally or work with an outside team, our guide on how to evaluate and hire an app agency covers what to look for in a partner.
Our investigation documented several issues that do not have obvious solutions in the official documentation.
Event listener cleanup behavior has changed. Pressable components have shown a number of subtle regressions on Android under the New Architecture, including cases where Pressable gets stuck or stops responding. In our project, we saw event listeners outlive their components inside a hidden Activity on Android, which required us to add manual cleanup.
Several deprecated C++ type aliases related to ShadowNode and ContextContainer have been removed. If you have any C++ native code touching these, it needs to be updated to use direct types.
The setAccessibilityFocus API is deprecated; replace it with sendAccessibilityEvent and pass "focus" as the event type.
For teams hitting issues not covered in the official migration guide, the React Native New Architecture Working Group discussions have been the most reliable source of community-sourced solutions.
If your app is on React Native and you have not engaged with the New Architecture migration yet, your upgrade path now has a hard deadline built into it. Staying on older versions means missing security patches, performance improvements, and compatibility with newer React features.
If you are building or maintaining a React Native library, 0.85 makes New Architecture compatibility a requirement, not an enhancement. Libraries that have not migrated are now incompatible with the current stable release.
If you are starting a new React Native project in 2026, none of this is a concern. New projects scaffold with the New Architecture by default.
For teams at NineTwoThree working on client projects, we treat the 0.82 and later migration as a standard part of any React Native upgrade engagement. The bridge is gone, and building with what is here is the only path forward. Our mobile app development practice handles this work as part of broader engagement scopes.
If your team is navigating this migration and needs an experienced partner, get in touch with NineTwoThree. We have worked through the specifics and can help you scope, plan, and execute the upgrade without throwing off your release schedule.
