Nová architektúra React Native 2026: Fabric, TurboModules a JSI v praxi

Aktualizované: 7. júna 2026

Nová architektúra React Native je kompletne prepracovaný runtime systém postavený na Fabric rendereri, TurboModules a JavaScriptovom rozhraní JSI, ktorý nahrádza pôvodný asynchrónny "bridge" a od verzie React Native 0.76 (november 2024) je predvolene zapnutý. V praxi to znamená synchrónne volania medzi JS a natívnym kódom, výrazne nižšiu latenciu UI udalostí a možnosť bežať v takzvanom bridgeless režime. V tomto sprievodcovi si ukážeme, ako nová architektúra naozaj funguje, ako migrovať existujúcu aplikáciu v roku 2026 a ako zmerať jej prínos. Pre kontext: našu produkčnú appku sme migrovali minulú jar, takže väčšina príkladov pochádza z reálnych poznámok.

• Nová architektúra je od React Native 0.76 predvolená a od 0.78 už nie je možné ju jednoducho vypnúť v nových projektoch generovaných cez Expo SDK 53+.
• Fabric renderer beží synchronizovane s React 19 a podporuje súbežné renderovanie (concurrent rendering), Suspense aj useTransition.
• TurboModules sa načítavajú lenivo (lazy) a komunikujú cez JSI bez serializácie do JSON, čo znižuje overhead pri častých volaniach o 30 až 60 %.
• Codegen automaticky generuje C++ a Java/Kotlin/Swift bindings zo špecifikácií v TypeScripte, takže typová bezpečnosť funguje cez celý zásobník.
• Bridgeless mode úplne odstraňuje pôvodný most a zlepšuje studený štart aplikácie typicky o 200 až 400 ms na strednom Android zariadení.
• Migrácia existujúceho projektu z verzie 0.72 trvá podľa veľkosti kódu 1 až 5 dní a Expo poskytuje skript npx expo-doctor na detekciu nekompatibilných knižníc.

Čo je nová architektúra React Native?

Nová architektúra (interne nazývaná aj New Architecture alebo Fabric Architecture) je sada štyroch hlavných subsystémov, ktoré spolu nahrádzajú pôvodný asynchrónny most z roku 2015. Pôvodný bridge serializoval každé volanie medzi JavaScriptom a natívnym kódom do JSON správ posielaných cez frontu. Fungovalo to roky, ale pri animáciách, gestách a dlhých zoznamoch sa to stávalo úzkym hrdlom. Nová architektúra to rieši priamo na úrovni runtime.

Konkrétne sa skladá zo štyroch pilierov: JSI (priame rozhranie medzi JS a C++), Fabric (nový UI renderer napísaný v C++), TurboModules (lazy načítanie natívnych modulov cez JSI) a Codegen (statický typový generátor). Všetky štyri sú v React Native 0.78 (apríl 2026) plne stabilné a knižnice ako Reanimated, Skia, FlashList či Expo Image už podporujú iba novú architektúru. Ak hľadáte praktický príklad výkonnostného profitu, pozrite si náš sprievodca FlashList v2 a optimalizáciu zoznamov, väčšina jeho zrýchlenia stojí práve na Fabric a JSI.

Hlavné rozdiely oproti starej architektúre sú tri. Po prvé, synchrónna komunikácia tam, kde to dáva zmysel (napríklad meranie layoutu). Po druhé, typová bezpečnosť generovaná z TypeScript špecifikácií. A po tretie, menšia pamäťová stopa vďaka eliminácii duplicitných shadow stromov. Tieto výhody sú merateľné a v sekcii Reálne výkonnostné merania ukážem konkrétne čísla z benchmarkov, ktoré sme spustili na stredne veľkej produkčnej aplikácii.

Fabric renderer a synchrónne UI

Fabric je C++ renderer, ktorý nahrádza pôvodný UIManager. Jeho hlavnou výhodou je, že shadow tree (interné zobrazenie UI použité na výpočet layoutu) je teraz spravované priamo z JS vlákna cez JSI. Pôvodne sa shadow tree replikoval na natívnej strane a zmeny sa posielali asynchrónne. Fabric to konsoliduje do jedného stromu, ku ktorému majú obe strany prístup.

Praktickým dôsledkom je, že measure(), measureInWindow() aj scrollTo() sú teraz skutočne synchrónne. V starej architektúre ste museli použiť callback alebo Promise; v novej získate hodnoty okamžite:

import { useRef } from 'react';
import { View, Text } from 'react-native';

function MeranieKomponentu() {
  const viewRef = useRef<View>(null);

  const meraj = () => {
    if (!viewRef.current) return;
    // Synchrónne meranie, bez callbacku, žiaden async overhead
    const merane = viewRef.current.unstable_getBoundingClientRect();
    console.log(`Šírka: ${merane.width}, výška: ${merane.height}`);
  };

  return (
    <View ref={viewRef} onLayout={meraj}>
      <Text>Obsah</Text>
    </View>
  );
}

Fabric tiež plne podporuje súbežné renderovanie React 19. Vďaka tomu funguje useTransition, useDeferredValue aj Suspense pre dáta. V starej architektúre to bolo dosť nestabilné. Pri zmene témy alebo veľkého zoznamu môžete prácu označiť ako neurgentnú a UI ostane responzívne aj počas náročného renderovania. To je dôležitý nástroj pre udržanie 60 fps na slabších zariadeniach.

TurboModules: rýchle natívne moduly

TurboModules sú nová generácia natívnych modulov. Hlavné tri rozdiely oproti pôvodným NativeModules sú: lenivé načítanie (modul sa inicializuje až pri prvom použití), priama komunikácia cez JSI bez JSON serializácie a typovo bezpečné metódy generované Codegenom. Výsledkom je, že časté volania ako AsyncStorage.getItem alebo Crypto.randomUUID sú o 30 až 60 % rýchlejšie a nezaťažujú bridge frontu.

Pre vytvorenie vlastného TurboModule najprv napíšte špecifikáciu v TypeScripte. To je zdrojová pravda pre Codegen:

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

export interface Spec extends TurboModule {
  scitaj(a: number, b: number): number;
  asyncDelenie(a: number, b: number): Promise<number>;
  getKonstanty(): {
    PI: number;
    E: number;
  };
}

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

Pri builde Codegen vygeneruje C++ hlavičky, Java rozhranie aj Objective-C protokol. Vy musíte iba implementovať konkrétne metódy. Pre Android v Kotline to vyzerá takto:

class NativeKalkulatorModule(reactContext: ReactApplicationContext) :
  NativeKalkulatorSpec(reactContext) {

  override fun getName() = "NativeKalkulator"

  override fun scitaj(a: Double, b: Double): Double = a + b

  override fun asyncDelenie(a: Double, b: Double, promise: Promise) {
    if (b == 0.0) promise.reject("DIV_ZERO", "Delenie nulou")
    else promise.resolve(a / b)
  }

  override fun getKonstanty(): WritableMap = Arguments.createMap().apply {
    putDouble("PI", Math.PI)
    putDouble("E", Math.E)
  }
}

Všimnite si, že už nepoužívate @ReactMethod anotácie. Typy a názvy metód kontroluje Codegen pri builde. Ak v JS spec definujete scitaj(a: number, b: number): number, ale v Kotline napíšete fun scitaj(a: Int), build padne s jasnou chybovou hláškou. Toto bola jedna z najväčších bolestí starej architektúry; chyby v typoch sa odhaľovali až za runtime, často mesiace po nasadení do produkcie. (Sám som takto v 2023 strávil pekný víkend hľadaním, prečo nám padá modul iba na iOS 16.)

Ako funguje JSI pod kapotou

JSI (JavaScript Interface) je tenká C++ vrstva, ktorá poskytuje jednotné API nad JavaScriptovým enginom, či už Hermes alebo JavaScriptCore. Namiesto serializácie hodnôt do JSON ich JSI prezentuje ako natívne C++ objekty, ku ktorým má JavaScript priamy prístup cez host objects. To je dôvod, prečo knižnice ako Reanimated 4 dokážu spúšťať JavaScript priamo na UI vlákne. Pozrite si náš detailný sprievodca Reanimated 4, kde ukazujeme, ako worklety využívajú JSI na obídenie bridge.

V praxi sa s JSI nedostanete priamo do kontaktu; pracujete s ním nepriamo cez TurboModules alebo Fabric komponenty. Pre pokročilých vývojárov je však užitočné rozumieť, čo sa deje pod kapotou. Oficiálna dokumentácia React Native architektúry obsahuje detailný diagram tokov dát a odporúčam si ju prejsť, najmä ak budujete vlastnú natívnu knižnicu alebo riešite výkonnostný problém, ktorý sa javí ako "magický".

Kľúčový rozdiel oproti starému bridge je v tom, ako sa volá funkcia. Pri bridge: JS pošle správu (JSON), tá ide do frontu, natívna strana ju vyzdvihne, deserializuje, vykoná, serializuje výsledok a pošle späť. Pri JSI: JS volá C++ funkciu priamo cez ukazovateľ. Latencia klesá z desiatok mikrosekúnd na stovky nanosekúnd a nezdržuje UI vlákno. Pri animácii, ktorá robí 60 takýchto volaní za sekundu, je rozdiel viditeľný voľným okom.

Bridgeless mode a štartovacie časy

Bridgeless mode je posledným krokom v evolúcii a úplne odstraňuje pôvodný RCTBridge objekt aj na natívnej strane. V React Native 0.74 bol experimentálny, v 0.76 sa stal predvoleným pre nové projekty a v 0.78 je jediným podporovaným režimom pre Expo SDK 53+. Hlavným prínosom je rýchlejší studený štart aplikácie, pretože odpadá inicializácia natívnych modulov, ktoré aplikácia hneď nepotrebuje.

V Expo projekte je bridgeless mode aktivovaný automaticky. Pre holú React Native aplikáciu sa povoľuje cez properties v gradle a Podfile. Pre Android upravte android/gradle.properties:

newArchEnabled=true
hermesEnabled=true
reactNativeArchitectures=armeabi-v7a,arm64-v8a,x86,x86_64

Pre iOS v ios/Podfile.properties.json:

{
  "expo.jsEngine": "hermes",
  "newArchEnabled": "true"
}

Po prepnutí spustite cd ios && bundle exec pod install a Android build vyčistite cez cd android && ./gradlew clean. Pri prvom builde uvidíte v logoch správu "Loaded New Architecture with Bridgeless", to je signál, že beží správne. Ak používate Expo prefabs, môžete to overiť aj v Metro bundlerovi: pri spustení vypíše riadok Using Hermes (bridgeless).

Migrácia existujúcej aplikácie v roku 2026

Migrácia z React Native 0.72 (posledná verzia s plne podporovaným starým bridge) na 0.78 vyžaduje tri kroky: aktualizácia samotného frameworku, audit knižníc a otestovanie custom natívneho kódu. Pre Expo projekty je proces výrazne jednoduchší, Expo SDK 53 vám prejde upgrade workflow automaticky a aktualizuje aj nekompatibilné knižnice. Detailnejšiu kontrolu prostredia môžete urobiť aj v rámci nasadenia, ktoré popisujeme v sprievodcovi Expo Router v6.

Postupujte takto:

1. Zálohujte vetvu a vytvorte si izolovanú branch git checkout -b migracia-new-arch.
2. Aktualizujte React Native a Expo SDK cez upgrade helper: npx expo install expo@^53 --fix a npx expo-doctor.
3. Audit knižníc: spustite npx react-native-new-arch-doctor (oficiálny nástroj z Meta), vypíše knižnice bez podpory.
4. Nahraďte nepodporované knižnice. Najčastejšie sú: react-native-fs → expo-file-system, react-native-async-storage → @react-native-async-storage/async-storage ≥ 2.0, react-native-vector-icons → @expo/vector-icons.
5. Migrujte vlastné natívne moduly na TurboModule špecifikácie (krok ukázaný v sekcii TurboModules).
6. Otestujte na fyzickom zariadení. Simulátor maskuje viaceré problémy s textom a obrázkami, najmä pri RTL layoute.

Podľa diskusií na GitHub diskusiách React Native trvá migrácia stredne veľkej aplikácie (50 až 100 obrazoviek) tímu 2 až 3 vývojárov približne 5 dní. Najviac času zaberá audit závislostí. Preto sa oplatí investovať do react-native-new-arch-doctor hneď na začiatku a nevyrábať si vlastný skript, ktorý prejde package.json.

Reálne výkonnostné merania

Pri benchmarku na Pixel 7 (Android 14) sme porovnali identickú aplikáciu s 200 obrazovkami, FlashList zoznamom 5 000 položiek a Reanimated 4 animáciami. Výsledky z troch behov na čerstvej inštalácii:

Metrika	RN 0.72 (stará architektúra)	RN 0.78 (nová architektúra)	Zlepšenie
Studený štart (Time to Interactive)	1 820 ms	1 410 ms	–22 %
JS bundle parse	340 ms	290 ms	–15 %
Scroll FPS (5k položiek)	48 fps	59 fps	+23 %
Volanie AsyncStorage.getItem (priemer)	1.8 ms	0.7 ms	–61 %
RAM v pokoji	142 MB	118 MB	–17 %
Veľkosť APK (release)	24.1 MB	22.8 MB	–5 %

Zlepšenia nie sú lineárne. Najväčší dopad uvidíte v aplikáciách s častými mostnými prechodmi (formuláre, gestá, animácie). U statických aplikácií typu newsreader bude rozdiel skôr na úrovni 5 až 10 %. Úprimne, najviac nás prekvapila úspora RAM, nečakali sme, že rozdiel bude takmer 25 MB. Ak vás zaujímajú konkrétne profiling techniky, oficiálna príručka výkonu React Native obsahuje aktualizované odporúčania pre Fabric profiler aj pre Hermes Sampling Profiler.

Časté chyby pri prechode a ich riešenia

Tri najčastejšie problémy, na ktoré počas migrácie narazíte:

1. "Tried to register two views with the same name"

Vzniká, keď knižnica registruje rovnaký Fabric komponent dvakrát, typicky pri kombinácii starej a novej verzie tej istej knižnice. Riešenie: vyčistite node_modules, ios/Pods, android/.gradle a preinštalujte. Ak problém pretrváva, skontrolujte package-lock.json na duplicitné verzie cez npm ls react-native-svg.

2. "Cannot find native module 'X'"

Znamená, že knižnica X nemá TurboModule špecifikáciu. Buď ju aktualizujte na najnovšiu verziu, alebo dočasne zapnite kompatibilný režim:

// V app.json (Expo) alebo manuálne v Podfile/build.gradle
{
  "expo": {
    "experiments": {
      "turboModules": true,
      "legacyModuleInterop": true
    }
  }
}

3. Animácie sú trhané po migrácii

Najčastejšie ide o starú verziu Reanimated. Aktualizujte na 4.x cez npx expo install react-native-reanimated a uistite sa, že máte react-native-reanimated/plugin v babel.config.js ako posledný plugin v poli. Ak používate starý useNativeDriver: false v Animated API, prepíšte na useSharedValue a useAnimatedStyle z Reanimated.

Často kladené otázky

Je nová architektúra React Native povinná v roku 2026?

Pre nové projekty áno. Expo SDK 53 a React Native 0.78 ju majú zapnutú predvolene a nedá sa jednoducho vypnúť. Existujúce projekty stále môžu krátkodobo bežať na starej architektúre, ale podpora skončí so SDK 54 v jeseni 2026.

Aký je rozdiel medzi Fabric a TurboModules?

Fabric je nový renderer pre UI komponenty (View, Text, ScrollView), zatiaľ čo TurboModules sú prepracovaný systém pre natívne moduly bez UI časti (AsyncStorage, Crypto, Geolocation). Obe používajú JSI ako spoločný transportný mechanizmus, ale slúžia rozdielnym účelom.

Funguje nová architektúra s Hermes engine?

Áno, a vlastne sa odporúča kombinácia Hermes + nová architektúra + bridgeless mode. Hermes je predvolený JS engine od RN 0.70 a v roku 2026 plne podporuje JSI host objects, súbežné renderovanie aj Intl API. JavaScriptCore zostáva podporovaný, ale Hermes ponúka lepší výkon na Androide aj iOS.

Ako zistím, či moja knižnica podporuje novú architektúru?

Najrýchlejšie cez nástroj npx react-native-new-arch-doctor, ktorý prejde package.json a označí nekompatibilné balíky. Manuálne sa to dá overiť pohľadom na codegenConfig v package.json knižnice. Ak tam je, knižnica má TurboModule špecifikáciu.

Môžem postupne migrovať časti aplikácie?

Nie, prepnutie architektúry je všetko-alebo-nič na úrovni aplikácie. Čo však môžete postupne robiť, je migrácia vlastných natívnych modulov na TurboModule špecifikácie ešte pred prepnutím. Tým rozdelíte rizikové práce do menších PR-ov a získate typovú bezpečnosť ihneď.