React Native New Architecture Guide 20…

Uppdaterad: 22 juni 2026

Att migrera till React Natives New Architecture 2026 är inte längre valfritt. Sedan version 0.76 är Bridgeless Mode, Fabric och Turbo Modules påslagna som standard, och de flesta större bibliotek har avvecklat sitt stöd för den gamla bryggan. Den goda nyheten är att migreringen i de flesta nya Expo- och bare-projekt sker automatiskt; den dåliga är att äldre kodbaser med egna native-moduler eller udda tredjepartsbibliotek fortfarande kräver två till fem dagars handpåläggning. Den här guiden går igenom exakt vad New Architecture är, vad som faktiskt går snabbare, och hur du tar dig dit utan att riva sönder produktionen.

New Architecture är standard från React Native 0.76 (oktober 2024) och bygger på JSI, Fabric, Turbo Modules och Bridgeless Mode.
Bridgeless Mode tar bort den asynkrona JSON-bryggan helt. Alla anrop mellan JS och native sker nu synkront via C++.
Interop-lagret gör att de allra flesta gamla native-moduler fortfarande fungerar utan ändringar under migreringen.
Praktiska prestandavinster jag har mätt ligger på 20–40 % snabbare TTI och 30–60 % lägre minnesförbrukning vid tunga listor.
Vanligaste migreringsfällor: ViewManagers som inte är Fabric-kompatibla, react-native-reanimated under 3.16, och saknad Codegen-spec för egna moduler.
För nya appar 2026 finns inget skäl att aktivera legacy-läget. Börja direkt på New Arch med Expo SDK 55+ eller RN 0.78+.

Vad är New Architecture i React Native?

New Architecture är samlingsnamnet för fyra sammanlänkade omskrivningar av React Natives kärna: JSI (JavaScript Interface), Fabric (renderaren), Turbo Modules (native-moduler) och Codegen (typgenerator). Tillsammans ersätter de den ursprungliga asynkrona JSON-bryggan som hela ramverket vilade på från 2015 fram till 0.68. Bridgeless Mode är inte en femte komponent utan slutsteget, alltså den dagen då bryggan faktiskt kompileras bort ur appen helt och hållet.

Jag har shippat sex appar på React Native sedan 2018, och de tre senaste har gått från brygga till bridgeless. Skillnaden är tydligast i situationer där JS-tråden och UI-tråden behöver prata fram och tillbaka många gånger per sekund: scrollbara listor med native-mätningar, gestbaserade animeringar och inputfält med komplex validering. På den gamla bryggan serialiserades varje meddelande till JSON och köades upp; på JSI är samma anrop ett synkront C++-funktionsanrop som tar nanosekunder i stället för millisekunder.

Värt att veta: New Architecture är inte en omskrivning av React-delen. Din komponentkod, dina hooks, ditt state, allt fungerar likadant. Det är lagret under React som har bytts ut. Det är därför migreringen i de flesta produktappar inte handlar om att skriva om JSX, utan om att uppgradera native-bibliotek och peta i Gradle/Podfile.

Är New Architecture stabil och produktionsklar 2026?

Ja, och det har varit fallet ett bra tag. Meta körde New Arch i Facebook-appen redan 2022, och från React Native 0.76 (släppt oktober 2024) är den påslagen som standard i alla nya projekt. Sedan dess har 0.77, 0.78, 0.79 och nu 0.80 fokuserat på att stänga rester och förbättra Codegen-felmeddelanden snarare än att leverera nya kärnfunktioner. Med andra ord: den är inte längre experimentell, den är vägen framåt.

Det betyder dock inte att din migrering är friktionsfri. Stabilitet i ramverket är en sak; stabilitet i ekosystemet är en annan. När jag senast räknade (juni 2026) stödjer ungefär 95 % av topp-100-paketen på npm New Arch direkt, men i den långa svansen finns fortfarande övergivna eller halvunderhållna native-moduler. Om din app använder en obskyr SDK för betalningar, hårdvarutillgång eller analys, börja migreringen med att lista alla beroenden och kolla deras package.json för fältet codegenConfig eller en explicit changelog-rad om Fabric-stöd.

För nya appar finns inget skäl att starta i legacy-läget längre. Expo SDK 55 skapar New Arch-projekt direkt, och React Native CLI gör detsamma sedan 0.76. Om en kollega föreslår att stänga av New Arch "tills biblioteket X uppdateras", be om en deadline, inte ett evigt undantag.

Bridgeless Mode: vad ändrades och varför det spelar roll

Bridgeless Mode är det som händer när alla tre andra delarna (JSI, Fabric, Turbo Modules) är på plats samtidigt: den gamla RCTBridge-klassen behövs inte längre och kompileras bort. I praktiken försvinner ungefär 50 ms från kallstarten på en typisk app, och appen behöver inte längre vakna en separat JS-tråd och vänta på att den ska initiera modullistan.

Konkret skillnad i kod är minimal. På 0.76+ ser ditt index.js i ett bare-projekt ut så här efter migrering:

// index.js efter migrering till Bridgeless Mode
import { AppRegistry } from 'react-native';
import App from './App';
import { name as appName } from './app.json';

// Inga manuella anrop till RCTBridge eller BridgeModule längre.
// AppRegistry pratar direkt med Fabric och Turbo Modules via JSI.
AppRegistry.registerComponent(appName, () => App);

På iOS-sidan har AppDelegate.mm slimmats: RCTAppDelegate hanterar bootstrappen och du behöver inte längre returnera en bridge-instans manuellt. På Android-sidan ärver MainApplication.kt från DefaultReactNativeHost som tar hand om bridgeless-konfigurationen via newArchEnabled=true i gradle.properties.

Turbo Modules och Codegen: den typsäkra bryggan

Turbo Modules ersätter de gamla NativeModules med lat-laddade, typsäkra anrop. I stället för att hela modullistan initieras vid appstart instansieras varje Turbo Module först när du anropar en metod på den. För en app med 80 native-moduler (vilket är vanligt om du använder Expo) sparar det runt 100 ms av kallstartstiden.

Hjärtat i detta är Codegen. Du beskriver din modul i TypeScript och Codegen genererar C++/Objective-C++/Java-interfacen åt dig:

// specs/NativeAnalytics.ts - TypeScript-spec, indata till Codegen
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  // Codegen genererar typsäkra wrappers på båda native-plattformarna
  track(event: string, properties: Object): void;
  identify(userId: string): Promise<boolean>;
  getDeviceId(): string; // synkront anrop, bara möjligt på JSI
}

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

Lägg till en codegenConfig-sektion i package.json så hittar bygget specfilen automatiskt:

{
  "codegenConfig": {
    "name": "RNAnalyticsSpec",
    "type": "modules",
    "jsSrcsDir": "./specs",
    "android": { "javaPackageName": "com.myapp.analytics" }
  }
}

Det getDeviceId()-anropet ovan är värt att stanna vid. Synkrona native-anrop var omöjliga på den gamla bryggan, eftersom allt var asynkront för att bryggan måste serialisera över trådgränsen. På Turbo Modules är det ett vanligt C++-funktionsanrop, vilket öppnar för API:er som tidigare krävde callbacks bara för att passera bryggan.

Fabric: concurrent React direkt i native

Fabric är den nya renderaren. Konceptuellt liknar den den gamla (JS skickar en trädbeskrivning, native renderar), men implementationen är skriven i C++ och delas mellan iOS och Android. Det betyder att en <View> beter sig identiskt på båda plattformarna på pixelnivå, vilket eliminerar en hel kategori av layoutbuggar som vi kämpade med på den gamla renderaren.

Den största praktiska vinsten är att Fabric stödjer Reacts concurrent features fullt ut. useTransition, useDeferredValue och startTransition fungerar precis som på webben: bakgrundsuppdateringar avbryts om en högre-prioriterad uppdatering kommer in. Det är en stor del av varför scrollprestanda på tunga listor blivit dramatiskt bättre.

För egna ViewManagers (komponenter som mappar mot en native-vy, t.ex. en kartkomponent eller videospelare) behöver du skriva en Fabric-spec. Här är ett minimalt exempel för en native-knapp:

// specs/MyButtonNativeComponent.ts
import type { ViewProps } from 'react-native';
import type { DirectEventHandler, Int32 } from 'react-native/Libraries/Types/CodegenTypes';
import codegenNativeComponent from 'react-native/Libraries/Utilities/codegenNativeComponent';

interface NativeProps extends ViewProps {
  label: string;
  cornerRadius?: Int32;
  onPressNative?: DirectEventHandler<{ x: number; y: number }>;
}

export default codegenNativeComponent<NativeProps>('MyButton');

Codegen producerar sedan RCTMyButtonViewComponentView på iOS och MyButtonManagerDelegate på Android. Det är mer kod än med gamla ViewManager, men typsäkerheten är värd det. Vi har inte haft en enda propspell-bug i produktion sedan vi gick över.

Hur migrerar du till New Architecture? Steg-för-steg

Här är arbetsflödet jag använt på två produktappar de senaste 18 månaderna. Räkna med 2 till 5 dagar för en medelstor app (50–100k LOC) med ett dussintal egna native-moduler.

Uppgradera React Native till minst 0.76, helst 0.78 eller senare. Använd React Native Upgrade Helper för att se exakt vilka filer som ändrats i template-projektet mellan din nuvarande och målversionen.
Inventera native-beroenden. Kör npx react-native config och korsreferera mot React Native Directory där varje paket har en explicit "New Arch"-flagga. Lista alla paket som ännu inte stöder Fabric/Turbo.
Slå på New Arch i en separat branch. I bare RN: sätt newArchEnabled=true i android/gradle.properties och kör RCT_NEW_ARCH_ENABLED=1 bundle exec pod install i ios/. I Expo: lägg till "newArchEnabled": true i app.json under expo.android och expo.ios (eller bara prebuilda Expo SDK 55+ som har det på som standard).
Bygg, krascha, fixa. Räkna med att första bygget misslyckas på minst en native-modul. Vanligaste felet är att en ViewManager förväntar sig gammal arkitektur. Lös genom att uppgradera paketet eller falla tillbaka på interop-lagret.
Konvertera egna moduler till Turbo Modules. Skriv TypeScript-specar, lägg till codegenConfig, ta bort den gamla NativeModules-registreringen.
Verifiera prestanda med en kvalitativ smoke test (kallstart, scroll, navigering) och en kvantitativ: använd Hermes sampling profiler eller den nya Performance API:n som följer med RN 0.79+.
Aktivera Bridgeless sist. Sätt bridgelessEnabled=true och kör en full regressionsrunda.

Vanliga fällor och hur du undviker dem

Tre fällor jag har sett upprepade gånger i kodgranskningar och migreringar:

1. Reanimated under 3.16

react-native-reanimated 3.16 var första versionen med fullt Bridgeless-stöd. Allt under det kraschar med ett svårtolkat C++-stacktrace första gången du försöker köra en useAnimatedStyle på en Fabric-vy. Lås uppgraderingen som ett första steg, gärna i samma PR som RN-uppgraderingen. Vår djupare genomgång av Reanimated 4 med CSS-animationer, gester och layoutövergångar går igenom de relevanta API-ändringarna.

2. Saknad Codegen-spec för egna moduler

Om du har en egen native-modul från före-Codegen-eran kommer den att laddas via interop-lagret med en varning i konsolen. Det fungerar, men förlorar typsäkerhet och alla synkrona anrop. Skriv specen, det tar 30 minuter och försvinner som teknisk skuld.

3. Direkt access mot UIManager

Gammal kod som anropar UIManager.measure() eller UIManager.dispatchViewManagerCommand() direkt behöver portas till motsvarande Fabric-API. På Fabric är vyhanteraren inte en singleton längre, utan associerad med Shadow Tree-noden. Använd findNodeHandle + nya commands-API:t som Codegen genererar åt dig.

Bibliotekskompatibilitet 2026

Status hos de vanligaste paketen, baserat på den senaste runden migreringar jag gjorde i maj 2026:

Bibliotek	Bridgeless-stöd	Minimum version	Anmärkning
react-native-reanimated	Fullt	3.16+	4.x rekommenderas för CSS-animationer
react-native-gesture-handler	Fullt	2.20+
react-native-screens	Fullt	4.0+	Krävs av Expo Router v7
react-native-svg	Fullt	15.8+
@shopify/flash-list	Fullt	2.0+	Stora prestandavinster på Fabric
react-native-mmkv	Fullt	3.0+	JSI-bibliotek från start
react-native-maps	Fullt	1.18+	Tidigare versioner laddas via interop
@react-native-firebase/*	Fullt	21+	Inkluderar Auth, Firestore, Analytics

Generell regel: paket som har codegenConfig i sin package.json är klara för Bridgeless. Om det saknas men paketet är aktivt underhållet, lägg in ett issue. De flesta maintainers tar in en sådan PR samma vecka. Om paketet är övergivet och fortfarande används på 50 ställen i koden, då är det dags för en arkitekturdiskussion, inte en migreringsdiskussion. Min erfarenhet är att övergivna native-paket är den dyraste komponenten i hela uppgraderingen, och att skriva om dem som rena JS-lösningar med Expo SDK 55-modulerna ofta är snabbare än att vänta på en uppdatering som aldrig kommer.

Faktiska prestandavinster du kan mäta

Här är de siffror jag samlat in från två produktappar mellan december 2024 och april 2026. Båda är feature-tunga konsumentappar med 200k+ MAU. Mätt på en mellanklass-Android (Pixel 6a) och iPhone 13.

Kallstart (Time to Interactive): -22 % på Android, -28 % på iOS efter Bridgeless.
Navigeringsövergångar: 60 fps konsekvent på Android (mot tidigare 45–55 fps med drop på blur-effekter).
Minnesförbrukning under tung lista (1000+ items): -42 % när FlashList 2 körs på Fabric.
JS-thread CPU under scroll: -35 %, mest på grund av att gesthantering och animeringar nu lever på UI-tråden via Reanimated worklets.
Bundle size: -8 % från att bryggans serialiseringskod tas bort.

Det är värt att kombinera New Arch med React Compiler, som är stabil från 0.78. Compilern memoiserar automatiskt på komponentnivå, vilket gör att du kan slänga ut de flesta useMemo/useCallback du har strösslat över koden. För en djupare genomgång av mätmetodik och flamegraphs, läs vår tidigare guide om React Native prestandaoptimering med New Architecture och React Compiler.

Vanliga frågor

Behöver jag verkligen migrera till New Architecture 2026?

Ja. Från React Native 0.76 är New Architecture standard, och från och med 0.79 är legacy-läget enbart en kompatibilitetsfallback för enskilda moduler. Om du stannar kvar på äldre RN-versioner kommer du snart att hamna utanför säkerhetspatchar och nya bibliotekssläpp.

Vad är skillnaden mellan New Architecture och Bridgeless Mode?

New Architecture är paraplytermen för JSI, Fabric, Turbo Modules och Codegen. Bridgeless Mode är det slutläge då den gamla RCTBridge-klassen helt har tagits bort ur appen, och det är möjligt först när alla tre andra komponenterna är aktiva och alla native-moduler är kompatibla.

Kan jag använda gamla native-moduler med New Architecture?

Ja, via interop-lagret som följer med React Native 0.74+. Modulerna laddas långsammare och förlorar typsäkerhet, men de fungerar. För Bridgeless Mode måste dock vissa kritiska moduler (framförallt ViewManagers) vara fabric-kompatibla, annars startar inte appen.

Hur lång tid tar migreringen för en typisk app?

2 till 5 dagar för en medelstor app (50–100k LOC) med några egna native-moduler. Större delen av tiden går åt till att uppdatera tredjepartsbibliotek och skriva Codegen-specar för egna moduler. Själva RN-uppgraderingen tar en eftermiddag.

Påverkar New Architecture min JavaScript-kod?

Mycket lite. Komponenter, hooks, state management och navigering fungerar identiskt. Det som ändras är native-bryggan under huven, samt att synkrona Turbo Module-anrop nu är möjliga, vilket kan förenkla viss kod som tidigare behövde callbacks bara för att passera bryggan.