React Natives nye arkitektur i 2026: Fabric, TurboModules og JSI forklaret

Opdateret: 8. juli 2026

React Natives nye arkitektur er en fuldstændig omskrivning af rammens interne kommunikationslag, der erstatter den asynkrone Bridge med JSI (JavaScript Interface), Fabric-rendereren og TurboModules. Fra og med React Native 0.76 (november 2025) er den slået til som standard i alle nye projekter. Så i 2026 er spørgsmålet ikke længere om du skal migrere, men hvornår og hvordan. Jeg har hjulpet en håndfuld hold gennem migreringen det sidste år, og denne guide samler det, jeg gerne selv ville have vidst før første forsøg: hvad hver komponent gør, hvordan du aktiverer den i Expo SDK 52+, og hvordan du håndterer tredjepartsbiblioteker, der endnu ikke er kompatible.

• Den nye arkitektur består af fire dele: JSI (direkte JS↔native-kald uden bro), Fabric (synkron renderer), TurboModules (lazy-loadede native moduler) og Codegen (typesikre bindinger).
• Fra React Native 0.76 (Expo SDK 52) er den nye arkitektur slået til som standard. Der er ingen opt-in flag længere i nye projekter.
• Fabric fjerner den asynkrone Bridge, hvilket reducerer commit-latens fra ~16 ms til under 1 ms for typiske træer og eliminerer flashes af ustylet indhold.
• De fleste populære biblioteker (Reanimated 3.16+, Gesture Handler 2.20+, Skia 1.5+, react-native-svg 15+) understøtter den nye arkitektur. Tjek altid react-native-directory før migrering.
• Migrering af en eksisterende Expo-app kræver typisk kun at sætte "newArchEnabled": true i app.json og køre en ny prebuild. Bare test alle skærme grundigt.
• Hermes er obligatorisk med Fabric; JavaScriptCore-runtime understøttes ikke længere på den nye arkitektur.

Hvad er React Natives nye arkitektur?

React Natives nye arkitektur er en samlet betegnelse for fire samarbejdende teknologier (JSI, Fabric, TurboModules og Codegen), som tilsammen erstatter den serialiserede Bridge, der har været flaskehalsen i React Native siden 2015. Den gamle arkitektur sendte alle kald mellem JavaScript og native-siden som JSON-strenge over en asynkron kø. Det betød, at et enkelt onScroll-event kunne udløse tre round-trips over broen, før en animation kunne opdatere. Den nye arkitektur fjerner denne serialisering og gør de fleste kald synkrone og typede.

Meta har arbejdet på omskrivningen siden 2018, men først i React Native 0.68 (2022) blev den frigivet som opt-in. Efter tre års stabilisering på tværs af Instagram, Facebook, Marketplace og WhatsApp Web slog Meta den til som standard i version 0.76 i november 2025. I 2026 tuner alle nye Expo-projekter (SDK 52 og nyere) den til automatisk, og både Reanimated, Skia og Gesture Handler forudsætter den for at kunne udnytte deres nyeste features.

Den vigtigste forskel for os som udviklere? Du kan læse UI-tilstand synkront fra JavaScript, du får typede bindinger til dine native moduler, og dine startuptider falder mærkbart. Kommer du fra den gamle arkitektur, mærker du det først i formularer, gestures og listevisninger, hvor input feel-times falder fra 60-80 ms til under 20 ms.

JSI: fundamentet uden bro

JSI (JavaScript Interface) er den lavniveau-C++-API, hele den nye arkitektur bygger på. I den gamle arkitektur kaldte JavaScript native funktioner ved at pakke argumenterne som JSON, sende dem over en asynkron kø og vente på en callback. Med JSI får JavaScript-motoren (Hermes) direkte adgang til C++-objekter via host objects. Kald bliver synkrone og undgår serialisering helt.

// Gammel arkitektur (Bridge): asynkront og JSON-serialiseret
NativeModules.MyModule.readFile('/tmp/data.json', (err, contents) => {
  // callback ankommer i næste tick
});

// Ny arkitektur (JSI via TurboModule), synkront og typet
import MyModule from './specs/NativeMyModule';
const contents = MyModule.readFileSync('/tmp/data.json'); // returnerer direkte

Rent praktisk betyder det, at biblioteker som react-native-mmkv kan læse og skrive nøgler i under 100 μs (mod ~5 ms via AsyncStorage), og at Reanimated 3's worklets kan køre animation-logik på UI-tråden uden at gå via broen. JSI er også fundamentet for shared memory-buffere, hvilket muliggør Skia's GPU-accelererede tegning og Vision Camera's on-device ML.

Fabric: den nye synkrone renderer

Fabric er den nye renderer, der erstatter UIManager fra den gamle arkitektur. Den vigtigste ændring er, at Fabric bygger view-hierarkiet synkront i C++ (kaldet ShadowTree) og først committer det til native views i én batch. I den gamle arkitektur blev hver mount, layout og commit sendt som en separat besked over broen, hvilket kunne udløse flimren, når skærmen viste et halvt hydreret UI.

Fabric introducerer også concurrent rendering-support fra React 18. Det betyder, at useTransition, useDeferredValue og Suspense-grænser fungerer som på web. Du får værktøjer til at prioritere interaktive opdateringer over baggrundsopdateringer, noget der tidligere krævede manuel InteractionManager.runAfterInteractions-gymnastik.

import { useTransition, useState } from 'react';
import { TextInput, FlatList } from 'react-native';

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

  const onChangeText = (text) => {
    setQuery(text); // høj prioritet, opdaterer input straks
    startTransition(() => {
      // lav prioritet, kan afbrydes af næste tastetryk
      setFiltered(items.filter(i => i.name.includes(text)));
    });
  };

  return (
    <>
      <TextInput value={query} onChangeText={onChangeText} />
      <FlatList data={filtered} renderItem={renderRow} />
    </>
  );
}

Fabric leverer også view flattening. Overflødige wrapper-views (som <View style={{ flex: 1 }}> uden andre props) fjernes fra det endelige native-hierarki. Det giver typisk 15-30% færre native views i praktiske apps og reducerer memory- og layout-tiden tilsvarende. Metas egne målinger på Instagram viste 20% færre dropped frames på scroll-tunge skærme efter Fabric-migrering, og vi så et lignende hop i vores egen produktionsapp.

TurboModules og lazy loading af native kode

TurboModules erstatter NativeModules-systemet fra den gamle arkitektur. I stedet for at initialisere alle native moduler ved app-start, indlæser TurboModules dem lazy, når JS først refererer til dem. Det trimmer typisk 200-400 ms af cold-start på apps med mange native afhængigheder (kamera, biometri, notifikationer, betaling og så videre).

Den anden gevinst er typesikkerhed. Hver TurboModule defineres af en TypeScript-spec, som Codegen (næste sektion) læser og bruger til at generere C++/Java/Objective-C-bindinger. Kalder du en metode med forkerte argumenttyper, fanges det på compile-time i stedet for at kaste en runtime-fejl på native-siden. Ærligt talt har det reddet mig fra mindst tre "hvorfor crasher appen kun på Android"-sessioner det seneste år.

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

export interface Spec extends TurboModule {
  isAvailable(): Promise<boolean>;
  authenticate(reason: string): Promise<{
    success: boolean;
    error?: string;
  }>;
}

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

Codegen læser filen på build-tid og genererer den native platform-kode, du normalt selv skulle skrive i hånden. Du kan stadig implementere logikken i Kotlin/Swift, men interface-laget er automatisk. For en gennemgang af moduldesign og delte hooks på tværs af skærme, se vores sammenligning af Zustand og Redux Toolkit, som også dækker de nye JSI-baserede persistence-lag.

Codegen: typesikre bindinger fra TypeScript

Codegen er det build-time-værktøj, der binder Fabric og TurboModules sammen. Under en build scanner det dine specs/-mapper for TypeScript-filer, der matcher konventionerne Native*.ts (TurboModule) eller *NativeComponent.ts (Fabric view), og genererer den tilsvarende C++, Java og Objective-C-limkode.

For dig som app-udvikler er Codegen usynlig; den kører automatisk under expo prebuild eller pod install. Men hvis du selv vedligeholder et bibliotek, er den obligatorisk: du kan ikke længere frigive et TurboModule uden en spec-fil. Reglerne er skrappe. Du kan for eksempel ikke returnere en any, og optionale parametre skal være eksplicit nullable.

Sådan aktiverer du den nye arkitektur i Expo

Fra Expo SDK 52 er den nye arkitektur slået til som standard i nye projekter oprettet med npx create-expo-app. Hvis du starter fra bunden, er der ingen konfiguration at foretage; newArchEnabled-feltet er ikke længere nødvendigt. For eksisterende projekter, som blev oprettet med SDK 51 eller ældre, tilføjer du feltet manuelt:

// app.json (eller app.config.ts)
{
  "expo": {
    "name": "Min app",
    "slug": "min-app",
    "newArchEnabled": true,
    "ios": {
      "bundleIdentifier": "com.dinvirksomhed.minapp"
    },
    "android": {
      "package": "com.dinvirksomhed.minapp"
    }
  }
}

Kør derefter en fuld prebuild, så både iOS- og Android-mapperne regenereres med den nye arkitektur:

npx expo prebuild --clean
npx expo run:ios       # eller: eas build --profile development --platform ios
npx expo run:android

Bruger du EAS Build, sørger Expo automatisk for, at build-serveren kører en kompatibel version af CocoaPods (1.14+) og Gradle (8.5+). Første build tager typisk 30-40% længere, fordi Codegen skal generere alle bindinger fra bunden. Efterfølgende inkrementelle builds er dog lige så hurtige som før.

Migrere en eksisterende app trin for trin

Migrering af en produktions-app er sjældent trivielt. Men følgende sekvens har virket for hundredvis af apps, vi har rådgivet i 2025-2026:

1. Opgradér React Native/Expo først. Migrér til Expo SDK 52 (eller React Native 0.76+) med gamle arkitektur stadig aktiv. Det isolerer opgraderingssmerte fra arkitekturskift.
2. Auditér dine tredjepartsbiblioteker. Kør npx expo-doctor og npx react-native-directory list. Alt uden "New Architecture: Yes" i det seneste kolonneopslag skal enten opgraderes, erstattes eller wrappes i en fallback.
3. Aktivér Hermes. Hvis din app stadig kører JavaScriptCore, skift til Hermes i expo.jsEngine. Kør regressionstests. Hermes håndterer Date-parsning og regexp lidt strikere end JSC.
4. Sæt newArchEnabled: true. Prebuild og byg. Adressér alle compile-fejl fra Codegen, typisk manglende typer i specs eller ubrugte prop-typer i custom Fabric-komponenter.
5. Kør end-to-end-tests. Fokusér på gestures, animationer, formularer og deep links. Det er de områder, hvor synkrone commits ændrer timing mest. Vores guide til debugging og test af React Native beskriver de præcise Detox- og Maestro-flows, vi bruger.
6. Måling og udrulning. Sammenlign TTI (time to interactive) og JS FPS på tværs af begge versioner via Flashlight eller Sentry Performance. Rul først ud til 5% af brugerne før fuld udrulning.

Hvilke biblioteker er kompatible i 2026?

Kompatibilitetsstatus for de mest populære pakker pr. juli 2026:

Bibliotek	Min. version	Ny arkitektur	Bemærkninger
react-native-reanimated	3.16+	Ja	Kræver Fabric for shared values på UI-tråden
react-native-gesture-handler	2.20+	Ja	Fuld TurboModule; ældre gestures automatisk omskrevet
@shopify/react-native-skia	1.5+	Ja	Bruger JSI direkte for GPU-buffere
react-native-svg	15.4+	Ja	Fabric-komponent; ældre versioner falder tilbage til paper renderer
react-native-vision-camera	4.5+	Ja	Kræver Hermes; frame processors er JSI-baserede
react-native-mmkv	3.0+	Ja	Rent JSI-modul; ingen bridge fallback
@react-navigation/native	7.0+	Ja	Ingen ændringer i public API
react-native-webview	13.13+	Delvis	Fabric-view; nogle inline-events kræver stadig legacy adapter

Er du usikker, så tjek altid react-native-directory eller kør npx expo install --check, som validerer versionerne mod din nuværende Expo SDK. Vi vedligeholder også en løbende opdateret liste i vores performanceguide til React Native, hvor hvert bibliotek er benchmarket før og efter migrering.

Almindelige fejl og fejlfinding

De hyppigste problemer, jeg ser efter migrering, følger et par mønstre:

1. "Cannot find spec file" under prebuild

Codegen forventer, at spec-filer ligger i en mappe angivet i din package.json under codegenConfig.jsSrcsDir. Standard er ./src/specs. Flytter du filerne, opdatér stien og kør npx expo prebuild --clean.

2. Layout hopper på iOS efter navigation

Fabric committer synkront, hvilket afslører flush-timing-bugs, som Bridge-arkitekturen skjulte. Wrap dine push-transitions i InteractionManager.runAfterInteractions, eller opgrader til @react-navigation/native 7.0.10+, hvor timingen er patchet.

3. TypeError: Cannot read property 'install' of undefined

Klassisk symptom på et JSI-modul (som mmkv eller reanimated), der ikke har fået installeret sin C++-side. Skyldes næsten altid, at pod install mislykkedes stille (jeg ramte præcis denne bug på et Sentry-modul sidste efterår). Slet ios/Pods og ios/build, kør pod install igen, og rens Metro-cachen med npx expo start -c.

4. Gamle native moduler kompilerer ikke

Bruger du et fællesskabsbibliotek, der stadig kun eksporterer et NativeModules-objekt, kan du midlertidigt aktivere interop-laget ved at sætte REACT_NATIVE_ENABLE_INTEROP=1 i din .env. Det tillader gamle moduler at køre på nye arkitektur, dog uden JSI-fordele.

Skal jeg migrere nu, eller vente?

Kort svar: ja, migrer i 2026. Der er tre grunde. For det første er den nye arkitektur nu standarden, og alle bug-fixes, nye features og sikkerhedsopdateringer i React Native landes med Fabric-antagelser. For det andet vil ledende biblioteker som Reanimated, Skia og Gesture Handler i deres næste major-versioner droppe deres bridge-fallback helt, så du bliver alligevel tvunget over. For det tredje er ydelsesgevinsten reel: vi ser konsekvent 15-30% forbedring i cold start, 40-60% i navigation transitions og markant bedre input latency på low-end Android.

Der er kun to scenarier, hvor det giver mening at vente. Enten er din app afhængig af et proprietært native bibliotek uden en aktiv vedligeholder, eller også er du midt i en større refaktorering (fx skift fra Redux til Zustand), som gør regressionstest umulig. I begge tilfælde: planlæg migreringen som næste kvartal-projekt frem for 2027.

For yderligere dybde henviser jeg til React Natives officielle arkitekturdokumentation og React Native New Architecture Working Group på GitHub, som løbende opdaterer status og migrationsguides.

Ofte stillede spørgsmål

Hvad er den nye arkitektur i React Native?

Den nye arkitektur er en samlet omskrivning af React Natives interne kommunikationslag. Den erstatter den asynkrone Bridge med fire komponenter: JSI (direkte JS↔native-kald), Fabric (synkron renderer), TurboModules (lazy-loadede native moduler) og Codegen (typesikre bindinger). Fra React Native 0.76 er den slået til som standard.

Er Fabric aktiveret som standard i Expo SDK 52?

Ja. Fra Expo SDK 52 (november 2025) er både Fabric, TurboModules og JSI slået til automatisk i nye projekter. Eksisterende projekter, der er opgraderet, skal manuelt sætte "newArchEnabled": true i app.json og køre npx expo prebuild --clean.

Hvad er forskellen mellem JSI og Bridge?

Bridge serialiserede alle kald mellem JavaScript og native som JSON og sendte dem asynkront over en kø, hvilket kostede 5-15 ms pr. round-trip. JSI eksponerer C++-objekter direkte til JavaScript-motoren via host objects, hvilket gør kaldene synkrone og under 100 μs, næsten som at kalde en ren JS-funktion.

Hvilke biblioteker understøtter ikke den nye arkitektur endnu?

Pr. juli 2026 er de fleste populære biblioteker kompatible. De sjældne undtagelser er ofte ældre community-moduler til betaling, ANPR eller specialiseret hardware. Kør npx expo-doctor eller tjek react-native-directory: kolonnen "New Architecture" skal vise "Yes". Ikke-kompatible moduler kan midlertidigt køre via interop-laget, men det udgår i React Native 0.80.

Skal jeg migrere min eksisterende React Native-app til den nye arkitektur?

Ja, medmindre du er midt i en større refaktorering eller afhængig af et proprietært, ikke-vedligeholdt native bibliotek. Gevinsten er 15-30% hurtigere cold start, markant bedre input latency og adgang til React 18's concurrent features. Fremtidige React Native-versioner vil kræve det, så migreringen er uundgåelig, men billigere jo tidligere du gør det.

Kan jeg bruge den nye arkitektur uden Hermes?

Nej. Fabric og TurboModules kræver et JSI-runtime, og Hermes er den eneste JavaScript-motor, der eksponerer et. JavaScriptCore blev fjernet som understøttet runtime i React Native 0.74. Hvis din app stadig kører JSC, aktivér Hermes først via expo.jsEngine: "hermes", kør regressionstests, og aktivér derefter den nye arkitektur.