React Native New Architecture in 2026: Hermes V1, Bridgeless Mode and Interview Questions

React Native New Architecture reached full maturity in 2026. With React Native 0.84 shipping Hermes V1 as the default engine and 0.85 removing every trace of the legacy bridge, the framework now delivers near-native performance without requiring developers to think about architecture flags or compatibility layers.

What Changed in React Native's Architecture Stack

The old React Native architecture relied on a single-threaded asynchronous JSON bridge to pass messages between JavaScript and native code. Every interaction crossed this bottleneck: touch events, layout calculations, module calls. The New Architecture replaces each layer of this pipeline with a direct, synchronous alternative.

| Layer | Old Architecture | New Architecture | |-------|-----------------|------------------| | JS Engine | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderer | Paper (async bridge) | Fabric (synchronous, shared C++) | | Native Modules | Bridge Modules (JSON serialization) | TurboModules (JSI, direct calls) | | Communication | Async JSON Bridge | JSI (JavaScript Interface) | | Initialization | Bridge init + module registration | Bridgeless (lazy, on-demand) |

JSI (JavaScript Interface) is the foundation. Instead of serializing every call to JSON and passing it through a queue, JSI exposes C++ host objects directly to JavaScript. A TurboModule call that previously required JSON encoding, bridge queuing, and JSON decoding now completes as a direct function invocation.

Hermes V1: The Default JavaScript Engine

Hermes V1 became the default engine in React Native 0.84, released in February 2026. This represents a full rewrite of the compiler and VM, not just an incremental update over the previous Hermes versions.

The improvements span four areas: a rewritten compiler with a new bytecode format, an improved JIT compiler, the Hades concurrent garbage collector, and better support for modern JavaScript patterns used by React 19.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

Hades, the concurrent garbage collector, deserves specific attention. Previous Hermes versions used a stop-the-world GC that occasionally caused visible jank during list scrolling. Hades runs collection concurrently on a background thread, keeping GC pauses under 12ms. For apps rendering long lists with complex cells, this eliminates the last source of JavaScript-side frame drops.

Fabric Renderer: Synchronous Layout and Rendering

Fabric replaces the Paper renderer with a C++ core shared between iOS and Android. The critical difference: layout calculations happen synchronously on the JavaScript thread instead of asynchronously through the bridge.

This synchronous model enables two capabilities that were impossible with Paper:

1. Concurrent rendering support: Fabric integrates with React 19's concurrent features. Transitions, Suspense boundaries, and useTransition work correctly because Fabric can interrupt and resume rendering.

2. Direct C++ layout: Yoga (the layout engine) executes in the same memory space as the JavaScript runtime. No serialization overhead for flexbox calculations.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

The useTransition hook in this example demonstrates why Fabric matters. With Paper, startTransition had no effect because the renderer could not interrupt an in-progress render. Fabric's integration with React 19 concurrent mode makes deferred updates work as designed, keeping the text input responsive while filtering thousands of items in the background.

TurboModules and JSI: Eliminating Serialization Overhead

TurboModules replace the old NativeModules system. The performance difference comes from eliminating JSON serialization entirely. A bridge module call followed this path: JS object -> JSON.stringify -> bridge queue -> JSON.parse -> native call -> JSON.stringify -> bridge queue -> JSON.parse -> JS callback. A TurboModule call is a direct C++ function invocation through JSI.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

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

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

The key detail: getDeviceModel(), getOSVersion(), and getBatteryLevel() are synchronous. The JavaScript thread calls directly into native code and receives the return value on the same tick. No promises, no callbacks, no bridge round-trip. This is only possible through JSI.

Bridgeless Mode: What It Removes and Why It Matters

Bridgeless Mode, introduced in React Native 0.73 and made default in 0.74, completes the architecture migration by removing the bridge initialization entirely. Even after Fabric and TurboModules were adopted, the old bridge still initialized at startup to handle global event emitters, timers, and error handling. Bridgeless Mode moves these remaining systems to JSI-based implementations.

The practical impact:

• Faster startup: No bridge initialization overhead. The runtime bootstraps only what the app actually uses through lazy loading.
• Reduced memory: No bridge data structures allocated at startup.
• Cleaner error handling: Error boundaries and global error handlers work through the new architecture without bridge fallbacks.

React Native 0.82 permanently disabled the old bridge. React Native 0.85, released in April 2026, removed all remaining bridge-related code from the codebase. There is no fallback path.

Production Migration: Real-World Performance Benchmarks

Production migrations from the old architecture to the New Architecture show consistent improvements across the key metrics:

| Metric | Old Architecture | New Architecture | Improvement | |--------|-----------------|------------------|-------------| | Cold start (TTI) | 1.4s | 0.8s | 43% faster | | Screen transition | 180ms | 110ms | 39% faster | | Memory baseline | 89MB | 66MB | 26% lower | | JS-to-native call | ~5ms (async) | ~0.1ms (sync) | 40x faster | | GC max pause | 45ms | 12ms | 73% shorter | | FlatList scroll (1000 items) | Occasional jank | Smooth 60fps | No dropped frames |

The most impactful improvement for user-facing quality is the GC pause reduction. Hades keeps collection pauses under one frame budget (16.6ms at 60fps), eliminating the most common source of visible jank in complex React Native apps.

Ecosystem Compatibility in 2026

The ecosystem has fully converged on the New Architecture. Expo SDK 55 and later run exclusively on the New Architecture, with no option to disable it. Key library compatibility:

• React Navigation 7.2+: Full Fabric support with native-stack screens
• Reanimated 3.5+: Shared animation backend with React Native 0.85
• Gesture Handler 2.16+: Direct JSI-based gesture recognition
• Vision Camera 4.0+: Frame processing through JSI
• Detox: E2E testing compatible with New Architecture

For teams using Expo, npx create-expo-app generates a project with the New Architecture enabled by default. No configuration needed.

Interview Questions: React Native New Architecture

These questions frequently appear in senior React Native interviews in 2026. Each answer covers the depth expected at a staff/senior level.

Q1: Explain the difference between the old Bridge and JSI. Why does JSI enable synchronous native calls?

The bridge serialized every JS-to-native message as JSON, pushed it onto an asynchronous queue, and deserialized it on the native side. JSI (JavaScript Interface) exposes C++ host objects directly in the JavaScript VM. Native functions registered through JSI appear as regular JavaScript functions that execute native code inline, without serialization or queuing. Synchronous calls are possible because JSI operates in the same thread context without an intermediate message queue.

Q2: What problem does the Fabric renderer solve that Paper could not?

Paper rendered asynchronously through the bridge, making it impossible to support React concurrent features. A startTransition call had no effect because Paper could not interrupt an in-progress render tree. Fabric implements rendering in shared C++ code, integrates directly with React 19's reconciler, and supports concurrent rendering, Suspense, and transitions. Layout calculations through Yoga also happen synchronously in the same memory space, eliminating the latency of cross-bridge layout.

Q3: Why is Hermes required for the New Architecture? Could another engine be used?

The New Architecture depends on JSI, which requires the JavaScript engine to support C++ host object registration. Hermes was designed from the ground up with JSI integration. JavaScriptCore could theoretically support JSI, but the official implementation and testing are built around Hermes. Hermes V1 additionally provides bytecode pre-compilation (eliminating runtime parsing), the Hades concurrent GC (sub-12ms pauses), and WebAssembly support, none of which are available through the React Native JSC integration.

Q4: How do TurboModules differ from the old NativeModules API from a developer's perspective?

TurboModules require a Codegen spec (a TypeScript interface extending TurboModule) that generates type-safe native bindings at build time. The old NativeModules used runtime reflection with no type checking. TurboModules support synchronous return values (not just promises), lazy initialization (modules load only when first accessed), and direct JSI calls without JSON serialization. The developer writes a TypeScript spec, runs Codegen, and implements the generated native interface.

Q5: Describe Bridgeless Mode and what it removes compared to having Fabric and TurboModules alone.

Even after adopting Fabric and TurboModules, the old bridge still initialized at startup to handle global event emitters, timers, error handling, and other runtime infrastructure. Bridgeless Mode replaces these remaining bridge-dependent systems with JSI-based implementations. It eliminates bridge initialization overhead, reduces baseline memory usage, and ensures the entire runtime operates through JSI. Since React Native 0.85, Bridgeless Mode is the only operating mode.

Practicing these questions with working code examples strengthens both conceptual understanding and practical recall. SharpSkill's React Native New Architecture module covers 40+ additional questions on Fabric, TurboModules, Hermes internals, and migration strategies.

Conclusion

• Hermes V1 delivers 29% faster cold starts, 38% lower memory, and sub-12ms GC pauses out of the box in React Native 0.84+
• Fabric enables React 19 concurrent features (transitions, Suspense) that Paper could never support
• TurboModules eliminate JSON serialization, making JS-to-native calls 40x faster through direct JSI invocation
• Bridgeless Mode removes the last bridge dependencies; React Native 0.85 has zero bridge code remaining
• The ecosystem is fully compatible: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+, and all major libraries support the New Architecture exclusively
• Interview preparation should focus on JSI mechanics, Fabric vs Paper trade-offs, TurboModule Codegen workflow, and Bridgeless Mode runtime changes