React Native has been the backbone of cross-platform mobile development for many teams, including ours at StrikingWeb. But for years, its architecture carried a fundamental limitation: the bridge. Every communication between JavaScript and native code had to pass through an asynchronous bridge that serialized data as JSON, creating a bottleneck that limited performance, especially for gesture-heavy interactions and complex animations.
The New Architecture, which became the default in React Native 0.76 (released in late 2024), replaces this bridge with a fundamentally different approach. It is the most significant change to React Native's internals since the framework was created, and it has profound implications for the performance and capabilities of cross-platform mobile applications.
The Old Architecture: Understanding the Bridge
To appreciate what the New Architecture changes, you need to understand what it replaces. In the old architecture, React Native had three threads:
- JavaScript thread: Runs your React components and business logic
- Native/UI thread: Handles native view rendering and user interactions
- Shadow thread: Calculates layout using Yoga (a cross-platform layout engine)
These threads communicated through the bridge — an asynchronous message queue that serialized all data as JSON. When a user tapped a button, the touch event was serialized to JSON, sent across the bridge to the JavaScript thread, processed, and the resulting UI update was serialized back to JSON and sent to the native thread. This round trip introduced latency and made it impossible to synchronize JavaScript and native operations precisely.
The consequences were visible to users: gestures felt slightly delayed compared to native apps, complex animations could drop frames, and interactions that required tight coordination between JavaScript and native code were difficult to implement smoothly.
The JavaScript Interface (JSI)
The foundation of the New Architecture is the JavaScript Interface, or JSI. JSI replaces the bridge with a direct interface between JavaScript and C++ code. Instead of serializing data as JSON and passing it through a message queue, JavaScript can now hold direct references to C++ objects and call methods on them synchronously.
This is a fundamental shift. With JSI:
- Synchronous calls are possible: JavaScript can call native functions and get results immediately, without waiting for an asynchronous bridge response
- No serialization overhead: Data is shared directly through memory, eliminating the JSON serialization/deserialization cost
- Engine agnostic: JSI abstracts the JavaScript engine interface, so React Native can use Hermes, V8, or JavaScriptCore without changing application code
- Direct memory sharing: JavaScript and native code can share data structures in memory, enabling zero-copy data transfer for performance-critical scenarios
Fabric: The New Rendering System
Fabric is the New Architecture's rendering system, replacing the old UI manager. Built on top of JSI, Fabric brings several transformative capabilities:
Synchronous Layout
In the old architecture, layout was calculated asynchronously on the shadow thread. Fabric performs layout calculations synchronously when needed, which means that measurements are available immediately. This eliminates an entire class of bugs where components would flash or shift during the initial render because layout data was not yet available.
Concurrent Rendering Support
Fabric is designed to work with React's concurrent features, including startTransition, Suspense, and automatic batching. This means React Native applications can now use the same concurrent patterns that React web developers have been using:
- Interruptible rendering: Long-running render cycles can be interrupted by high-priority updates (like user input), ensuring that the UI remains responsive
- Suspense for data fetching: Components can suspend while waiting for data, showing fallback UI automatically
- Transition API: Mark state updates as non-urgent, allowing React to keep the current UI interactive while rendering the update in the background
Improved Threading Model
Fabric allows rendering operations to occur on multiple threads simultaneously and even synchronously on the main thread when necessary. This flexibility enables features like synchronous gestures and layout-driven animations that were impossible with the old architecture.
"With Fabric, React Native apps can achieve the kind of fluid, 60fps interactions that users expect from native applications — the performance gap has narrowed dramatically."
TurboModules: Faster Native Module Access
TurboModules replace the old Native Modules system with a JSI-based approach that offers several advantages:
Lazy Loading
In the old architecture, all native modules were initialized at app startup, even if they were never used. TurboModules are loaded lazily — they are only initialized when first accessed. For applications with many native modules, this significantly reduces startup time.
Synchronous Access
Because TurboModules use JSI, JavaScript can call native module methods synchronously when needed. This is critical for operations where the result must be available immediately, such as reading device orientation during a gesture or accessing clipboard contents.
Type Safety with Codegen
TurboModules use a code generation system (Codegen) that reads TypeScript or Flow type definitions and generates native interfaces automatically. This provides type safety across the JavaScript-native boundary and catches errors at build time rather than runtime.
A TurboModule specification looks like this:
// NativeCalculator.ts
import { TurboModule, TurboModuleRegistry } from "react-native"
export interface Spec extends TurboModule {
multiply(a: number, b: number): number;
getDeviceName(): string;
}
export default TurboModuleRegistry.getEnforcing<Spec>("Calculator")
The Codegen processes this specification and generates the corresponding native interface code for both iOS (Objective-C++) and Android (Java/Kotlin), ensuring that the native implementation matches the JavaScript contract.
Practical Impact: What We Have Seen
After migrating several client applications to the New Architecture, we have observed measurable improvements:
- Startup time: 15 to 25 percent faster app startup, primarily from lazy loading of TurboModules
- Animation smoothness: Gesture-driven animations and transitions now consistently hit 60fps, where previously they would drop to 30-40fps under load
- Memory usage: Reduced memory overhead from elimination of JSON serialization buffers and more efficient native module management
- List performance:
FlatListandSectionListscrolling is noticeably smoother, particularly for lists with complex item layouts - Developer experience: Better error messages when native modules are misconfigured, thanks to Codegen's type checking
Migration Considerations
Migrating to the New Architecture requires attention to several areas:
Third-Party Library Compatibility
The most significant migration challenge is third-party library compatibility. Libraries that use the old Native Modules API need to be updated to support TurboModules. The React Native community has made excellent progress — most popular libraries now support the New Architecture — but if your app depends on less-maintained libraries, you may need to find alternatives or contribute updates.
Custom Native Modules
If you have built custom native modules, they need to be rewritten as TurboModules. The Codegen system simplifies this process, but the migration requires understanding both the old and new APIs. We recommend migrating one module at a time, verifying functionality after each migration.
Bridged vs Bridgeless Mode
The New Architecture supports a bridgeless mode that completely removes the old bridge. However, during the transition period, it also supports an interoperability mode where old-style native modules and Fabric components can coexist. We recommend starting with interoperability mode and moving to bridgeless once all dependencies support the New Architecture.
The Competitive Landscape
The New Architecture addresses many of the criticisms that drove teams to consider alternatives like Flutter. With synchronous native access, concurrent rendering, and dramatically improved animation performance, React Native's technical capabilities are now more competitive than ever. The advantage of sharing code and knowledge with React web development remains a powerful differentiator for teams that build both web and mobile applications.
That said, Flutter continues to excel in certain areas — particularly in custom rendering and pixel-perfect design consistency across platforms. The right choice depends on your team's expertise, your application's requirements, and your broader technology strategy.
Getting Started with the New Architecture
For new React Native projects, the New Architecture is the default starting point as of React Native 0.76. For existing projects, we recommend a phased migration approach:
- Phase 1: Audit your dependencies for New Architecture compatibility
- Phase 2: Enable the New Architecture in a development build and run your test suite
- Phase 3: Migrate custom native modules to TurboModules one at a time
- Phase 4: Enable bridgeless mode once all dependencies are compatible
At StrikingWeb, our mobile development team has migrated multiple production applications to the New Architecture and is ready to help you navigate the transition. Whether you are building a new React Native application or upgrading an existing one, the New Architecture represents a meaningful step forward in cross-platform mobile development.