Jak zaplanować aktualizację React Native i przejście na New Architecture, zanim stara wersja zablokuje wydania?

Źródła sprawdzone 12 listopada 2026.

Ten poradnik jest dla osoby, która odpowiada za firmową aplikację w React Native (z Expo albo bez) i ma zdecydować, kiedy i jak ją zaktualizować. Opisuje kolejność prac, ryzyka i to, co przygotować przed wyceną.

Odpowiedź w skrócie: im starsza wersja, tym więcej zmian w plikach natywnych i bibliotekach naraz. Aktualizacja nie musi oznaczać przepisania aplikacji, ale wymaga inwentaryzacji zależności, ścieżki wersji z punktem kontrolnym na 0.81 i testów ścieżek, od których zależy przychód.

Trzy zmiany po stronie platform sprawiają, że odkładanie aktualizacji ma koszt:

• React Native 0.82: brak możliwości powrotu do starej architektury.
• Expo SDK 55: tylko New Architecture, oparte na React Native 0.83.
• Google Play: wymagany docelowy poziom API dla nowych wydań od 31 sierpnia 2026.

React Native 0.82 to pierwsza wersja działająca wyłącznie na New Architecture. Według ogłoszenia wydania React Native 0.82 ustawienie newArchEnabled=false na Androidzie i RCT_NEW_ARCH_ENABLED=0 na iOS jest w tej wersji ignorowane.

Po stronie Expo przewodnik Expo o New Architecture podaje, że SDK 55 i nowsze działają tylko na nowej architekturze, SDK 55 używa React Native 0.83, a stara architektura została zamrożona w czerwcu 2025: nie powstają dla niej nowe funkcje ani poprawki.

Trzecia zmiana dotyczy sklepu. Według wymagań Google Play dotyczących docelowego API od 31 sierpnia 2026 nowe aplikacje i aktualizacje muszą celować w Android 16 (API 36), z wyjątkami: aplikacje na Wear OS i Android Automotive OS muszą celować co najmniej w API 35, a na Android TV i Android XR co najmniej w API 34. Istniejące aplikacje muszą celować co najmniej w API 35, aby pozostać dostępne dla nowych użytkowników na nowszych wersjach Androida.

Zakres aktualizacji wynika z tego, co jest w projekcie, a nie z numeru wersji. Zanim ktokolwiek poda termin, zbierz te informacje:

Stan bibliotek względem New Architecture można sprawdzić w serwisie React Native Directory, który oznacza biblioteki działające z nową architekturą. W projektach Expo polecenie npx expo-doctor porównuje zależności z danymi tego serwisu.

Jeśli projekt nie działa jeszcze na New Architecture, zespół React Native zaleca najpierw aktualizację do 0.81 albo Expo SDK 54. Te wersje zawierają ostrzeżenia ułatwiające migrację. Plan może wyglądać tak:

Taki podział oddziela dwa ryzyka: zmiany wynikające z nowej wersji React Native i zmiany wynikające z nowej architektury. Gdy coś przestanie działać, łatwiej ustalić przyczynę. Wersja 0.81 to jednak tylko etap przejściowy: według strony wydań React Native w listopadzie 2026 aktywnie wspierane są 0.87 i 0.88, a 0.81 nie jest już wspierana.

1. Aktualizacja do 0.81 lub SDK 54 ze starą architekturą, jeśli projekt jest na starszej wersji.
2. Włączenie New Architecture w tej samej wersji i naprawa bibliotek oraz modułów, które jej nie obsługują.
3. Wydanie i obserwacja wersji z nową architekturą u użytkowników.
4. Aktualizacja do aktualnie wspieranej wersji React Native (w Expo: najnowszego SDK), gdy aplikacja działa stabilnie.

Projekt React Native składa się z części JavaScript, projektu Android i projektu iOS, więc aktualizacja dotyczy wszystkich trzech.

W projektach bez Expo pomaga narzędzie Upgrade Helper, które pokazuje pełną listę zmian w plikach między dwiema wybranymi wersjami, z komentarzami wyjaśniającymi część zmian.

W projektach Expo instrukcja aktualizacji Expo SDK opisuje kolejne kroki: instalację nowej wersji pakietu expo, dopasowanie zależności poleceniem npx expo install --fix i kontrolę poleceniem npx expo-doctor. Expo zaleca przechodzenie o jedną wersję SDK naraz.

Jeśli projekt korzysta z Continuous Native Generation, katalogi android i ios są generowane od nowa, a zmiany natywne trzeba przenieść do konfiguracji i pluginów. Ręczne zmiany w tych katalogach bez takiej konfiguracji zostaną nadpisane.

Dla każdej biblioteki lub modułu, który nie działa z New Architecture, masz kilka wyjść. Wybór zależy od tego, jak ważna jest funkcja i czy biblioteka ma aktywnych opiekunów:

• Aktualizacja biblioteki do wersji działającej z nową architekturą.
• Zamiana na inną bibliotekę o podobnym zakresie, jeśli obecna nie jest rozwijana.
• Poprawka lub własny fork, gdy zmiana jest mała, a biblioteka jest kluczowa.
• Przepisanie własnego modułu na Turbo Modules lub komponent Fabric.
• Usunięcie funkcji, jeśli nikt z niej nie korzysta.

Jeśli niekompatybilna biblioteka zewnętrzna blokuje migrację, zespół React Native radzi skontaktować się bezpośrednio z jej opiekunami. Warto to zrobić na etapie inwentaryzacji, a nie w trakcie aktualizacji.

Nowa architektura zmienia sposób renderowania i komunikacji z kodem natywnym, dlatego testy powinny objąć zachowanie aplikacji na urządzeniach, a nie tylko kompilację. Lista kontrolna przed wydaniem:

• Testy E2E ścieżek logowania, zakupu, płatności i powiadomień na Androidzie i iOS.
• Ekrany z listami, animacjami i widokami natywnymi na starszych i nowszych telefonach.
• Raporty awarii i błędów z wersji testowej przed wydaniem do sklepu.
• Plan wycofania: poprzedni kod gotowy do wydania z wyższym numerem wersji i możliwość wstrzymania wydania etapowego.

W Google Play i App Store można wydawać nową wersję etapami (staged rollout w Google Play, phased release w App Store). Daje to czas na obserwację błędów u części użytkowników, zanim wersja trafi do wszystkich.

Nie da się rzetelnie podać czasu aktualizacji bez inwentaryzacji, bo dwie aplikacje na tej samej wersji mogą mieć zupełnie inne zależności. Na zakres wpływają:

Rzetelna wycena zawiera listę bibliotek z decyzją dla każdej z nich i plan testów. Jeśli wycena podaje tylko liczbę dni bez takiej listy, poproś o nią przed startem prac.

1. Odległość wersji: ile wydań React Native lub SDK Expo dzieli projekt od celu.
2. Biblioteki natywne: ile z nich wymaga aktualizacji, zamiany albo poprawki.
3. Własny kod natywny: liczba modułów i widoków do przepisania.
4. Testy: czy istnieją automatyczne testy, czy trzeba je dopisać.
5. Równoległy rozwój: czy zespół w tym samym czasie wydaje nowe funkcje.

Inwentaryzacja może pokazać, że aplikacja ma więcej problemów niż przestarzała wersja: brak testów, kod bez właściciela, biblioteki porzucone przez autorów albo architekturę, która utrudnia każdą zmianę.

Wtedy warto porównać aktualizację z modernizacją albo przepisaniem. Kryteria tej decyzji opisujemy w poradniku o naprawie, modernizacji lub przepisaniu aplikacji mobilnej.

Przed rozmową z wykonawcą przygotuj dostęp do repozytorium, listę funkcji krytycznych dla biznesu, wersje aplikacji w sklepach i informację, czy wydania są planowane w trakcie aktualizacji.