Jeden ekran React Native w aplikacji Swift lub Kotlin: co ustalić przed integracją

Źródła sprawdzone 5 listopada 2026.

Istniejąca aplikacja iOS lub Android może otrzymać ekran React Native bez zastępowania całego interfejsu. Oficjalny poradnik React Native opisuje dodawanie widoku lub przepływu do aplikacji natywnej. Wymaga to jednak integracji z projektem iOS lub Android, a nie tylko przygotowania komponentu w JavaScript. Integracja z istniejącą aplikacją — React Native.

Pytanie przed pierwszym ekranem brzmi więc: jak będzie współpracował z resztą produktu? Trzeba określić, kto otwiera i zamyka widok, skąd pochodzi sesja użytkownika oraz co dzieje się z rozpoczętą operacją po przerwaniu działania aplikacji. Jeden ekran może mieć mały zakres wizualny, a jednocześnie dotykać wielu zależności.

Drugi model opisuje dokumentacja Native Platform. Ten artykuł dotyczy trzeciego, często nazywanego integracją brownfield. Dostęp do funkcji natywnej z RN nie jest sam w sobie dowodem, że aplikacja natywna jest gotowa przyjąć ekran RN.

Dobrym kandydatem do oceny jest ekran z wyraźnym wejściem, wyjściem i ograniczonym zestawem danych. Może to być widok statusu zamówienia albo część programu lojalnościowego. To przykłady hipotetyczne, nie opis projektu klienta. Jeśli ekran wymaga jednoczesnej zmiany logowania, płatności i całej nawigacji, zakres oceny obejmuje także te zależności. Trzeba też wskazać osobę odpowiedzialną za każdą aplikację natywną i jej wydanie.

• Nowa aplikacja React Native. Co jest punktem wyjścia: Nowy produkt z interfejsem RN Co trzeba rozstrzygnąć: Architekturę całego produktu i jego zależności.
• Moduł lub komponent natywny w aplikacji RN. Co jest punktem wyjścia: Aplikacja RN korzystająca z kodu albo widoku platformy Co trzeba rozstrzygnąć: Jak udostępnić tę funkcję kodowi RN.
• Ekran RN wewnątrz aplikacji natywnej. Co jest punktem wyjścia: Istniejący produkt Swift/Kotlin, który otwiera widok RN Co trzeba rozstrzygnąć: Jak ekran współpracuje z natywnym hostem i resztą aplikacji.

Poniższa lista jest propozycją pytań projektowych, nie obowiązkową architekturą. „Host” oznacza istniejącą aplikację natywną. Właścicieli i mechanizmy trzeba dopasować do konkretnego produktu.

Callstack dokumentuje mechanizm, w którym kod RN wywołuje nawigację hosta przez zdefiniowany kontrakt i natywne delegaty. To konkretny wzorzec integracji, nie automatyczna synchronizacja wszystkich stosów ekranów. Przed wyborem rozwiązania warto opisać również gest cofania, zewnętrzny link do ekranu i zamknięcie widoku w połowie operacji. Brownfield Navigation — Callstack.

• Nawigacja. Po stronie hosta trzeba ustalić: Kiedy i z jakimi parametrami otwiera ekran Po stronie ekranu RN trzeba ustalić: Jak zgłasza zakończenie lub prośbę o przejście dalej Wspólna decyzja: Kto zmienia stos ekranów; co oznacza Back i anulowanie
• Cykl życia. Po stronie hosta trzeba ustalić: Jakie zdarzenia i odtworzenie obsługuje aplikacja Po stronie ekranu RN trzeba ustalić: Co robi po utracie i odzyskaniu aktywności Wspólna decyzja: Jak wznowić widok bez powtórzenia operacji
• Stan. Po stronie hosta trzeba ustalić: Które dane są źródłowe i kto je aktualizuje Po stronie ekranu RN trzeba ustalić: Które dane są tylko lokalnym stanem UI Wspólna decyzja: Format, wersja i aktualność przekazywanych danych
• Tożsamość. Po stronie hosta trzeba ustalić: Kto odpowiada za sesję, wylogowanie i jej odświeżenie Po stronie ekranu RN trzeba ustalić: Jak uzyskuje potrzebny kontekst użytkownika Wspólna decyzja: Jak oba obszary reagują na wygasłą sesję
• Operacje w toku. Po stronie hosta trzeba ustalić: Kto może ustalić wynik operacji biznesowej Po stronie ekranu RN trzeba ustalić: Jak pokazuje oczekiwanie, błąd i potwierdzenie Wspólna decyzja: Jak identyfikować operację i obsłużyć ponowienie
• Analityka. Po stronie hosta trzeba ustalić: Kto wysyła zdarzenia całej aplikacji Po stronie ekranu RN trzeba ustalić: Kto wysyła zdarzenia nowego widoku Wspólna decyzja: Jedna definicja zdarzenia i sposób unikania duplikatów

Kontekst zalogowania nie sprowadza się do przekazania identyfikatora użytkownika. Zespół powinien określić, kto odświeża uprawnienia, co oznacza wylogowanie oraz jak ekran reaguje na zmianę konta. Nie należy przenosić tokenów do przypadkowego magazynu tylko dlatego, że jest dostępny z JavaScript. Dokumentacja RN rozróżnia przechowywanie danych zwykłych i wrażliwych; Async Storage nie jest miejscem na tokeny. Security — React Native.

Podobnie trzeba oddzielić stan interfejsu od stanu biznesowego. Pozycja listy lub otwarta zakładka to inne dane niż potwierdzenie przyjęcia zamówienia. Callstack opisuje bibliotekę Brownie do współdzielenia stanu między RN a kodem natywnym. Sam wybór takiego narzędzia nie ustala jednak, które dane są nadrzędne ani kto rozstrzyga konflikt. Brownie — Callstack.

RN udostępnia AppState do obserwowania aktywności aplikacji. To sygnał do obsługi zmiany stanu, nie gotowy mechanizm odtworzenia ekranu lub zakończenia zamówienia. AppState — React Native.

Na iOS cykl życia sceny interfejsu wymaga uwzględnienia osobno od procesu aplikacji. Na Androidzie ViewModel może przetrwać zmianę konfiguracji, ale nie systemowe zakończenie procesu. Integracja musi uwzględniać odpowiedni model platformy; zdarzenie „wrócono do aplikacji” nie dowodzi, że wszystkie dane w pamięci nadal istnieją. Sceny UIKit — Apple, zachowywanie stanu widoku — Android.

zachowywanie stanu widoku — Android.

Na dzień odczytu dokumentacja Callstack zawiera tabele testowanych kombinacji React Native, Expo i pakietów brownfield. Nie jest to obietnica wsparcia dowolnej starszej aplikacji. W ocenie projektu trzeba zapisać wybrane wersje, datę dokumentacji oraz wynik sprawdzenia zależności. Tabele zgodności — Callstack.

Do takiego zapisu warto włączyć wersję RN i używaną architekturę, ewentualne Expo, wymagane biblioteki natywne, toolchain iOS/Android, minimalne systemy oraz sposób dostarczenia kodu RN w wydaniu. Otwarta pozostaje także odpowiedzialność za aktualizacje po pierwszej integracji. Nie należy przepisywać instrukcji instalacji z innej wersji dokumentacji i uznawać jej za potwierdzenie zgodności całego produktu.

Załóżmy, że natywna aplikacja ma już logowanie i listę zamówień, a nowy ekran RN pokazuje szczegóły wybranego zamówienia. To przykład do rozmowy projektowej, nie case study GMI ani gotowa specyfikacja.

Host otwiera ekran z uzgodnionym kontekstem. Zespół określa sposób pobrania danych, uprawnienia i zachowanie po zmianie użytkownika. Ekran zgłasza zamknięcie przez ustalony kontrakt. Jeżeli pozwala wykonać operację, na przykład anulować zamówienie, trzeba dodatkowo ustalić, jak sprawdzić jej wynik po utracie odpowiedzi. Brak odpowiedzi na ekranie nie może być samodzielną podstawą do pokazania ani sukcesu, ani pewnej porażki.

Nie jest to porównanie pełnej przebudowy z naprawą aplikacji. To ocena konkretnej granicy między działającą częścią natywną a nowym ekranem.

Poniższe scenariusze to propozycja kryteriów odbioru dla opisanego przykładu. Ich oczekiwane wyniki trzeba potwierdzić z właścicielami systemów; nie są raportem z wykonanych testów.

Android opisuje zachowanie Back na poziomie zadań i stosu Activity, z wyjątkami zależnymi od konfiguracji. Dlatego trzeba sprawdzić zachowanie rzeczywistego hosta, a nie przenosić regułę jednego stosu na drugi. Tasks and the back stack — Android.

• Wejście z natywnej listy i powrót. Oczekiwany rezultat do uzgodnienia: Właściwe zamówienie; powrót do ustalonego miejsca bez dodatkowego ekranu lub utraty potrzebnego kontekstu.
• Back, gest cofania, przycisk zamknięcia. Oczekiwany rezultat do uzgodnienia: Spójna obsługa przez uzgodnionego właściciela nawigacji. Androidowy stos Activity i wewnętrzny stos RN nie są traktowane jako ten sam mechanizm.
• Sesja wygasa przy otwieraniu lub po zalogowaniu zewnętrznym. Oczekiwany rezultat do uzgodnienia: Zdefiniowana ścieżka ponownego uwierzytelnienia lub wyjścia; brak danych poprzedniego konta.
• Aplikacja trafia w tło, wraca lub zostaje odtworzona po zakończeniu procesu. Oczekiwany rezultat do uzgodnienia: Stan UI i dane biznesowe są ponownie ustalone zgodnie z kontraktem, bez założenia ciągłości pamięci.
• Operacja została wysłana, ale odpowiedź nie dotarła. Oczekiwany rezultat do uzgodnienia: Użytkownik widzi ustalony stan oczekiwania lub niepewności. Ponowienie nie tworzy drugiej operacji dzięki uzgodnionemu mechanizmowi po stronie odpowiedzialnego systemu.
• Host i RN obserwują ten sam zakup. Oczekiwany rezultat do uzgodnienia: Zdarzenie biznesowe jest liczone raz według wspólnej definicji; ponowne wyświetlenie nie udaje nowego zakupu.
• Kod RN nie uruchamia się lub dane nie mogą zostać odczytane. Oczekiwany rezultat do uzgodnienia: Jest uzgodniona ścieżka błędu i wyjścia, a użytkownik nie otrzymuje fikcyjnego potwierdzenia.
• Nowy ekran zostaje wyłączony. Oczekiwany rezultat do uzgodnienia: Znana jest alternatywna ścieżka i sposób obsługi operacji rozpoczętych przed wyłączeniem.

Wyłączenie punktu wejścia, powrót do poprzedniego widoku i wycofanie całego wydania aplikacji to różne działania. Zespół musi ustalić, które są faktycznie dostępne, kto je uruchamia oraz jak długo stare i nowe kontrakty danych muszą ze sobą współpracować. Istnienie flagi funkcji lub zdalnego wyłączenia nie jest założeniem tego przykładu.

Odtworzenie UI również nie odwraca już przyjętego zamówienia czy innej operacji biznesowej. Dokumentacja Apple o przywracaniu stanu dotyczy odtworzenia interfejsu i wymaga danych oraz obsługi po stronie aplikacji. To nie mechanizm cofania transakcji. Restoring your app’s state — Apple.

Przed decyzją o pierwszym ekranie warto zebrać wersje aplikacji i zależności, diagram nawigacji, zasady sesji, opis operacji, właścicieli wydania oraz oczekiwane zachowanie po błędzie. Z takim materiałem można omówić wykonalność i potwierdzić zakres oceny. Sam opis biblioteki nie przesądza kosztu, terminu ani dopasowania do konkretnej aplikacji.