React Native New Architecture 2026: Hermes V1, Bridgeless Mode und Interview-Fragen

Die React Native New Architecture hat 2026 ihre volle Produktionsreife erreicht. Mit React Native 0.84, das Hermes V1 als Standard-Engine ausliefert, und Version 0.85, die sämtliche Überreste der alten Bridge entfernt, liefert das Framework jetzt nahezu native Performance, ohne dass Entwickler sich mit Architektur-Flags oder Kompatibilitätsschichten befassen müssen.

Was sich im Architektur-Stack von React Native geändert hat

Die alte React Native Architektur basierte auf einer single-threaded, asynchronen JSON-Bridge, die Nachrichten zwischen JavaScript und nativem Code übermittelte. Jede Interaktion passierte diesen Engpass: Touch-Events, Layout-Berechnungen, Modulaufrufe. Die New Architecture ersetzt jede Schicht dieser Pipeline durch eine direkte, synchrone Alternative.

| Schicht | Alte Architektur | Neue Architektur | |---------|-----------------|------------------| | JS Engine | JavaScriptCore | Hermes V1 (Bytecode + JIT) | | Renderer | Paper (async Bridge) | Fabric (synchron, shared C++) | | Native Modules | Bridge Modules (JSON-Serialisierung) | TurboModules (JSI, direkte Aufrufe) | | Kommunikation | Async JSON Bridge | JSI (JavaScript Interface) | | Initialisierung | Bridge-Init + Modulregistrierung | Bridgeless (lazy, on-demand) |

JSI (JavaScript Interface) bildet das Fundament. Anstatt jeden Aufruf als JSON zu serialisieren und durch eine Queue zu senden, stellt JSI C++-Host-Objekte direkt für JavaScript bereit. Ein TurboModule-Aufruf, der zuvor JSON-Encoding, Bridge-Queuing und JSON-Decoding erforderte, wird nun als direkter Funktionsaufruf ausgeführt.

Hermes V1: Die Standard-JavaScript-Engine

Hermes V1 wurde mit React Native 0.84 im Februar 2026 zur Standard-Engine. Es handelt sich um eine vollständige Neuentwicklung von Compiler und VM, nicht nur ein inkrementelles Update der vorherigen Hermes-Versionen.

Die Verbesserungen erstrecken sich über vier Bereiche: einen neu geschriebenen Compiler mit neuem Bytecode-Format, einen verbesserten JIT-Compiler, den Hades Concurrent Garbage Collector und bessere Unterstützung moderner JavaScript-Patterns, die von React 19 verwendet werden.

// 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, der Concurrent Garbage Collector, verdient besondere Aufmerksamkeit. Frühere Hermes-Versionen verwendeten einen Stop-the-World-GC, der beim Scrollen durch Listen gelegentlich sichtbares Ruckeln verursachte. Hades führt die Collection nebenläufig auf einem Hintergrund-Thread aus und hält GC-Pausen unter 12ms. Für Apps, die lange Listen mit komplexen Zellen rendern, eliminiert dies die letzte Quelle JavaScript-seitiger Frame-Drops.

Fabric Renderer: Synchrones Layout und Rendering

Fabric ersetzt den Paper-Renderer durch einen C++-Kern, der zwischen iOS und Android geteilt wird. Der entscheidende Unterschied: Layout-Berechnungen finden synchron auf dem JavaScript-Thread statt, statt asynchron über die Bridge.

Dieses synchrone Modell ermöglicht zwei Fähigkeiten, die mit Paper unmöglich waren:

1. Concurrent-Rendering-Unterstützung: Fabric integriert sich mit den Concurrent-Features von React 19. Transitions, Suspense Boundaries und useTransition funktionieren korrekt, weil Fabric das Rendering unterbrechen und fortsetzen kann.

2. Direktes C++-Layout: Yoga (die Layout-Engine) wird im selben Speicherbereich wie die JavaScript-Runtime ausgeführt. Kein Serialisierungs-Overhead für Flexbox-Berechnungen.

// 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' },
})

Der useTransition-Hook in diesem Beispiel verdeutlicht, warum Fabric wichtig ist. Mit Paper hatte startTransition keine Wirkung, weil der Renderer ein laufendes Rendering nicht unterbrechen konnte. Fabrics Integration mit dem Concurrent Mode von React 19 sorgt dafür, dass verzögerte Updates wie vorgesehen funktionieren und das Textfeld reaktionsfähig bleibt, während tausende Einträge im Hintergrund gefiltert werden.

TurboModules und JSI: Eliminierung des Serialisierungs-Overheads

TurboModules ersetzen das alte NativeModules-System. Der Performance-Unterschied ergibt sich aus dem vollständigen Wegfall der JSON-Serialisierung. Ein Bridge-Module-Aufruf folgte diesem Pfad: JS-Objekt -> JSON.stringify -> Bridge-Queue -> JSON.parse -> nativer Aufruf -> JSON.stringify -> Bridge-Queue -> JSON.parse -> JS-Callback. Ein TurboModule-Aufruf ist ein direkter C++-Funktionsaufruf über 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"
}

Das entscheidende Detail: getDeviceModel(), getOSVersion() und getBatteryLevel() sind synchron. Der JavaScript-Thread ruft direkt nativen Code auf und erhält den Rückgabewert im selben Tick. Keine Promises, keine Callbacks, kein Bridge-Roundtrip. Dies ist nur durch JSI möglich.

Bridgeless Mode: Was entfernt wird und warum es wichtig ist

Bridgeless Mode, eingeführt in React Native 0.73 und Standard seit 0.74, vollendet die Architekturmigration, indem die Bridge-Initialisierung vollständig entfällt. Selbst nachdem Fabric und TurboModules übernommen wurden, initialisierte die alte Bridge noch beim Start, um globale Event-Emitter, Timer und Fehlerbehandlung zu verwalten. Bridgeless Mode migriert diese verbleibenden Systeme auf JSI-basierte Implementierungen.

Die praktischen Auswirkungen:

• Schnellerer Start: Kein Bridge-Initialisierungs-Overhead. Die Runtime bootstrappt nur das, was die App tatsächlich nutzt, durch Lazy Loading.
• Reduzierter Speicherverbrauch: Keine Bridge-Datenstrukturen werden beim Start allokiert.
• Sauberere Fehlerbehandlung: Error Boundaries und globale Error Handler funktionieren über die neue Architektur ohne Bridge-Fallbacks.

React Native 0.82 deaktivierte die alte Bridge dauerhaft. React Native 0.85, veröffentlicht im April 2026, entfernte sämtlichen verbleibenden Bridge-Code aus der Codebasis. Es gibt keinen Fallback-Pfad.

Produktionsmigration: Praxisnahe Performance-Benchmarks

Produktionsmigrationen von der alten zur neuen Architektur zeigen konsistente Verbesserungen bei den Schlüsselmetriken:

| Metrik | Alte Architektur | Neue Architektur | Verbesserung | |--------|-----------------|------------------|-------------| | Cold Start (TTI) | 1,4s | 0,8s | 43% schneller | | Bildschirmwechsel | 180ms | 110ms | 39% schneller | | Speicher-Baseline | 89MB | 66MB | 26% weniger | | JS-zu-Native-Aufruf | ~5ms (async) | ~0,1ms (sync) | 40x schneller | | GC Max-Pause | 45ms | 12ms | 73% kürzer | | FlatList-Scroll (1000 Items) | Gelegentliches Ruckeln | Flüssige 60fps | Keine verlorenen Frames |

Die wirkungsvollste Verbesserung für die Benutzererfahrung ist die Reduktion der GC-Pausen. Hades hält Collection-Pausen unter einem Frame-Budget (16,6ms bei 60fps), womit die häufigste Quelle sichtbaren Ruckelns in komplexen React Native Apps eliminiert wird.

Ökosystem-Kompatibilität 2026

Das Ökosystem ist vollständig auf die New Architecture konvergiert. Expo SDK 55 und spätere Versionen laufen ausschließlich auf der New Architecture, ohne Option zur Deaktivierung. Wichtige Bibliotheks-Kompatibilität:

• React Navigation 7.2+: Volle Fabric-Unterstützung mit native-stack Screens
• Reanimated 3.5+: Geteiltes Animations-Backend mit React Native 0.85
• Gesture Handler 2.16+: Direkte JSI-basierte Gestenerkennung
• Vision Camera 4.0+: Frame-Verarbeitung über JSI
• Detox: E2E-Tests kompatibel mit New Architecture

Für Teams, die Expo nutzen, generiert npx create-expo-app ein Projekt mit standardmäßig aktivierter New Architecture. Keine Konfiguration erforderlich.

Interview-Fragen: React Native New Architecture

Diese Fragen tauchen 2026 regelmäßig in Senior-React-Native-Interviews auf. Jede Antwort deckt die Tiefe ab, die auf Staff-/Senior-Level erwartet wird.

F1: Erläutern Sie den Unterschied zwischen der alten Bridge und JSI. Warum ermöglicht JSI synchrone native Aufrufe?

Die Bridge serialisierte jede JS-zu-Native-Nachricht als JSON, schob sie in eine asynchrone Queue und deserialisierte sie auf der nativen Seite. JSI (JavaScript Interface) stellt C++-Host-Objekte direkt in der JavaScript-VM bereit. Über JSI registrierte native Funktionen erscheinen als reguläre JavaScript-Funktionen, die nativen Code inline ausführen, ohne Serialisierung oder Queuing. Synchrone Aufrufe sind möglich, weil JSI im selben Thread-Kontext ohne eine zwischengeschaltete Message-Queue operiert.

F2: Welches Problem löst der Fabric-Renderer, das Paper nicht lösen konnte?

Paper renderte asynchron über die Bridge, was die Unterstützung von Reacts Concurrent-Features unmöglich machte. Ein startTransition-Aufruf hatte keine Wirkung, weil Paper einen laufenden Render-Baum nicht unterbrechen konnte. Fabric implementiert Rendering in geteiltem C++-Code, integriert sich direkt mit dem Reconciler von React 19 und unterstützt Concurrent Rendering, Suspense und Transitions. Layout-Berechnungen über Yoga finden ebenfalls synchron im selben Speicherbereich statt, was die Latenz der Cross-Bridge-Layout-Berechnung eliminiert.

F3: Warum ist Hermes für die New Architecture erforderlich? Könnte eine andere Engine verwendet werden?

Die New Architecture basiert auf JSI, das erfordert, dass die JavaScript-Engine die Registrierung von C++-Host-Objekten unterstützt. Hermes wurde von Grund auf mit JSI-Integration konzipiert. JavaScriptCore könnte JSI theoretisch unterstützen, aber die offizielle Implementierung und das Testing sind auf Hermes aufgebaut. Hermes V1 bietet zusätzlich Bytecode-Vorkompilierung (eliminiert Runtime-Parsing), den Hades Concurrent GC (unter 12ms Pausen) und WebAssembly-Support, die über die React-Native-JSC-Integration nicht verfügbar sind.

F4: Wie unterscheiden sich TurboModules von der alten NativeModules-API aus Entwicklerperspektive?

TurboModules erfordern eine Codegen-Spec (ein TypeScript-Interface, das TurboModule erweitert), die zur Build-Zeit typsichere native Bindings generiert. Die alten NativeModules nutzten Runtime-Reflection ohne Type-Checking. TurboModules unterstützen synchrone Rückgabewerte (nicht nur Promises), Lazy Initialization (Module laden nur beim ersten Zugriff) und direkte JSI-Aufrufe ohne JSON-Serialisierung. Der Entwickler schreibt eine TypeScript-Spec, führt Codegen aus und implementiert das generierte native Interface.

F5: Beschreiben Sie Bridgeless Mode und was er im Vergleich zu Fabric und TurboModules allein entfernt.

Selbst nach der Einführung von Fabric und TurboModules initialisierte die alte Bridge noch beim Start, um globale Event-Emitter, Timer, Fehlerbehandlung und andere Runtime-Infrastruktur zu verwalten. Bridgeless Mode ersetzt diese verbleibenden bridge-abhängigen Systeme durch JSI-basierte Implementierungen. Er eliminiert den Bridge-Initialisierungs-Overhead, reduziert den Basis-Speicherverbrauch und stellt sicher, dass die gesamte Runtime über JSI operiert. Seit React Native 0.85 ist Bridgeless Mode der einzige Betriebsmodus.

Das Üben dieser Fragen mit funktionierenden Code-Beispielen stärkt sowohl das konzeptuelle Verständnis als auch die praktische Abrufbarkeit.

Fazit

• Hermes V1 liefert 29% schnellere Cold Starts, 38% weniger Speicherverbrauch und GC-Pausen unter 12ms standardmäßig in React Native 0.84+
• Fabric ermöglicht Concurrent-Features von React 19 (Transitions, Suspense), die Paper nie unterstützen konnte
• TurboModules eliminieren JSON-Serialisierung und machen JS-zu-Native-Aufrufe durch direkte JSI-Invokation 40x schneller
• Bridgeless Mode entfernt die letzten Bridge-Abhängigkeiten; React Native 0.85 enthält null Bridge-Code
• Das Ökosystem ist vollständig kompatibel: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ und alle großen Bibliotheken unterstützen die New Architecture exklusiv
• Die Interview-Vorbereitung sollte sich auf JSI-Mechanik, Fabric-vs-Paper-Tradeoffs, den TurboModule-Codegen-Workflow und Bridgeless-Mode-Runtime-Änderungen konzentrieren