{"id":14418,"date":"2026-04-22T18:30:00","date_gmt":"2026-04-22T18:30:00","guid":{"rendered":"https:\/\/dianapps.com\/blog\/?p=14418"},"modified":"2026-05-27T11:44:33","modified_gmt":"2026-05-27T11:44:33","slug":"react-native-new-architecture","status":"publish","type":"post","link":"https:\/\/dianapps.com\/blog\/react-native-new-architecture\/","title":{"rendered":"React Native New Architecture: What Changed in 2025\u20132026?"},"content":{"rendered":"

<\/span>Introduction<\/span><\/h2>\n

For most of React Native’s first decade, its architecture had a fundamental flaw that every developer learned to work around: the bridge.<\/p>\n

Every interaction between JavaScript and native code had to pass through an asynchronous message queue, serialize data to JSON, cross to a separate thread, and deserialize on the other side. It worked. But it was never fast, it scaled poorly under heavy UI load, and it made certain performance-critical features , real-time animations, synchronous layout reads, concurrent rendering genuinely difficult to build.<\/p>\n

The React Native New Architecture is the fix. And in 2025\u20132026, it stopped being optional.<\/p>\n

React Native 0.76 made the New Architecture the default in late 2024. React Native 0.82 (October 2025) permanently disabled the old architecture, there is no flag to turn it off. The legacy bridge was frozen in June 2025, receiving no further updates or bug fixes. As of Expo SDK 55 (React Native 0.83), the New Architecture is always enabled, full stop.<\/p>\n

This post explains what actually changed, why it matters for apps you’re building or maintaining today, and what the migration looks like in practice.<\/p>\n

TL;DR:<\/strong> React Native’s New Architecture replaces the async bridge with JSI (direct C++ calls), Fabric (concurrent renderer), TurboModules (lazy-loaded native modules), and Codegen (auto-generated type bindings). The legacy architecture was permanently disabled in React Native 0.82 (October 2025). Production migrations show 43% faster cold starts, 39% faster rendering, and 26% lower memory usage. React 19 and Hermes V1 are now fully integrated.<\/p><\/blockquote>\n

<\/span>The Legacy Bridge: What It Was and Why It Had to Go?<\/span><\/h2>\n

In the original React Native architecture, JavaScript and native code lived on completely separate threads. Communication between them worked like this:<\/p>\n

    \n
  1. JavaScript called a native function<\/li>\n
  2. The call was serialized into a JSON string<\/li>\n
  3. The JSON was sent across a bridge thread (asynchronous \u2014 no return value was possible)<\/li>\n
  4. The native side deserialized the JSON, executed the function, serialized the result back to JSON<\/li>\n
  5. The result crossed the bridge again, back to JavaScript<\/li>\n<\/ol>\n

    This design was pragmatic. It decoupled JavaScript from native code and made React Native portable. But it created a set of problems that compounded as apps got more complex.<\/p>\n

    Read More- Create a React Native App Without Expo<\/a><\/p>\n

    <\/span>Legacy Bridge: The Core Problems<\/span><\/h3>\n
    \n
    \n\n\n\n\n\n\n\n\n\n\n
    Problem<\/th>\nTechnical Cause<\/th>\nUser-Visible Symptom<\/th>\n<\/tr>\n<\/thead>\n
    Serialization overhead<\/strong><\/td>\nEvery JS-to-native call required JSON encode\/decode<\/td>\nStutters on rapid UI updates<\/td>\n<\/tr>\n
    Asynchronous-only<\/strong><\/td>\nNo synchronous calls possible<\/td>\nWorkarounds needed for layout reads, gestures<\/td>\n<\/tr>\n
    Bridge congestion<\/strong><\/td>\nHigh call volume created a queue bottleneck<\/td>\nDropped frames under load<\/td>\n<\/tr>\n
    No concurrent rendering<\/strong><\/td>\nIncompatible with React 18 concurrent features<\/td>\nuseTransition, Suspense didn’t work properly<\/td>\n<\/tr>\n
    Eager module loading<\/strong><\/td>\nAll native modules initialized at startup, even unused ones<\/td>\nSlow cold start on every launch<\/td>\n<\/tr>\n
    No type safety<\/strong><\/td>\nJS and native type mismatches only caught at runtime<\/td>\nRuntime crashes from interface drift<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n

    The bridge wasn’t just slow – it was architecturally incompatible with where React was heading. React 18’s concurrent rendering model requires the ability to interrupt, pause, and resume rendering. The old bridge’s asynchronous, fire-and-forget model couldn’t support that.<\/p>\n

    <\/span>The Four Pillars of the New Architecture<\/span><\/h2>\n

    The New Architecture is built on four interdependent components that together replace everything the bridge used to do.<\/p>\n

    \n
    \n\n\n\n\n\n\n\n\n
    Component<\/th>\nWhat It Replaces<\/th>\nWhat It Adds<\/th>\n<\/tr>\n<\/thead>\n
    JSI (JavaScript Interface)<\/strong><\/td>\nThe async bridge<\/td>\nDirect synchronous C++ calls between JS and native<\/td>\n<\/tr>\n
    Fabric<\/strong><\/td>\nThe legacy UI manager<\/td>\nConcurrent renderer, synchronous layout reads, React 18\/19 support<\/td>\n<\/tr>\n
    TurboModules<\/strong><\/td>\nLegacy NativeModules<\/td>\nLazy initialization, type-safe specs, JSI-backed performance<\/td>\n<\/tr>\n
    Codegen<\/strong><\/td>\nManual type definitions<\/td>\nAuto-generated type-safe bindings from TypeScript specs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n

    They’re not independent \u2014 they compose. JSI is the foundation everything else builds on. Fabric and TurboModules are built on top of JSI. Codegen generates the bindings that make TurboModules type-safe. Pull any one of these out and the system doesn’t work.<\/p>\n

    Read More- Building a Robust React Native Foundation for Complex Apps<\/a><\/p>\n

    <\/span>JSI: JavaScript Interface – The Foundation<\/span><\/h2>\n

    JSI is the most significant change in the entire New Architecture. Every other improvement depends on it.<\/p>\n

    What JSI does:<\/strong> It gives JavaScript a direct reference to C++ host objects \u2014 without any serialization, without any message queue, without any async handoff.<\/p>\n

    What this means in practice:<\/strong> JavaScript can now call native functions synchronously, the same way it calls any other function. There’s no bridge to cross. No JSON to encode or decode. No thread hop.<\/p>\n

    \/\/ This was IMPOSSIBLE with the old bridge \u2014 synchronous native calls didn't exist\r\nconst model = NativeDeviceInfo.getDeviceModel(); \/\/ returns immediately \/\/ With the old bridge, you had to do this:\r\nNativeDeviceInfo.getDeviceModel((model) => { \/\/ callback-based, asynchronous, delayed\r\n});<\/code><\/pre>\n
    <\/span>JSI vs The Bridge: Side-by-Side<\/span><\/h3>\n
    \n
    \n\n\n\n\n\n\n\n\n\n\n\n
    Dimension<\/th>\nLegacy Bridge<\/th>\nJSI<\/th>\n<\/tr>\n<\/thead>\n
    Call mechanism<\/strong><\/td>\nAsync message passing<\/td>\nSynchronous direct C++ reference<\/td>\n<\/tr>\n
    Data format<\/strong><\/td>\nJSON serialization<\/td>\nNo serialization \u2014 direct memory access<\/td>\n<\/tr>\n
    Thread model<\/strong><\/td>\nSeparate bridge thread<\/td>\nIn-process, no thread overhead<\/td>\n<\/tr>\n
    Performance overhead<\/strong><\/td>\n10\u00d7 vs native<\/td>\nNear-native \u2014 JSI eliminates 10\u00d7 overhead<\/td>\n<\/tr>\n
    Synchronous calls<\/strong><\/td>\nNot possible<\/td>\nFully supported<\/td>\n<\/tr>\n
    React Concurrent features<\/strong><\/td>\nIncompatible<\/td>\nFully compatible<\/td>\n<\/tr>\n
    Memory model<\/strong><\/td>\nCopies across boundary<\/td>\nShared memory, no copies<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n
    The JSI change alone unlocked an entire category of high-performance apps that were genuinely not feasible with the old bridge. Real-time gesture tracking, synchronous layout measurements, concurrent UI updates \u2014 all become clean implementations instead of workarounds.<\/p>\n
    <\/span>Fabric: The New Rendering Engine<\/span><\/h2>\n
    Fabric is React Native’s new renderer. It replaces the legacy UIManager and is written primarily in C++, which allows it to share core logic across Android and iOS for the first time.<\/p>\n
    The key design goal of Fabric was to align React Native’s rendering with React’s concurrent model \u2014 making Suspense, useTransition, automatic batching, and useLayoutEffect work the same way in React Native as they do on the web.<\/p>\n
    <\/span>What Fabric Changes About Rendering?<\/span><\/h3>\n
    \n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Feature<\/th>\nLegacy Renderer<\/th>\nFabric<\/th>\n<\/tr>\n<\/thead>\n
    Rendering model<\/strong><\/td>\nAsynchronous, no interruption<\/td>\nConcurrent \u2014 can pause, resume, prioritize<\/td>\n<\/tr>\n
    React 18\/19 features<\/strong><\/td>\nPartial\/broken<\/td>\nFull support (Suspense, Transitions, batching)<\/td>\n<\/tr>\n
    Layout reads<\/strong><\/td>\nAsynchronous only<\/td>\nSynchronous when needed (useLayoutEffect works correctly)<\/td>\n<\/tr>\n
    Shared C++ core<\/strong><\/td>\nSeparate Android\/iOS implementations<\/td>\nUnified C++ core across platforms<\/td>\n<\/tr>\n
    Shadow tree<\/strong><\/td>\nJS-side only<\/td>\nShared between JS and native (immutable snapshots)<\/td>\n<\/tr>\n
    useTransition<\/strong><\/td>\nNot supported<\/td>\nFully supported<\/td>\n<\/tr>\n
    Suspense for data fetching<\/strong><\/td>\nNot supported<\/td>\nFully supported<\/td>\n<\/tr>\n
    Automatic batching<\/strong><\/td>\nManual batching required<\/td>\nAutomatic for all state updates<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n
    <\/span>What This Means for Your UI?<\/span><\/h3>\n
    If you’ve been using React hooks and patterns from the web ecosystem, Fabric makes them work correctly in React Native. useTransition<\/code> lets you mark state updates as non-urgent \u2014 the UI stays responsive while heavy work runs in the background. Suspense boundaries work for data fetching, not just code splitting. useLayoutEffect<\/code> runs synchronously before paint, which makes tooltip positioning and conditional rendering based on measurements correct for the first time.<\/p>\n
    <\/span>TurboModules: Lazy, Type-Safe Native Modules<\/span><\/h2>\n
    TurboModules replace the legacy NativeModules system. They solve two separate problems: performance and type safety.<\/p>\n
    Performance:<\/strong> In the old system, every native module was initialized at app startup \u2014 even modules you’d never use in a given session. For large apps with dozens of native modules, this was a meaningful source of startup latency. TurboModules load lazily: a module initializes only when it’s first accessed.<\/p>\n
    Type safety:<\/strong> Legacy NativeModules relied on manual, runtime-checked interfaces. Type mismatches between JavaScript and native code only surfaced when the code actually ran. TurboModules use typed specs \u2014 TypeScript interfaces that define the exact contract between JS and native, verified at build time by Codegen.<\/p>\n
    <\/span>Legacy NativeModules vs TurboModules<\/span><\/h3>\n
    \n
    \n\n\n\n\n\n\n\n\n\n\n
    Dimension<\/th>\nLegacy NativeModules<\/th>\nTurboModules<\/th>\n<\/tr>\n<\/thead>\n
    Initialization<\/strong><\/td>\nEager \u2014 all modules at startup<\/td>\nLazy \u2014 only when first called<\/td>\n<\/tr>\n
    Communication<\/strong><\/td>\nVia bridge (async, serialized)<\/td>\nVia JSI (synchronous or async, no serialization)<\/td>\n<\/tr>\n
    Type safety<\/strong><\/td>\nRuntime type checking only<\/td>\nBuild-time type verification via Codegen<\/td>\n<\/tr>\n
    Startup impact<\/strong><\/td>\nAll modules contribute to cold start<\/td>\nOnly accessed modules contribute<\/td>\n<\/tr>\n
    Synchronous calls<\/strong><\/td>\nNot possible<\/td>\nFully supported<\/td>\n<\/tr>\n
    Performance<\/strong><\/td>\n10\u00d7 bridge overhead<\/td>\nNear-native direct access<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n
    \/\/ TurboModule spec \u2014 TypeScript interface verified at build time\r\nexport interface Spec extends TurboModule { \/\/ Synchronous \u2014 impossible with the old bridge getDeviceModel(): string; \/\/ Async \u2014 works as before, but without bridge overhead getBatteryLevel(): Promise<number>; getStorageInfo(): Promise<{ total: number; available: number }>;\r\n} export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo');<\/code><\/pre>\n
    <\/span>Codegen: Auto-Generated Type Safety<\/span><\/h2>\n
    Codegen is the automation layer that makes TurboModules and Fabric components type-safe without manual boilerplate. It reads your TypeScript (or Flow) specs and generates the native binding code automatically.<\/p>\n
    What Codegen generates:<\/strong><\/p>\n