React Native New Architecture explained: A practical guide

If you've been building mobile apps with React Native, or thinking about it for your next project, you've almost certainly come across the phrase ‘New Architecture’ at some point over the last couple of years. It's been discussed in conference talks, developer forums, and release notes, often accompanied by a flurry of technical terms like JSI, Fabric, TurboModules, and Hermes (nothing to do with the fashion brand).

Here's the thing though: the New Architecture actually is newsworthy, and not just in a marketing-hype kind of way. And, as of React Native 0.76, released in late 2024, it's enabled by default in all new projects. So, whether you're actively migrating an existing app or starting fresh, this is now the baseline.

This guide walks through what the New Architecture is, why it was necessary, what's actually changed under the hood, and what it means in practical terms for your app's performance and workflow.

First, a bit of history: the old architecture

React Native launched in 2015 with a clever premise: write your UI in JavaScript and React, and have it render as genuine native components on iOS and Android. No webview, no hybrid compromise, but actual native UI. That promise held up remarkably well for years, and the framework grew to power apps at companies like Meta, Microsoft, Shopify, and thousands of startups worldwide.

But the original architecture had structural limitations that became increasingly difficult to work around as apps grew more ambitious. JavaScript and native code (the actual iOS or Android layer) lived on completely separate threads. Every time your app needed to call a native feature (the camera, sensors, the file system, a custom animation), data had to be packaged up as JSON, passed across what was known as ‘the bridge,’ then unpacked on the native side.

This worked fine for simple apps. But the cracks started showing when apps needed to do something demanding, like process video frames in real time, run complex animations tightly synced with gestures, load large datasets, or handle rapid-fire updates. The bridge was asynchronous and serial by nature, so it could only pass one batch of messages at a time, and that became a bottleneck. Dropped frames, input lag, and stuttery animations were the symptoms. The bridge was the root cause, and its stability was starting to erode.

Meta's engineering teams had been aware of these limitations for years, and work on a replacement began long before most people heard about it. The result is what's now called the New Architecture.

What the New Architecture brings to the table

The New Architecture is a complete reimagining of how React Native's core systems communicate and render, and not a patch on top of the old one. There are four key components worth understanding: JSI, TurboModules, Fabric, and Hermes. They all work together, but each solves a distinct problem.

JSI

JSI stands for JavaScript Interface, and it's the foundational change that makes everything else possible. Instead of routing all communication through the bridge, JSI allows JavaScript to work with native C++ objects directly.

Think of it this way: the old system was like sending letters between two offices in the same building. Each letter had to be written out, packaged, sent through internal mail, received, opened, and read before anything happened. JSI is like giving both offices a shared whiteboard they can both read and write on simultaneously. The overhead practically disappears.

TurboModules

In the old system, every native module your app might use, whether it was Bluetooth, the camera, push notifications, or biometric authentication, was loaded into memory at startup, whether your app needed it right then or not. Just like apps loading on your laptop at start up by default. Yet on mobile, for large apps with many native modules, this contributed to sluggish launch times.

TurboModules fix this with something called lazy initialization. A module is loaded only when it's actually called for the first time, not beforehand. TurboModules are also built on JSI, so the calls themselves are faster and can be synchronous where that makes sense. They also provide stronger safety through TypeScript and Flow, which means fewer runtime surprises and bugs that are easier to catch.

Fabric

Fabric is the new rendering engine that replaces the old UI Manager. It's the part of React Native responsible for taking your React component tree and turning it into actual pixels on screen.

The old renderer had to calculate layout asynchronously and then hand instructions off to the native side, meaning another round-trip and delays. Fabric shares rendering logic across iOS and Android through a unified C++ core, and because it integrates with JSI, calculations can be synchronous. This is particularly significant for gestures and animations, where even a few milliseconds of delay creates a noticeably janky experience for the user.

Fabric also unlocks support for React's concurrent features (things like React.Suspense and useTransition), which allow React to prioritize which UI updates are urgent and which can wait. This brings React Native's rendering model much closer to what React on the web already supports.

Hermes

Hermes is Meta's own JavaScript engine, specifically built for React Native, and it's now the default engine for all new projects. Compared to the previously common JavaScriptCore engine, Hermes delivers faster app startup times, smaller bundle sizes, and better memory efficiency. This is partly because it can pre-compile JavaScript to bytecode ahead of time, rather than compiling it on the device as the app launches.

Hermes and JSI are designed to work in tandem, and many of the performance gains from the New Architecture use Hermes as the underlying runtime.

What this means in practice

All of this is interesting from a technical perspective, but the question that matters most for most teams is: what does this actually change about building apps? These are some performance improvements you’ll actually notice in the New Architecture:

• Smoother animations and gesture responses
• Faster cold start times
• More reliable, deterministic rendering (what you test is what users see)
• Real-time capabilities that were previously impractical, like live camera processing or high-frequency sensor data

For teams building data-heavy or interaction-rich apps, these improvements are meaningful. Apps that previously required workarounds or native modules to hit acceptable performance bars may work better right out of the box.

For simpler apps with mostly static screens, the impact is real, but less dramatic. That doesn't mean it's not worth migrating, but it's worth setting realistic expectations internally.

Where things stand today

React Native 0.76, which shipped in late 2024, was the milestone release that enabled the New Architecture by default. And since then, the ecosystem has caught up substantially. Most community libraries have been updated to be New Architecture compatible, and Expo (the most popular way to start and manage React Native projects) has built full support into its toolchain. So, new Expo apps created today default to the New Architecture.

The React Native team also introduced CodeGen, a tool that automatically generates type-safe bindings between JavaScript and native code based on TypeScript or Flow definitions. This reduces the manual effort and error-prone boilerplate that used to come with writing native modules, and it makes the boundary between JavaScript and native code much safer.

Migrating an existing app: what to know

If you're running an existing React Native app on the old architecture, migration is not a flip-a-switch operation, but it's also not as daunting as it might sound, especially if you're on a modern version of React Native. Here's what a sensible migration approach looks like:

• Check your third-party libraries - Any external tools or plugins your app relies on need to be compatible with the New Architecture. Most popular ones already are, but it's worth auditing before you start rather than discovering blockers later on.
• Don't try to do it all at once - If your app is running on an older version of React Native, upgrade in stages rather than jumping straight to the latest. Incremental steps are easier to troubleshoot, and each version has clear documentation on what changes.
• Measure before and after - Note how fast your app launches and how smooth key interactions feel before you start. That gives you a concrete baseline to compare against once the migration is done.
• Roll it out carefully for live apps - If you have a large, active user base, it's worth releasing the migrated version to a small percentage of users first. Watch how it behaves in the real world before pushing it to everyone.

The bottom line

React Native has come a long way from the framework developers used to recommend with a string of ‘but’s attached. The New Architecture fixes the core issues that gave it that reputation: apps start faster, animations run smoother, and the performance problems that used to frustrate teams are mostly gone.

If you're already on React Native, it's worth planning your migration sooner rather than later. The hard work of making the ecosystem ready has been done, and putting it off just makes it a bigger job down the line. If you're considering React Native for something new, this is honestly the best time to start.

And if you want a team that's been building React Native apps for years and knows this new landscape inside out, that's exactly what we do at Tapptitude. Get in touch and let's talk about your project.