- The New Architecture replaces the async bridge with JSI, Fabric, and TurboModules for synchronous native calls and faster UI updates.
- Migration is mostly about library readiness: check Fabric and TurboModule support before you flip the flag.
- Codegen and typed specs are now the contract between JS and native, so expect to write or update specs.
- You will still drop into Swift, Kotlin, or C++ for platform APIs that have no JS equivalent.
Your app launches in 2.8 seconds on a Pixel 8 and the home feed drops frames whenever a user scrolls past the third card. You profile it, and the bottleneck is not your JavaScript. It is the async bridge serializing every native call into JSON, queuing it, and handing it back on the next tick. That queue is exactly what the New Architecture was built to delete, and in 2026 it is the default runtime for new React Native projects. If you are still on the old bridge, or you flipped the flag last quarter and hit a wall of native module errors, this guide walks through what actually changed under the hood and how to move without breaking production. For broader stack decisions around the same codebase, our React Native mobile app development guide covers the surrounding choices.
What Is React Native's New Architecture in 2026?
The New Architecture is React Native's modern runtime built on JSI, Fabric, and TurboModules, replacing the asynchronous bridge with direct, typed native calls. It has been the default for new projects for a while, and in 2026 most production apps run it.
The old model worked like a post office. JavaScript called a native method, the call got serialized to JSON, pushed across an async bridge, deserialized on the native side, executed, then the result came back the same way. Every native call paid that tax, and every UI update waited for the bridge to drain. The New Architecture removes the serialization step entirely. JavaScript now holds a C++ reference to a native object and calls it directly.
Two consequences matter for your release schedule. First, synchronous native calls are now possible, which is why layout and gesture libraries can respond in the same frame as the touch. Second, the renderer commits UI trees with a real diffing algorithm instead of a shadow tree round trip, so list scrolling and animation stay smooth even when the JS thread is busy.
In 2026, the practical reality is that the New Architecture is not a preview you opt into. It is the path forward, and the old architecture is legacy maintenance. If you are starting a new app today, you get it by default. If you have an app that shipped in 2022 or 2023, your work is a migration, not a greenfield decision.
Fabric vs TurboModules vs JSI: What Each One Actually Changes
JSI is the low-level C++ layer that lets JavaScript hold references to native objects, Fabric is the new renderer that builds and commits UI trees synchronously, and TurboModules are the typed native modules loaded lazily through JSI. Together they remove the bridge bottleneck.
It helps to think of them as three layers, not three features. JSI is the foundation. Fabric and TurboModules are the two consumers of that foundation, one for UI and one for native capability.
| Layer | What it replaces | What it changes for you | Typical symptom if misconfigured |
|---|---|---|---|
| JSI | The JSON bridge transport | Direct C++ to JS references, synchronous calls possible | HostObject lifetime crashes, dangling references |
| Fabric | The old shadow tree renderer | Synchronous layout and commit, better list and gesture performance | Layout mismatch, missing measure callbacks |
| TurboModules | Legacy NativeModules | Lazy loading, typed specs, Codegen generated glue | Module not found, spec mismatch at build time |
| Codegen | Manual bridge macros | Generates C++, Java, and Objective-C from TS specs | Build fails on spec type mismatch |
The single biggest mental shift is Codegen. In the old world, you wrote a native module by hand and registered it with a macro. Now you write a TypeScript spec, and Codegen generates the native glue for iOS, Android, and C++. That means the contract between JS and native is typed and checked at build time. If your spec says a method returns a number and your Swift returns a string, the build fails instead of silently coercing at runtime.
TurboModules also load lazily. A legacy NativeModule was often initialized at startup whether you used it or not. TurboModules only instantiate when first accessed, which is one reason cold start improves after migration. If your app has a dozen native modules for analytics, crypto, and file access, that difference shows up in startup time.
How to Migrate a Legacy React Native App to the New Architecture
Migration is a staged process: upgrade React Native, enable the New Architecture flag, run Codegen, fix library incompatibilities, and test on both platforms before shipping. Most teams spend more time on library readiness than on their own code.
Here is the order that works in practice. Skipping steps is how you end up debugging native crashes for a week.
- Upgrade React Native first, on the old architecture. Get to a recent release with the bridge still active. Ship it. You want a known-good baseline before you change the runtime.
- Audit every dependency. For each library, check whether it ships Fabric and TurboModule support. This is the step that decides your timeline.
- Flip the New Architecture flag and run Codegen. Build both platforms. Expect Codegen errors on any spec that uses unsupported types.
- Fix interop cases. Libraries that have not migrated can often run through the interop layer, but interop has limits and performance cost.
- Test on real devices, not just simulators. Threading bugs and worklet issues show up under real load.
Two engineering details bite teams here. First, the interop layer lets you keep some legacy modules, but it does not give you synchronous calls or lazy loading for those modules. You get compatibility, not the performance win. Second, Reanimated worklets behave differently because they now run on the UI thread through JSI. If your animation code assumed bridge timing, it will need review.
This is also where test coverage pays off. A migration is a runtime swap, and regressions hide in edge cases like background sync, deep links, and permission flows. Our software testing and QA services use Playwright and Vitest for web surfaces and device farms for native, with CI gates that block a merge when a smoke suite fails. Pair that with a proper DevOps and cloud CI/CD setup so both platforms build on every pull request, and you catch Codegen breakage the moment a spec changes instead of at release.
Budget realistically. A small app with a clean dependency graph can migrate in a few weeks. An app with ten native modules, a custom renderer, and a couple of abandoned libraries can take a full quarter, because half the work is replacing or forking dependencies nobody maintains anymore.
Which Libraries Are Ready, and Where You Still Hit Native Code
Most core libraries and popular community packages support Fabric and TurboModules, but niche or unmaintained modules still require interop or a native rewrite. You will also write native code for platform APIs that have no JS binding.
The readiness picture in 2026 is good at the top of the dependency tree and uneven at the bottom. Navigation, gesture handling, animation, storage, and networking are all New Architecture ready. The trouble is the long tail: a payments SDK from a vendor that updates once a year, an old barcode scanner, a niche Bluetooth library, an analytics wrapper that wraps another wrapper.
When you hit one of those, you have three options, and they are not equal.
- Interop layer. Fastest path, keeps the library working, but you do not get synchronous calls or lazy loading for that module.
- Fork and migrate. You own the maintenance. Worth it if the library is core to your product and the upstream is dead.
- Write your own TurboModule. Cleanest long-term, most work up front, and it is the right call when the native surface is small.
You will also write native code regardless of library readiness. Anything that touches a platform API without a JS binding, like a specific iOS sensor, a background task scheduler, or a proprietary hardware SDK, needs Swift or Kotlin. That is not a failure of the framework. It is the boundary of what cross-platform can abstract.
A concrete example: if you integrate a vendor SDK that only ships an old-style NativeModule, you can wrap it, but the wrapper still crosses the bridge for that call. If that call sits in your hot path, say a real-time location update, the bridge cost comes back. In that case, writing a thin TurboModule around the vendor's native API is usually the better move, even though it means maintaining native code.
Performance Tradeoffs and Common Breakages After Migration
The New Architecture improves startup, list scrolling, and synchronous layout, but it can expose race conditions and lifecycle bugs that the old bridge hid. Expect to fix native module threading and reanimated worklet issues first.
Here is the honest part. The bridge was slow, but it was also a serialization boundary that accidentally protected you from some threading bugs. When calls become synchronous and direct, code that assumed ordering can break. The most common failures we see after a migration:
- Native module threading. A module that assumed it ran on a specific thread now runs where you call it. Shared mutable state needs a lock or a queue.
- Worklet timing. Animation code that read a JS value across the bridge now reads it through JSI, and stale closures surface as jank.
- Layout measurement. Fabric measures synchronously, so components that relied on a deferred measurement can render at the wrong size for one frame.
- HostObject lifetime. A JSI object held past its owner's lifetime crashes hard, and these are the crashes that are hardest to reproduce.
On the upside, the wins are real. Cold start improves because TurboModules load lazily. Long lists scroll smoother because Fabric commits on the UI thread. Gestures feel tighter because the touch can be handled in the same frame. We saw this pattern on a cross-platform build where the same codebase had to serve both mobile and a web dashboard, and the shared component logic held up well once the renderer changed. You can read the shape of that work in our proptech mobile plus web case study.
Measure before and after. Track startup time, dropped frames, and native module latency on a fixed device matrix. If you cannot show a number moving, you are doing migration work for future-proofing, not for speed, and you should say that out loud to your team.
When to Migrate, and When to Rebuild Instead
Migrate when your dependency graph is mostly New Architecture ready and your app is stable. Rebuild when the app is small, the codebase is tangled, or the upgrade cost exceeds a clean rewrite on the current stack.
The decision comes down to two variables: how many dependencies block you, and how much of your code is custom native. If most of your libraries are ready and your native surface is thin, migrate. If you are carrying five abandoned packages and a custom renderer, the migration is really a rewrite wearing a costume, and you should price it that way.
Rebuilding makes sense when the app is small enough that a clean start is cheaper than untangling years of workarounds, or when the product has drifted so far from the code that you would rewrite the screens anyway. In that case, start on the New Architecture from day one and skip the migration entirely.
There is a third path worth naming: stay put for now. If your app is small, stable, and uses only well-maintained libraries, the migration may cost more engineering time than it returns in speed. Measure startup time, frame drops, and native module latency before committing, and be willing to stay on the old architecture if the numbers do not justify the work. That is not laziness. That is prioritization.
Frequently Asked Questions
Is the New Architecture the default in React Native in 2026?
Yes, it is the default for new projects, and the old architecture is now legacy maintenance. If you scaffold a new app today, you get JSI, Fabric, and TurboModules without opting in. Existing apps still need to migrate explicitly.
That split is why you still see old-architecture code in the wild. Plenty of production apps shipped before the switch and have not moved yet, so library authors maintain both paths. As those apps migrate, the old path will fade.
Do I need to rewrite my native modules for TurboModules?
Not always, but you should plan to. Legacy modules can often run through the interop layer, which keeps them working without a rewrite. However, interop does not give you synchronous calls or lazy loading, so you lose most of the performance benefit for that module.
If the module is on a hot path, rewrite it as a TurboModule with a typed spec so Codegen can generate the glue. If it is called rarely, interop is a reasonable stopgap while you plan the rewrite.
What is the difference between Fabric and the old renderer?
Fabric builds and commits the UI tree synchronously through JSI, while the old renderer used an asynchronous shadow tree and a bridge round trip. That difference is why layout, lists, and gestures feel tighter after migration.
Practically, Fabric means a touch can be handled and the resulting layout committed in the same frame. The old renderer had to serialize the update and wait, which is where dropped frames came from under load.
How long does a New Architecture migration usually take?
It depends almost entirely on library readiness, not on your own code. A small app with a clean dependency graph can migrate in a few weeks; an app with custom native modules and abandoned packages can take a full quarter.
Audit your dependencies before you estimate. The number of libraries without Fabric or TurboModule support is a better predictor of timeline than lines of code.
Where to Go From Here
The New Architecture is the right long-term target, but the migration is a project with a real cost, and the win is measured in startup time and frame stability, not in a checkbox. Audit your dependencies first, measure your current performance, and decide with numbers.
If you would rather not run that audit solo, we build and migrate React Native apps for a living. Devs & Logics is a US-focused software development agency that builds SaaS MVPs, web platforms, mobile apps, AI-powered products, and cloud setups for startups and enterprises. Our React Native and Expo mobile app development team handles New Architecture migrations, TurboModule rewrites, and greenfield builds, and we will tell you honestly when a rebuild beats a migration.