“So… should I finally move to the new architecture?”
This question has been crawling every React Native developer’s mind for quite a while. Why? Because recently Meta released React Native 0.80 on 12 June, and with that they also announced:
"The Legacy Architecture of React Native is now officially frozen, and you’ll start seeing warnings for APIs that will stop working once we fully sunset the Legacy Architecture."
Source
This marks a huge milestone in the React Native journey. And if you are building apps today, or maintaining older ones, it's time to get familiar with what this new architecture brings, how it works, and what it means for your codebase.
In this post, we’ll walk through the core ideas behind the new architecture, demystify the jargon, and talk honestly about whether (and when) you should adopt it.
Let’s dig in.
Why Did React Native Need a New Architecture?
Assuming you know how React Native works, we are first going to understand the "why" behind the new architecture, it helps to take a quick look at how things used to work under the hood.
React Native's original architecture relied on a bridge to let JavaScript talk to native modules. It worked by serializing messages (like UI updates, API calls, etc.) and sending them across the bridge asynchronously. While this was a clever solution back in 2015, it's shown its age over the years.
Here are some of the biggest issues developers ran into:
Asynchronous communication caused noticeable UI lag, especially in animations or high-frequency updates.
Large data transfers across the bridge required JSON serialization, which introduced overhead and complexity.
Native modules had to be eagerly loaded during app startup, which slowed down launch times.
Debugging and profiling native code were often frustrating and disconnected from the JavaScript side.
The React Native team recognized these limitations and decided to rebuild the core of the framework to better align with modern JavaScript and native performance expectations.
Thus, a new architecture built on JSI (JavaScript Interface) for direct communication, Fabric for rendering, and Turbomodules for smarter native module loading came into existence.
This upgrade proved to be a foundational change. So what are these pieces, and how do they work together? Let’s break them down next.
Key Concepts Made Simple
React Native's new architecture introduces three core components: JSI, Fabric, and TurboModules.
Let’s break each one down without assuming you’ve got a background in native internals.
JSI (JavaScript Interface)
Think of JSI as the new way JavaScript talks to native code, without the bridge.
In the old architecture, communication between JavaScript and native modules had to go through a serializing bridge, often creating performance bottlenecks. JSI replaces that with a C++ interface that lets JavaScript interact with native objects directly, synchronously, and without serialization overhead.
Why this matters:
It’s faster — no more async back-and-forth for every interaction.
You can write native modules in C++ and expose them easily to JS.
It opens the door to multi-language support beyond Objective-C and Java/Kotlin.
Fabric
Fabric is the new rendering system in React Native. It reimagines how the UI is managed and rendered.
Under the legacy system, React Native used a somewhat detached system for rendering native views. Fabric brings React Native's rendering closer to how React itself works on the web by supporting concurrent rendering, fine-grained updates, and better scheduling.
What you get with Fabric:
Better UI responsiveness (smoother animations, faster interactions)
Cleaner rendering pipeline with better debugging tools
Native view trees that are easier to sync with JS
It also introduces a new concept called the Shadow Tree, which mirrors the native view hierarchy and enables smarter layout updates.
TurboModules
TurboModules change how native modules are loaded and accessed.
Previously, all native modules were eagerly initialized when the app started, whether you used them or not. That's not great for startup time or memory usage.
TurboModules are loaded lazily and accessed via JSI, which means:
Faster cold starts
Less memory consumption
Better scalability as your app grows
From a developer's perspective, you'll eventually write TurboModules instead of the older NativeModules, and the new system will handle loading them only when needed.
Putting It All Together
JSI is the enabler: it lets JS talk to native code directly.
Fabric makes rendering smarter and UI performance smoother.
TurboModules modernize how native functionality is bundled into your app.
Together, they replace the bridge-heavy asynchronous model with something faster, leaner, and more in synch with the evolution of both React and mobile platforms.
What Changes for Developers?
At this point, you might be wondering:
“Okay, cool architecture stuff—but how does this affect me when I’m actually building apps?”
Fair question. The new architecture doesn't rewrite how you write React Native apps on the surface; your View, Text, FlatList, and useEffect will still look the same. But under the hood, a few key things are changing that you'll want to keep in mind.
Here’s what you’ll notice as a developer:
1. You Have to Opt Into It (For Now)
As of React Native 0.80, the new architecture is stable, but it's not automatically turned on. You need to enable it manually in your build configs (app/build.gradle, Podfile, etc.).
That means:
You can migrate gradually.
You can test new features while keeping older parts of your codebase untouched.
You’ll need to understand how to enable Fabric and TurboModules per package or module.
2. Custom Native Modules Need Updating
If your app relies on custom native modules (or third-party ones that haven't yet been updated), you may run into compatibility issues.
To make them work with the new system, they'll need:
JSI bindings instead of relying on the old bridge
Lazy loading patterns (for TurboModules)
Updated codegen configs for type-safe, auto-linked APIs
Some community packages already support the new system, but not all do yet. It's worth checking.
3. Better Performance, But Gradually
Don't expect huge FPS gains on day one unless your app already suffers from bridge-heavy interactions.
The new architecture sets the stage for better performance:
Fewer dropped frames during animations
Faster rendering of complex layouts
Smoother native integrations (like camera, maps, etc.)
But it really shines when combined with Concurrent React and modern design patterns. That's where things like deferred rendering and interruptible updates start to matter.
4. New Tools & Debugging Strategies
Fabric and JSI introduce new ways to inspect, debug, and optimize your app.
For example:
You can use Systrace and Flipper plugins that are new-arch aware.
The layout engine behaves slightly differently, so debugging UI issues may require learning how the Shadow Tree and Yoga layout engine now interact.
5. Codegen Brings Type Safety
One subtle but exciting part of the new system is codegen, React Native can now generate native bindings from TypeScript or Flow type definitions.
Why this matters:
Less boilerplate when writing native modules
Type-safe integration across JS and native
Consistent, auto-linked modules without manual setup
Should You Adopt the New Architecture Now?
Short answer: It depends on your project’s current needs, dependencies, and how close you are to the native layer.
The long answer? Let’s break it down.
You Should Consider Adopting It If:
You are starting a new React Native project and want long-term support and performance benefits.
Your app relies on high-performance UI, like animations, camera modules, or custom native views.
You are comfortable updating your native build configs and exploring new tools (like codegen and JSI).
Your core dependencies (or your own native modules) already support the new architecture.
Starting fresh with the new system means you won’t have to migrate later, and you'll be future-proofed as the ecosystem evolves.
You Might Wait a Bit If:
You are maintaining a mature codebase with lots of legacy native modules or unmaintained third-party packages.
You have tight deadlines or limited bandwidth, migrating isn't hard, but it's not zero-effort either.
Your app doesn't currently suffer from performance issues related to the bridge or native module loading.
In this case, it’s totally reasonable to hold off. The legacy system is reliable and have maintained for years.
What’s the Middle Ground?
If you're unsure, you can opt into the new architecture gradually:
Start by enabling Fabric and TurboModules in a dev build.
Migrate one module or feature at a time.
Final Thoughts
If you are new to the ecosystem, don't worry about mastering it all at once. The core concepts still apply, and most of your React Native knowledge remains valid. Just keep this new direction on your radar as you build.
This is your cue to start experimenting if you're experienced. You might even port a screen or module to use Fabric or a TurboModule. The community is making steady progress, the documentation is getting better, and the tooling is ready.
If you understand the new architecture, you'll be better able to build React apps that are faster, smoother, and feel more native, regardless of whether you decide to implement it now or in the upcoming quarter.
Top comments (0)