React Native 0.80: Przewodnik Migracji 2026

Wprowadzenie: Dlaczego 2026 rok to moment, w którym naprawdę musisz migrować

React Native 0.80, wydany w 2025 roku, to przełomowy moment w historii frameworka. Po latach przygotowań, testów i stopniowego wdrażania, Nowa Architektura stała się nie tylko zalecanym, ale wręcz niezbędnym wyborem dla każdego poważnego projektu React Native. Meta oficjalnie ogłosiła zamrożenie Starej Architektury — dalszy rozwój, optymalizacje i nowe funkcje będą dostępne wyłącznie dla aplikacji korzystających z nowego stosu.

Szczerze mówiąc, 2026 rok to moment, w którym ekosystem w końcu osiągnął dojrzałość. Większość popularnych bibliotek i pakietów społeczności została zaktualizowana pod kątem pełnej obsługi JSI, Fabric i TurboModules. Firmy takie jak Discord, Shopify, Microsoft czy Coinbase wdrożyły Nową Architekturę w swoich aplikacjach produkcyjnych i raportują poważne poprawy wydajności.

Jeśli prowadzisz aktywny projekt React Native — nie ma już wymówek. Migracja przestała być eksperymentem, to aktualnie standard branżowy. W tym przewodniku przeprowadzimy Cię przez cały proces, wyjaśnimy kluczowe koncepcje i pomożemy uniknąć typowych pułapek.

Co się zmieniło w React Native 0.79 i 0.80

Wydania 0.79 i 0.80 przyniosły ze sobą chyba najbardziej znaczące zmiany w historii React Native od czasu pierwszej wersji publicznej. Przyjrzyjmy się najważniejszym nowościom.

Integracja z React 19.1

React Native 0.80 korzysta z najnowszego React 19.1, który wprowadza szereg ulepszeń wydajnościowych i nowych funkcji. Wśród najważniejszych znajdziemy ulepszone React Server Components (nadal w fazie eksperymentalnej dla React Native), nowy compiler React optymalizujący renderowanie oraz poprawioną obsługę Suspense i Concurrent Features.

Integracja z React 19.1 oznacza też pełne wsparcie dla nowoczesnych hooków — w tym useTransition, useDeferredValue oraz ulepszonych mechanizmów cachowania. Dla nas, deweloperów, to możliwość pisania bardziej wydajnego kodu z mniejszą ilością manualnych optymalizacji.

Hermes jako domyślny silnik JavaScript (porzucenie JavaScriptCore)

Jedna z najbardziej rewolucyjnych zmian w 0.80 to uczynienie Hermesa domyślnym i jedynym oficjalnie wspieranym silnikiem JavaScript. JavaScriptCore został oficjalnie wycofany ze wsparcia dla nowych projektów.

Co to konkretnie daje?

Szybszy start aplikacji — Hermes wykorzystuje bytecode, co znacząco przyspiesza inicjalizację
Mniejsze zużycie pamięci — optymalizacje garbage collectora redukują footprint o 20-40%
Lepsza wydajność — natywne wsparcie dla JSI i głęboka integracja z Nową Architekturą
Spójność platform — ten sam silnik na iOS i Android eliminuje irytujące rozbieżności w zachowaniu

Meta zainwestowała spore zasoby w optymalizację Hermesa specjalnie pod kątem React Native, co czyni go znacznie lepszym wyborem niż uniwersalne rozwiązania typu JSC czy V8.

Zamrożenie Starej Architektury

Od wersji 0.80 Stara Architektura (bazująca na Bridge) została oficjalnie zamrożona. W praktyce oznacza to, że:

Nie będą dodawane nowe funkcje do komponentów Bridge
Optymalizacje wydajnościowe skupią się wyłącznie na Nowej Architekturze
Wsparcie dla Starej Architektury ograniczy się do krytycznych poprawek bezpieczeństwa
Nowe API i moduły będą tworzone wyłącznie dla TurboModules i Fabric

Ta decyzja była w zasadzie nieunikniona — utrzymywanie dwóch równoległych architektur spowalniało rozwój frameworka i generowało ogromne koszty techniczne. Teraz zespół React Native może skupić się na jednym, nowoczesnym rozwiązaniu.

Deprecjacja głębokich importów (deep imports)

React Native 0.80 wprowadza ostrzeżenia dla tzw. "deep imports", czyli bezpośrednich importów z wewnętrznych ścieżek pakietu. Kod taki jak poniżej został oznaczony jako przestarzały:

// Deprecated - unikaj tego
import { Alert } from 'react-native/Libraries/Alert/Alert';

Zamiast tego po prostu korzystaj z publicznych API:

// Poprawne podejście
import { Alert } from 'react-native';

Zmiana ta pozwala zespołowi React Native na refaktoryzację wewnętrznej struktury bez ryzyka zepsucia kodu deweloperów, którzy polegali na niestabilnych wewnętrznych API. I szczerze — dawno trzeba było to zrobić.

Mniejsze APK dzięki IPO (~1MB redukcji)

Optymalizacja Inter-Procedural Optimization (IPO) w procesie kompilacji natywnego kodu C++ przyniosła zauważalną redukcję rozmiaru wynikowych plików APK — średnio o około 1MB. Niby niewiele, ale dla użytkowników z wolnymi połączeniami lub ograniczoną przestrzenią na telefonie każdy megabajt robi różnicę.

IPO działa poprzez agresywną optymalizację między modułami podczas linkowania, eliminując nieużywany kod i inlinując funkcje między granicami kompilacji. Proces jest automatycznie włączony w release builds dla projektów z Nową Architekturą.

Szybsze buildy na iOS

Dzięki przepisaniu części systemu budowania i lepszej integracji z Xcode, czasy kompilacji na iOS zostały znacząco skrócone. Osiągnięto to poprzez:

Lepsze cachowanie skompilowanych modułów Fabric
Paralelizację generowania kodu przez Codegen
Optymalizację skryptów CocoaPods
Wykorzystanie precompiled headers dla nagłówków C++

Dla większych projektów to oszczędność wielu minut w każdym cyklu development-test-debug. A jak wiemy — każda zaoszczędzona minuta buildu to mniej scrollowania Twittera w oczekiwaniu.

Ścisłe API TypeScript (opt-in)

React Native 0.80 wprowadza opcjonalny tryb ścisłych typów TypeScript dla całego API frameworka. Gdy jest włączony, eliminuje wiele luźno typowanych konstrukcji i wymusza bardziej precyzyjne typy. Tryb jest szczególnie przydatny dla nowych projektów i zespołów, które chcą maksymalnie wykorzystać TypeScript. Dla istniejących projektów włączenie go może wymagać dodatkowej pracy, ale długoterminowo mniej błędów runtime zdecydowanie rekompensuje ten wysiłek.

Metro z 3x szybszym startem dzięki odroczonemu hashowaniu

Metro bundler w wersji dostarczonej z React Native 0.79 i 0.80 wprowadza inteligentne odraczanie hashowania plików (deferred hashing). Zamiast hashować wszystkie pliki przy starcie, Metro robi to lazy — tylko dla faktycznie żądanych modułów. Dla dużych projektów oznacza to nawet 3-krotnie szybszy cold start development servera.

Dodatkowo Metro otrzymało szereg innych usprawnień: ulepszone cachowanie transformacji, szybsze rozwiązywanie zależności i zmniejszone zużycie pamięci dla dużych bundli.

Discord: 400ms redukcji czasu do interakcji

Jeden z najbardziej imponujących case studies migracji pochodzi od zespołu Discord. Po pełnej migracji ich aplikacji mobilnej na Nową Architekturę zaobserwowali:

400ms redukcji time-to-interactive — czas od uruchomienia do pełnej interaktywności
Szybsze renderowanie list — dzięki Fabric i zoptymalizowanemu FlatList
Mniejsze zużycie pamięci — kombinacja Hermesa i eliminacji Bridge
Płynniejsze animacje — stały 60 FPS nawet na starszych urządzeniach

Te wyniki nie są odosobnione. Podobne liczby raportowały inne duże firmy, co potwierdza, że Nowa Architektura to nie tylko teoretyczne ulepszenie — przynosi realne, mierzalne korzyści dla użytkowników końcowych.

Zrozumienie komponentów Nowej Architektury

Żeby skutecznie przeprowadzić migrację, trzeba zrozumieć fundamentalne zmiany architektoniczne. Nowa Architektura składa się z czterech głównych komponentów, które razem zastępują stary system oparty na Bridge.

JSI (JavaScript Interface) — zastępuje Bridge

JavaScript Interface to fundament całej Nowej Architektury. W Starej Architekturze cała komunikacja między kodem JavaScript a natywnym kodem (Java/Kotlin na Android, Objective-C/Swift na iOS) przebiegała przez asynchroniczny Bridge. Każde wywołanie było serializowane do JSON, przesyłane przez Bridge, deserializowane po drugiej stronie, a wynik wracał tą samą drogą. Brzmi powolnie? Bo było.

JSI całkowicie eliminuje ten bottleneck:

Bezpośrednie referencje — kod JavaScript może przechowywać bezpośrednie referencje do obiektów C++
Synchroniczne wywołania — możliwość wykonywania synchronicznych wywołań natywnych tam, gdzie to potrzebne
Brak serializacji — dane przekazywane bezpośrednio, bez kosztownej konwersji do/z JSON
Wspólna pamięć — możliwość dzielenia pamięci między światem JS a natywnym (ArrayBuffer, TypedArray)

Zobaczmy to na przykładzie. W Starej Architekturze wywołanie prostej funkcji natywnej wyglądało tak:

// Stara Architektura - asynchroniczne, przez Bridge
NativeModules.MyModule.getValue()
  .then(value => console.log(value));

Z JSI to samo wywołanie może być synchroniczne:

// Nowa Architektura - synchroniczne przez JSI
const value = global.myNativeModule.getValue();
console.log(value);

Ta zmiana ma ogromne implikacje wydajnościowe — szczególnie dla operacji wymagających intensywnej komunikacji JS-native, jak animacje, gesty czy przetwarzanie danych.

Fabric Renderer — zastępuje stary renderer

Fabric to nowy system renderowania UI, który w pełni wykorzystuje możliwości JSI. Stary renderer musiał przesyłać wszystkie zmiany UI przez Bridge (co było głównym źródłem opóźnień), natomiast Fabric działa bezpośrednio z natywnym systemem UI przez C++.

Kluczowe ulepszenia Fabric:

Synchroniczne layout — odczyt wymiarów elementów bez callback hell
Type-safe props — wszystkie właściwości komponentów typowane i walidowane przez Codegen
Priorytetyzacja renderowania — integracja z React Concurrent Mode pozwala przerwać renderowanie dla pilniejszych zadań
Ulepszona integracja z host views — płynniejsze osadzanie natywnych widoków w hierarchii React

Fabric zmienia też sposób tworzenia custom komponentów natywnych. Zamiast dziedziczenia po ViewManager i manualnej konfiguracji, używamy specyfikacji TypeScript/Flow, automatycznie konwertowanych na kod natywny przez Codegen.

TurboModules — zastępuje NativeModules

TurboModules to następca systemu NativeModules, zaprojektowany od podstaw pod JSI. Główne różnice w porównaniu ze starym podejściem:

Lazy loading — moduły ładowane tylko gdy są faktycznie używane, nie wszystkie przy starcie
Type-safe — pełna typizacja metod i parametrów
Synchroniczne metody — możliwość definiowania zarówno synchronicznych jak i asynchronicznych metod
Lepsza wydajność — bezpośrednie wywołania przez JSI zamiast Bridge

Migracja z NativeModule do TurboModule wymaga stworzenia specyfikacji w TypeScript lub Flow:

// NativeMyModule.ts - specyfikacja TurboModule
import type {TurboModule} from 'react-native';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  // Asynchroniczna metoda
  getString(id: string): Promise<string>;

  // Synchroniczna metoda
  getNumberSync(id: string): number;

  // Metoda z callbackiem
  calculate(
    a: number,
    b: number,
    callback: (result: number) => void
  ): void;
}

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

Następnie Codegen automatycznie generuje cały boilerplate code dla Androida i iOS. Piękne, prawda?

Codegen — type-safe bindings

Codegen to narzędzie generujące całą warstwę pośrednią między kodem JavaScript a natywnym na podstawie specyfikacji TypeScript/Flow. Eliminuje potrzebę ręcznego pisania powtarzalnego kodu i zapewnia pełną zgodność typów między granicami języków.

Codegen przetwarza specyfikacje i generuje:

C++ headers i implementation — wspólną warstwę dla obu platform
Java/Kotlin bindings — dla Android
Objective-C/Swift bindings — dla iOS
TypeScript type definitions — dla kodu JavaScript

Całość działa automatycznie podczas budowania projektu. Definiujesz specyfikację, a Codegen zajmuje się resztą. To ogromne uproszczenie w tworzeniu i utrzymaniu custom natywnych modułów.

Przewodnik migracji krok po kroku

No dobra, teorię mamy za sobą. Czas na praktykę. Poniżej znajdziesz szczegółowy przewodnik migracji istniejącej aplikacji na React Native 0.80 z Nową Architekturą.

Krok 1: Aktualizacja wersji React Native

Zaczynamy od aktualizacji do wersji 0.80. Najlepiej użyć oficjalnego narzędzia upgrade helper:

# Użyj React Native Upgrade Helper
npx react-native upgrade 0.80.0

# Lub ręcznie zaktualizuj package.json
npm install [email protected]
# lub
yarn add [email protected]

Po aktualizacji package.json musisz też zaktualizować natywne foldery projektu. Sprawdź różnice na stronie React Native Upgrade Helper, porównując swoją aktualną wersję z 0.80.0.

Kluczowe pliki do zaktualizowania:

android/build.gradle
android/app/build.gradle
android/gradle.properties
ios/Podfile
ios/YourApp.xcodeproj/project.pbxproj

Po aktualizacji plików uruchom:

# iOS
cd ios && pod install && cd ..

# Android - clean build
cd android && ./gradlew clean && cd ..

Krok 2: Włączenie flag Nowej Architektury

Nowa Architektura włączana jest przez flagi w konfiguracji natywnej. Dla Androida edytuj android/gradle.properties:

# Android - android/gradle.properties

# Włącz Nową Architekturę
newArchEnabled=true

# Włącz Hermes (powinien być już domyślnie true w 0.80)
hermesEnabled=true

Dla iOS edytuj ios/Podfile:

# iOS - ios/Podfile

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

platform :ios, '13.0'

target 'YourApp' do
  config = use_native_modules!

  use_react_native!(
    :path => config[:reactNativePath],
    # Włącz Nową Architekturę
    :fabric_enabled => true,
    :hermes_enabled => true
  )

  # Reszta konfiguracji...
end

Po włączeniu flag przeinstaluj pods:

cd ios
pod deintegrate
pod install
cd ..

Krok 3: Upewnienie się, że Hermes jest włączony

W React Native 0.80 Hermes powinien być domyślnie włączony, ale warto to zweryfikować. Sprawdź, czy w android/gradle.properties masz:

hermesEnabled=true

I w ios/Podfile:

:hermes_enabled => true

Możesz zweryfikować czy Hermes działa w runtime:

// Sprawdź czy Hermes jest aktywny
const isHermes = () => !!global.HermesInternal;

console.log('Hermes enabled:', isHermes());

Jeśli zwraca true — Hermes działa. Jeśli false, sprawdź konfigurację ponownie i zrób clean build.

Krok 4: Migracja Native Modules do TurboModules

Jeśli Twoja aplikacja używa custom native modules, musisz je zmigrować do TurboModules. To pewnie najbardziej pracochłonny etap, ale spokojnie — procedura jest dość mechaniczna.

Krok 4.1: Stwórz specyfikację TypeScript

Utwórz plik specyfikacji opisujący interfejs modułu:

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

export interface Spec extends TurboModule {
  // Definiuj metody swojego modułu
  multiplyNumbers(a: number, b: number): Promise<number>;

  getDeviceName(): Promise<string>;

  // Metoda synchroniczna
  isDebugMode(): boolean;

  // Event emitter
  addListener: (eventType: string) => void;
  removeListeners: (count: number) => void;
}

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

Krok 4.2: Zaktualizuj implementację Android (Kotlin)

Na Androidzie moduł powinien teraz implementować interfejs wygenerowany przez Codegen:

// android/app/src/main/java/com/yourapp/MyModule.kt
package com.yourapp

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.Promise
import com.yourapp.NativeMyModuleSpec

class MyModule(reactContext: ReactApplicationContext) :
    NativeMyModuleSpec(reactContext) {

    override fun getName() = NAME

    override fun multiplyNumbers(a: Double, b: Double, promise: Promise) {
        try {
            val result = a * b
            promise.resolve(result)
        } catch (e: Exception) {
            promise.reject("ERROR", e)
        }
    }

    override fun getDeviceName(promise: Promise) {
        promise.resolve(android.os.Build.MODEL)
    }

    override fun isDebugMode(): Boolean {
        return BuildConfig.DEBUG
    }

    override fun addListener(eventType: String) {
        // Implementacja event listener
    }

    override fun removeListeners(count: Double) {
        // Implementacja usuwania listenerów
    }

    companion object {
        const val NAME = "MyModule"
    }
}

Krok 4.3: Zaktualizuj implementację iOS (Objective-C++)

Dla iOS implementuj protokół wygenerowany przez Codegen:

// ios/MyModule.mm
#import "MyModule.h"
#import <React/RCTBridge+Private.h>
#import <React/RCTUtils.h>
#import <ReactCommon/RCTTurboModule.h>

@implementation MyModule

RCT_EXPORT_MODULE()

- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:
    (const facebook::react::ObjCTurboModule::InitParams &)params
{
    return std::make_shared<facebook::react::NativeMyModuleSpecJSI>(params);
}

RCT_EXPORT_METHOD(multiplyNumbers:(double)a
                  b:(double)b
                  resolve:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject)
{
    NSNumber *result = @(a * b);
    resolve(result);
}

RCT_EXPORT_METHOD(getDeviceName:(RCTPromiseResolveBlock)resolve
                  reject:(RCTPromiseRejectBlock)reject)
{
    NSString *deviceName = [[UIDevice currentDevice] model];
    resolve(deviceName);
}

RCT_EXPORT_SYNCHRONOUS_TYPED_METHOD(BOOL, isDebugMode)
{
#if DEBUG
    return YES;
#else
    return NO;
#endif
}

@end

Krok 5: Aktualizacja custom komponentów do Fabric

Jeśli masz custom natywne komponenty UI, musisz je zmigrować do Fabric. Podobnie jak przy TurboModules, zaczynasz od specyfikacji:

// src/specs/MyCustomViewNativeComponent.ts
import type {ViewProps} from 'react-native';
import type {HostComponent} from 'react-native';
import codegenNativeComponent from 'react-native/Libraries/Utilities/codegenNativeComponent';

interface NativeProps extends ViewProps {
  color?: string;
  text?: string;
  onCustomEvent?: (event: {
    nativeEvent: {message: string};
  }) => void;
}

export default codegenNativeComponent<NativeProps>(
  'MyCustomView'
) as HostComponent<NativeProps>;

A potem użyj tej specyfikacji w komponencie React:

// src/MyCustomView.tsx
import React from 'react';
import MyCustomViewNativeComponent from './specs/MyCustomViewNativeComponent';
import type {ViewProps} from 'react-native';

interface Props extends ViewProps {
  color?: string;
  text?: string;
  onCustomEvent?: (message: string) => void;
}

const MyCustomView: React.FC<Props> = ({
  color,
  text,
  onCustomEvent,
  ...props
}) => {
  const handleEvent = (event: any) => {
    if (onCustomEvent) {
      onCustomEvent(event.nativeEvent.message);
    }
  };

  return (
    <MyCustomViewNativeComponent
      {...props}
      color={color}
      text={text}
      onCustomEvent={handleEvent}
    />
  );
};

export default MyCustomView;

Krok 6: Wykorzystanie Codegen dla type-safe bindings

Codegen uruchamia się automatycznie podczas buildu, ale możesz go skonfigurować w package.json:

{
  "name": "your-app",
  "version": "1.0.0",
  "codegenConfig": {
    "name": "AppSpecs",
    "type": "all",
    "jsSrcsDir": "src/specs",
    "android": {
      "javaPackageName": "com.yourapp.specs"
    }
  }
}

Ta konfiguracja mówi Codegenowi, gdzie szukać specyfikacji (folder src/specs) i jak nazywać generowane pliki. Gdy uruchomisz build, Codegen automatycznie:

Przeskanuje folder src/specs w poszukiwaniu specyfikacji
Wygeneruje kod C++ jako wspólną warstwę
Wygeneruje kod Java/Kotlin dla Android
Wygeneruje kod Objective-C dla iOS
Wygeneruje TypeScript type definitions

Wszystkie te pliki są generowane automatycznie — nigdy nie edytuj ich ręcznie. Jeśli potrzebujesz zmian, modyfikuj specyfikacje TypeScript i uruchom build ponownie.

Krok 7: Testowanie i profilowanie

Po zakończeniu migracji — a właściwie już w trakcie — kluczowe jest dokładne testowanie i mierzenie wydajności.

Testowanie funkcjonalne:

Przetestuj wszystkie główne user flows
Zwróć szczególną uwagę na miejsca używające custom natywnych modułów
Sprawdź integracje z bibliotekami third-party
Zweryfikuj obsługę błędów i edge cases

Testowanie wydajności:

Oto metryki, na które warto zwrócić uwagę:

Time to Interactive (TTI) — czas od startu do pełnej interaktywności
JavaScript frame rate — powinien stabilnie trzymać 60 FPS
UI frame rate — również 60 FPS dla płynnych animacji
Memory usage — zużycie pamięci powinno być niższe niż przed migracją
Bundle size — wielkość bundla JavaScript i natywnego APK/IPA

Do profilowania użyj też narzędzi platformowych:

# Android - profiling z adb
adb shell am start -n com.yourapp/.MainActivity
adb logcat | grep -i "react"

# iOS - użyj Instruments (Time Profiler, Allocations)
# Xcode -> Product -> Profile

Typowe problemy migracyjne i jak sobie z nimi radzić

Podczas migracji na pewno natkniesz się na kilka przeszkód. Oto najczęstsze problemy i sprawdzone rozwiązania.

Problem 1: Biblioteki third-party nie wspierają Nowej Architektury

Objaw: Po włączeniu newArchEnabled=true aplikacja się nie buduje lub crashuje przy użyciu konkretnej biblioteki.

Co zrobić:

Sprawdź dokumentację biblioteki — wiele popularnych pakietów już wspiera Nową Architekturę
Przejrzyj issues na GitHubie — często są gotowe pull requesty z supportem
Użyj interop layer — React Native 0.80 oferuje warstwę kompatybilności dla starych modułów
Rozważ alternatywną bibliotekę z obsługą Nowej Architektury

Problem 2: Błędy kompilacji Codegen

Objaw: Build fails z błędami typu "Cannot find symbol NativeMyModuleSpec".

Rozwiązanie:

# Wyczyść cache Codegen
# Android
cd android
./gradlew clean
rm -rf .cxx/
cd ..

# iOS
cd ios
rm -rf build/
pod deintegrate
pod install
cd ..

# Wyczyść Metro cache
npx react-native start --reset-cache

Upewnij się też, że specyfikacja TypeScript jest poprawna — nawet drobny błąd składni uniemożliwi generowanie kodu.

Problem 3: Synchroniczne wywołania blokują UI

Objaw: Po migracji na TurboModules z synchronicznymi metodami UI się zawiesza.

Rozwiązanie: Nie wszystko powinno być synchroniczne (to częsty błąd). Używaj synchronicznych wywołań tylko dla bardzo szybkich operacji (< 1ms). Dla reszty — Promise lub callbacki:

// ZŁE - synchroniczne dla wolnej operacji
export interface Spec extends TurboModule {
  fetchDataSync(): string; // To zablokuje UI thread!
}

// DOBRE - asynchroniczne dla wolnej operacji
export interface Spec extends TurboModule {
  fetchData(): Promise<string>; // UI pozostanie responsywny
}

Problem 4: Animacje nie działają płynnie

Objaw: Animacje, które w Starej Architekturze chodziły gładko, teraz są rwane.

Rozwiązanie: Upewnij się, że korzystasz z react-native-reanimated 3.x lub nowszego, w pełni zoptymalizowanego pod Fabric:

# Zainstaluj najnowszą wersję Reanimated
npm install react-native-reanimated@latest

# Upewnij się, że masz Reanimated plugin w babel.config.js
module.exports = {
  presets: ['module:metro-react-native-babel-preset'],
  plugins: [
    'react-native-reanimated/plugin'
  ]
};

Expo i Nowa Architektura (SDK 52/53)

Jeśli korzystasz z Expo, proces migracji wygląda nieco inaczej — i trzeba przyznać, że jest trochę prostszy. Expo SDK 52 wprowadziło wsparcie dla Nowej Architektury jako domyślne ustawienie, a SDK 53 kontynuuje ten kierunek.

Expo SDK 52 — Nowa Architektura jako standard

W SDK 52 Nowa Architektura jest domyślnie włączona. Kontrolujesz to przez konfigurację w app.json:

{
  "expo": {
    "plugins": [
      [
        "expo-build-properties",
        {
          "android": {
            "newArchEnabled": true
          },
          "ios": {
            "newArchEnabled": true
          }
        }
      ]
    ]
  }
}

Po zmianie konfiguracji uruchom prebuild:

npx expo prebuild --clean

Expo SDK 53 — pełna dojrzałość

SDK 53 przynosi pełną dojrzałość Nowej Architektury w ekosystemie Expo. Wszystkie oficjalne moduły są w pełni kompatybilne. Dla nowych projektów wystarczy:

npx create-expo-app@latest my-app

Projekt zostanie automatycznie skonfigurowany z Nową Architekturą. Warto mieć na uwadze, że w SDK 53 Google Maps nie będzie wspierane w Expo Go na Androidzie, a push notifications również wymagają development build zamiast Expo Go.

EAS Build i Nowa Architektura

EAS Build w pełni wspiera Nową Architekturę. Wystarczy upewnić się, że eas.json ma odpowiednią konfigurację:

{
  "build": {
    "production": {
      "android": {
        "buildType": "apk",
        "gradleCommand": ":app:assembleRelease"
      },
      "ios": {
        "buildConfiguration": "Release"
      }
    }
  }
}

Timeline i oszacowanie nakładu pracy

Czas potrzebny na migrację różni się znacząco w zależności od złożoności projektu, liczby custom natywnych modułów i zależności od bibliotek external. Oto orientacyjne ramy czasowe.

Mały projekt (aplikacja MVP, mało custom kodu natywnego)

Czas: 1-3 dni
Zakres: Upgrade React Native, włączenie flag, testowanie
Zespół: 1 developer
Ryzyko: Niskie — większość pracy to update konfiguracji

Średni projekt (aplikacja produkcyjna, kilka custom modułów)

Czas: 1-2 tygodnie
Zakres: Upgrade, migracja 3-5 custom modułów do TurboModules, aktualizacja bibliotek, obszerne testowanie
Zespół: 1-2 developers (najlepiej z doświadczeniem iOS i Android)
Ryzyko: Średnie — możliwe problemy z kompatybilnością bibliotek

Duży projekt (złożona aplikacja, wiele custom modułów i komponentów)

Czas: 3-6 tygodni
Zakres: Pełna migracja wszystkich custom modułów i komponentów, fork i patch bibliotek third-party, rozbudowane testowanie i profilowanie
Zespół: 2-3 developers (idealnie z dedykowanym iOS i Android engineerem)
Ryzyko: Średnie do wysokiego — wymaga starannego planowania

Rekomendowany plan migracji

Niezależnie od wielkości projektu, sprawdzi się następujący plan:

Tydzień 1: Przygotowanie — Audit kodu, identyfikacja zależności, stworzenie feature brancha, setup środowiska testowego
Tydzień 2-3: Migracja techniczna — Upgrade React Native, włączenie flag, migracja modułów
Tydzień 4: Testowanie — Testy funkcjonalne i wydajnościowe, naprawianie bugów
Tydzień 5: Beta release — Deploy do grupy testerów, zbieranie feedbacku
Tydzień 6: Production release — Stopniowy rollout (10% → 50% → 100% użytkowników)

Podsumowanie i rekomendacje

Migracja na React Native 0.80 z Nową Architekturą to już nie kwestia "czy", ale "kiedy". A 2026 rok to definitywnie właściwy moment — ekosystem dojrzał, biblioteki są kompatybilne, korzyści wydajnościowe potwierdzone w produkcji.

Kluczowe wnioski

Nowa Architektura to fundamentalna zmiana — JSI, Fabric i TurboModules całkowicie przeprojektowują komunikację między JS a kodem natywnym
Korzyści są rzeczywiste — Discord, Shopify i inne firmy raportują konkretne poprawy wydajności
Stara Architektura jest zamrożona — brak nowych funkcji i optymalizacji dla Bridge-based kodu
Hermes jest standardem — JSC został porzucony, Hermes oferuje lepszą wydajność i integrację
Codegen eliminuje boilerplate — type-safe bindings generowane automatycznie

Najważniejsze rekomendacje

1. Zacznij teraz, nawet jeśli nie czujesz się gotowy. Stwórz feature branch, włącz Nową Architekturę i zobacz jak aplikacja się zachowuje. Nawet jeśli natrafisz na problemy — będziesz wiedzieć co wymaga uwagi.

2. Zaktualizuj zależności przed migracją. Im bardziej aktualne biblioteki, tym większe prawdopodobieństwo, że już wspierają Nową Architekturę. Zrób audit package.json i zaktualizuj wszystko do najnowszych wersji.

3. Priorytetyzuj migrację custom kodu. Twoje własne native modules i komponenty wymagają najwięcej pracy. Zacznij od nich, a biblioteki third-party zostaw na później.

4. Używaj Codegen od początku. Nie próbuj pisać boilerplate'u ręcznie. Codegen to ogromna oszczędność czasu i eliminuje całą klasę błędów. Zainwestuj czas w naukę pisania poprawnych specyfikacji TypeScript — zwróci się wielokrotnie.

5. Testuj wydajność systematycznie. Ustaw baseline metrics przed migracją (TTI, frame rate, memory usage) i porównuj je po każdym etapie. Pozwoli Ci to udowodnić wartość migracji stakeholderom i wychwycić ewentualne regresje wcześnie.

6. Planuj stopniowy rollout. Nie rób big-bang release. Użyj feature flags lub stopniowego rollout (10% → 25% → 50% → 100%) aby minimalizować ryzyko. To da Ci czas na reakcję, gdyby coś poszło nie tak w produkcji.

Co dalej po migracji

Po zakończeniu migracji możesz wreszcie skupić się na wykorzystaniu pełnego potencjału Nowej Architektury:

Implementuj zaawansowane animacje z react-native-reanimated 3.x
Eksperymentuj z synchronicznymi wywołaniami dla ultra-responsywnego UI
Optymalizuj renderowanie list wykorzystując ulepszony FlatList w Fabric
Rozważ adopcję React Server Components gdy staną się stabilne dla React Native
Monitoruj nowe możliwości w kolejnych wydaniach — Nowa Architektura to platforma dla przyszłych innowacji

Migracja na React Native 0.80 z Nową Architekturą to inwestycja w przyszłość Twojej aplikacji. Nakład pracy jest znaczący, ale długoterminowe korzyści — lepsza wydajność, łatwiejsze utrzymanie, dostęp do najnowszych funkcji — sprawiają, że jest to jedna z najbardziej wartościowych decyzji technicznych w 2026 roku.

Powodzenia w migracji!