The New Architecture is the largest change React Native has made since it launched. It's now the default, and understanding what it replaced explains both why it matters and which of your problems it won't solve.
The problem with the old bridge
Legacy React Native ran JavaScript and native code as two separate worlds connected by an asynchronous JSON bridge. Every interaction — calling a native module, updating the UI, responding to a gesture — meant serialising data to JSON, passing it across, and deserialising on the other side.
This caused three specific problems:
Everything was asynchronous. You could not synchronously ask native code for a value. Anything needing an immediate answer had to be restructured around a callback.
Serialisation was a real cost. Large payloads meant measurable time spent converting to and from JSON, and the bridge was a single queue everything shared.
Frame drops during interaction. The classic symptom: a scroll view that stutters when your JavaScript is busy, because the layout update it needed had to queue behind other bridge traffic. Users experienced it as a list that felt "not quite native," and it was very hard to fix from application code.
JSI: the foundation
The JavaScript Interface replaces the bridge with direct bindings. JavaScript can hold a reference to a C++ object and call methods on it directly — no serialisation, no queue, and synchronously when appropriate.
This isn't a feature you use directly. It's the layer everything else is built on, and it's what makes the other two pieces possible.
The practical consequence: the JavaScript engine is no longer isolated behind a message queue. Native code can be invoked as a function call rather than a message send.
Fabric: the new renderer
Fabric is the rendering system built on JSI. Two things change meaningfully.
Layout can be synchronous when it needs to be. The old renderer's async layout is why scroll views stuttered under load. Fabric can perform layout on the same thread as the interaction, so scrolling and gestures stay smooth while JavaScript is busy.
The shadow tree lives in C++. Previously the view hierarchy was managed in JavaScript, so every update crossed the bridge. Now it's shared C++ state that both sides access directly, which cuts a large amount of traffic that used to be constant background cost.
What you'll notice: smoother scrolling in complex lists, more responsive gestures, less jank when the JS thread is doing work. What you won't notice: any change to how you write components. Fabric is transparent to normal application code.
Turbo Modules: lazy native modules
Under the old system, every native module was initialised at app launch, whether or not you used it. An app with thirty native dependencies paid startup cost for all thirty even if the user only opened the home screen.
Turbo Modules load on first use. A camera module isn't initialised until something touches the camera.
The startup improvement is real and scales with how many native dependencies you have. An app with a handful of modules sees little; one with dozens sees a lot. Anyone quoting you a fixed percentage is guessing — measure your own cold start before and after.
Turbo Modules are also typed. You define the interface in TypeScript, and Codegen generates the C++ and platform binding code from it. A mismatch between your JavaScript signature and the native implementation becomes a build error rather than a runtime crash on a device you don't own.
What this means for a new project
Very little, deliberately. The New Architecture is the default in current React Native versions, and you get all of it without doing anything. You write components the same way.
The benefits are structural — better performance under load, safer native module interfaces, and a foundation the framework can keep building on. There's no new API to learn for typical application work.
What this means for an existing app
This is where the real work is, and it's almost entirely about dependencies.
Your own code is usually fine. Standard components, standard hooks, standard navigation — these carry over.
Your native dependencies are the problem. Any library with native code must be updated to support the New Architecture. Well-maintained popular libraries have been ready for a while. Unmaintained ones are where migrations stall, and it's common to discover that a package you depend on has had no commits in two years.
The realistic migration path:
- Inventory every dependency with native code. This is the actual scope of the migration, and doing it first prevents nasty surprises.
- Check each for New Architecture support. Most maintained libraries advertise it clearly.
- For unsupported ones, decide early — is there a maintained alternative, will you fork and patch it, or do you write a replacement? This decision drives the timeline more than anything else.
- Enable the interop layer if you need a staged migration. It lets old-architecture modules run alongside new ones, which makes an incremental path possible.
- Test on real low-end devices. The gains show up most under load, and so do the regressions.
Custom native modules you wrote yourself need porting to the Turbo Module spec. Mechanical work, but budget for it — you'll define the TypeScript interface and let Codegen produce the bindings.
Setting expectations honestly
The New Architecture improves smoothness under load, startup time in dependency-heavy apps, and type safety at the native boundary. Those are worthwhile.
It does not make a slow app fast. If your list is janky because you're re-rendering the whole thing on every keystroke, or you're loading full-resolution images into thumbnails, or you're doing heavy computation on the JS thread — those are application problems and they will survive the migration unchanged.
Profile before migrating. If your performance issues are in your own render logic, fix those first. You may find you don't need the migration urgently at all, and it's a much easier project once your app is actually well-behaved.
Building or migrating a React Native app?
We build React Native applications on the New Architecture and handle migrations including the dependency audit that determines whether it's a two-week or two-month project. Talk to us about app development.