React Native New Architecture: JSI, Fabric & TurboModules

TL;DR

• JSI replaces the old async JSON bridge with synchronous C++ bindings, eliminating serialisation overhead
• Fabric is the new rendering system that aligns with React 18's concurrent features and reduces time-to-first-paint
• TurboModules load native modules lazily and expose typed interfaces, cutting app startup time
• The new architecture is stable in 2026 and most popular libraries have migrated, but legacy bridge compatibility is still available

Table of Contents

• Why the Old Architecture Was a Bottleneck
• JSI: The JavaScript Interface
• Fabric: The New Rendering System
• TurboModules: Lazy Loading Native Code
• Codegen: TypeScript to Native Type Safety
• Real Performance Improvements
• Enabling the New Architecture in Existing Apps
• Library Compatibility in 2026
• Frequently Asked Questions

Why the Old Architecture Was a Bottleneck

React Native's original architecture used an asynchronous bridge to communicate between JavaScript and native code. Every interaction between the two worlds followed this flow:

1. JavaScript creates a message (a JSON object describing what native code should do)
2. The message is serialised to a JSON string
3. The string is sent across the bridge to the native side
4. The native side deserialises the JSON
5. The native side executes the operation
6. The response follows the same path back

This worked, but it had three fundamental problems:

Serialisation cost: Converting complex objects to JSON and back for every frame update, gesture handler callback, and layout measurement added measurable overhead. On low-end Android devices, this cost was visible as frame drops during scrolling.

Asynchronous only: The bridge only supported async communication. If JavaScript needed a measurement from native (like a view's dimensions), it had to wait for the async roundtrip. This made synchronous gesture handling impossible without workarounds like react-native-gesture-handler and react-native-reanimated, which bypassed the bridge entirely.

Single-threaded bottleneck: All bridge messages funnelled through a single message queue. Heavy JavaScript execution (parsing a large JSON response, for example) blocked UI updates because the bridge could not process layout messages while JavaScript was busy.

JSI: The JavaScript Interface

JSI (JavaScript Interface) is a C++ layer that allows JavaScript to directly call native functions without serialisation. Think of it as replacing a REST API call with a direct function call.

With the old bridge:

JS: "Hey native, what is the width of View #42?"
Bridge: serialize -> queue -> deserialize
Native: "It is 320 pixels"
Bridge: serialize -> queue -> deserialize
JS: "Got it, now I can compute layout"

With JSI:

JS: nativeModule.getViewWidth(42) // returns 320 synchronously

JSI achieves this by exposing C++ host objects to the JavaScript runtime. These objects are real C++ instances that JavaScript can hold references to and call methods on directly. There is no JSON serialisation, no message queue, and no async waiting.

This is the same approach used by browser APIs. When JavaScript calls document.getElementById(), it does not send a JSON message to the rendering engine. It calls a C++ function directly through the V8/JSC bindings. JSI brings this same pattern to React Native.

What JSI Means for Developers

For most application developers, JSI is invisible. You do not interact with C++ host objects directly. Instead, JSI enables TurboModules and Fabric to work efficiently. However, if you write native modules, you can now expose synchronous APIs to JavaScript, which was impossible before.

Libraries like react-native-mmkv (key-value storage) use JSI directly to achieve synchronous reads and writes, making them significantly faster than AsyncStorage.

Fabric: The New Rendering System

Fabric is the renderer that replaced the old "Shadow Tree" architecture. It redesigns how React Native measures, lays out, and renders native views.

How Fabric Differs

Shadow tree in C++: The old architecture maintained a shadow tree in Java/Objective-C. Fabric moves it to C++, shared between JavaScript and native code. This eliminates the serialisation cost for layout operations.

Concurrent rendering: Fabric aligns with React 18's concurrent rendering model. It can prepare multiple versions of the UI simultaneously and commit the final version, enabling features like Suspense and startTransition in React Native.

Synchronous layout: With JSI powering the communication, Fabric can perform layout measurements synchronously. This eliminates the "layout flash" issue where components briefly appeared with wrong dimensions before the async measurement returned.

Priority-based rendering: Fabric can prioritise user-visible updates over background ones. A touch response gets higher priority than rendering an off-screen list item, reducing perceived latency.

TurboModules: Lazy Loading Native Code

The old native module system loaded every native module at app startup, regardless of whether the module was needed. If your app had 30 native modules but a particular screen only used 3, you still paid the initialisation cost for all 30.

TurboModules solve this with lazy loading. A native module is only initialised when JavaScript first requests it. This directly reduces app startup time, especially for apps with many dependencies.

TurboModule Definition

TurboModules use a TypeScript specification (via Codegen) to define the interface between JavaScript and native:

// NativeDeviceInfo.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceName(): string;
  getBatteryLevel(): Promise<number>;
  getStorageInfo(): {
    totalSpace: number;
    freeSpace: number;
  };
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo');

This TypeScript specification is processed by Codegen to generate native (Objective-C++ and Java/Kotlin) interface code, ensuring type safety across the boundary.

Codegen: TypeScript to Native Type Safety

Codegen is the tooling layer that reads your TypeScript module and component specifications and generates native code from them. Before Codegen, the shape of data crossing the bridge was validated at runtime (or not at all), which meant type mismatches caused cryptic native crashes.

With Codegen:

1. You define your native module interface in TypeScript
2. Codegen generates Objective-C++ headers and Java interfaces
3. Your native implementation conforms to these generated interfaces
4. Any mismatch between JavaScript types and native types causes a build error, not a runtime crash

This is a significant improvement for apps that use custom native modules for features like camera access, Bluetooth, or payment processing.

Real Performance Improvements

The new architecture delivers measurable improvements. Based on benchmarks published by the React Native team and independent testing:

Metric	Old Architecture	New Architecture	Improvement
App startup (30 modules)	1200ms	800ms	33% faster
Scroll frame drops (complex list)	8-12 per screen	1-3 per screen	~75% fewer
Bridge throughput	~10k msg/s	Direct calls	N/A (no bridge)
Layout measurement	Async (20-40ms)	Sync (<1ms)	~95% faster
Memory (native modules)	All loaded upfront	Lazy loaded	20-40% less

These numbers vary by app complexity, but the directional improvements are consistent.

When testing the API endpoints that your React Native app consumes, use our free API Request Tester to verify response payloads and latency before implementing the client-side code. Slow or malformed API responses are amplified by the rendering pipeline, so catching issues early saves debugging time.

For debugging JSON payloads from your backend, our JSON formatter and validator helps you inspect nested response structures before writing your TypeScript types.

Enabling the New Architecture in Existing Apps

For apps created with React Native 0.74+, the new architecture is enabled by default. For older apps, enabling it requires configuration changes:

Android (gradle.properties):

newArchEnabled=true

iOS (Podfile):

ENV['RCT_NEW_ARCH_ENABLED'] = '1'

After enabling, run pod install for iOS and rebuild. Be prepared for:

1. Native module compatibility issues: Some older native modules need updates to support TurboModules
2. Custom native view changes: Views using the old ViewManager pattern need migration to Fabric components
3. Event handling differences: Some edge cases in event propagation behave differently under Fabric

The general recommendation is to enable new architecture on a feature branch, run your full test suite, and identify breaking changes before merging.

Library Compatibility in 2026

As of early 2026, the new architecture ecosystem has matured significantly:

• react-native-reanimated: Full support since v3.5
• react-native-gesture-handler: Full support since v2.14
• react-native-screens: Full support
• react-navigation: Full support since v7
• react-native-svg: Full support
• react-native-maps: Full support
• react-native-camera: Replaced by react-native-vision-camera (full support)

The React Native Directory now shows new architecture compatibility status for each library, making it easy to audit your dependencies before enabling it.

For teams working with The Debuggers on React Native projects, we recommend enabling the new architecture for all new projects and planning migration for existing apps during the next major version upgrade.

For a broader comparison of how React Native stacks up against Flutter in 2026, read our Flutter vs React Native comparison.

Frequently Asked Questions

Is the React Native new architecture stable for production?

Yes. The new architecture has been stable since React Native 0.74 and is the default for new projects created with 0.76+. Major apps including Facebook, Instagram, and Shopify have been running on the new architecture in production. The remaining risks are primarily with older third-party libraries that have not migrated, so audit your dependency list before enabling. Most actively maintained libraries now support both architectures.

Do I need to rewrite my app to use the new architecture?

No. React Native maintains backward compatibility through an interop layer. Your existing JavaScript code and most React components work without changes. The migration effort is primarily on the native side: custom native modules need to adopt TurboModule interfaces, and custom native views need to support Fabric. If you only use JavaScript and third-party libraries, the migration is mostly a configuration change plus dependency updates.

How does JSI compare to Flutter's platform channels?

JSI is faster than Flutter's platform channels because it uses direct synchronous C++ calls. Flutter's platform channels are asynchronous and use binary message encoding (though they are efficient). However, Flutter rarely needs platform channels for UI rendering because it owns the entire render pipeline. JSI closes the performance gap that existed because React Native relies on native UI components, making the communication overhead more impactful.

Will the old bridge ever be removed?

The React Native team has indicated that the old bridge will be deprecated and eventually removed, but there is no firm removal date. The interop layer that allows old-style native modules to work with the new architecture will remain available for several major versions to give the ecosystem time to migrate fully. For new code, there is no reason to use the old bridge patterns.

---

Building a React Native app?

Test your mobile backend APIs instantly with our free API Request Tester. Send requests, inspect response headers, and validate JSON payloads directly from your browser before implementing the client-side code.

Need help migrating to the new architecture or building a React Native app from scratch? The Debuggers provides React Native development and consulting services for teams of all sizes.