React Native 0.76 i React 18: Praktyczny przewodnik po optymalizacji wydajności aplikacji mobilnych

Why Modern React Native Performance Matters More Than Ever

W 2025 roku wydajność aplikacji mobilnych przestała być luksusem, a stała się podstawowym wymogiem rynkowym. Użytkownicy oczekują niemal natychmiastowego uruchamiania, płynnych animacji oraz reakcji interfejsu bez opóźnień, niezależnie od jakości sieci czy klasy urządzenia. W sklepach z aplikacjami konkurencja jest ogromna, a różnice rzędu kilkuset milisekund w czasie startu lub opóźnione reakcje na dotyk realnie wpływają na retencję i przychody.

React Native od lat pozostaje jednym z głównych wyborów przy budowie wieloplatformowych aplikacji mobilnych. Jednocześnie wiele zespołów nadal korzysta z przestarzałych wersji, co ogranicza ich możliwości w zakresie optymalizacji. Wersja React Native 0.76 w połączeniu z React 18 stanowi istotny punkt zwrotny: umożliwia wykorzystanie nowoczesnych mechanizmów wydajnościowych bez konieczności porzucania istniejącej bazy kodu.

Kluczowa zmiana polega na tym, że poprawa wydajności nie wymaga już pełnego przepisania aplikacji. Nowe narzędzia i mechanizmy można wdrażać stopniowo, ekran po ekranie. Z tego powodu coraz częściej obserwuje się, że zespoły średnio zaawansowanych programistów React Native – które już dostarczają aplikacje produkcyjne – zaczynają planować modernizację środowiska uruchomieniowego i narzędzi, zamiast pełnych rewritów.

Fundamentem współczesnej optymalizacji React Native są trzy filary techniczne:

• szybszy bundling i rozwiązywanie modułów dzięki nowoczesnemu Metro,
• automatyczne batchowanie aktualizacji stanu w React 18,
• renderowanie współbieżne z wykorzystaniem transitions, które utrzymują responsywność interfejsu.

Te mechanizmy bezpośrednio przekładają się na krótszy czas uruchamiania aplikacji oraz bardziej płynne działanie interfejsu. Nie koncentrują się na teoretycznych benchmarkach, ale na konkretnych wzorcach, które można zastosować w istniejących projektach.

Część zespołów rozważa dziś alternatywne rozwiązania, takie jak Svelte czy Solid, które oferują inne modele reaktywności. Warto je znać i porównać, na przykład korzystając z analiz takich jak Svelte vs React: The End of an Era?, jednak w praktyce nowoczesny React Native nadal ma bardzo duży potencjał optymalizacyjny, jeśli zostanie odpowiednio skonfigurowany.

Niniejszy materiał ma formę pogłębionego przewodnika. Pokazuje on, jak krok po kroku przejść na React Native 0.76+ z React 18, jak wykorzystać usprawnienia Metro, jak skorzystać z automatycznego batchowania oraz renderowania współbieżnego, a następnie jak przenieść te rozwiązania na konkretne ekrany w istniejącej aplikacji. Celem jest, aby czytelnik zakończył lekturę z praktyczną listą priorytetów oraz wzorcami, które można wdrożyć w ciągu najbliższego tygodnia prac.

Upgrading Safely to React Native 0.76 and React 18 Without a Rewrite

Najważniejszym krokiem w kierunku poprawy wydajności jest samo przejście na nowoczesne wersje narzędzi. React Native 0.76 i React 18 otwierają drogę do wykorzystania nowej architektury, szybszego bundlowania, automatycznego batchowania i renderowania współbieżnego. Bez tego większość opisanych dalej zysków pozostanie niedostępna.

W uproszczeniu można powiedzieć, że aktualizacja obejmuje trzy wymiary:

• aktualizację samego rdzenia React Native (runtime, integrację z natywnymi platformami),
• aktualizację React do wersji 18, która wprowadza automatic batching i concurrency,
• unowocześnienie otoczenia: TypeScript, definicji typów, bibliotek trzecich oraz konfiguracji CI.

Podejście powinno być konserwatywne i oparte na ograniczaniu ryzyka. W praktyce dobrze sprawdza się praca na osobnym branchu oraz wyraźne etapy pośrednie:

• utworzenie dedykowanej gałęzi aktualizacyjnej w systemie kontroli wersji,
• użycie narzędzia react-native upgrade-helper, aby porównać obecną wersję z docelową i zobaczyć konieczne zmiany,
• uruchomienie komendy npx react-native upgrade, a następnie ręczne przejrzenie zmian w package.json,
• sprawdzenie, czy wersje react i react-native są zgodne z oficjalną dokumentacją danej wersji RN,
• aktualizacja TypeScript oraz pakietów @types do wersji rekomendowanych przez społeczność dla tej konfiguracji,
• uruchomienie pełnego zestawu testów oraz pipeline CI po każdej większej zmianie.

Na każdym etapie warto budować stagingowe wersje aplikacji, które mogą zostać przekazane wewnętrznym użytkownikom do szybkiej weryfikacji. Pomaga to wychwycić błędy, których nie pokażą testy automatyczne, takie jak subtelne regresje w nawigacji czy gestach.

Typowe pułapki obejmują przestarzałe API usunięte z React Native, a także biblioteki trzecie, które nie są jeszcze zgodne z nową wersją. Dobrą praktyką jest sporządzenie listy zależności kluczowych dla aplikacji oraz sprawdzenie, czy ich repozytoria i zgłoszone błędy potwierdzają kompatybilność z RN 0.76 i React 18. W razie problemów warto tymczasowo przytrzymać pojedynczą bibliotekę na starszej wersji lub zastąpić ją alternatywą o lepszym wsparciu.

Aktualizacja nie oznacza konieczności zmiany całej struktury kodu. Większość komponentów i ekranów może pozostać w dotychczasowej formie. Zmienia się głównie środowisko uruchomieniowe, które staje się szybsze i bogatsze w funkcje, w tym te związane z wydajnością.

Wielu programistów, którzy sceptycznie podchodzili do hooków i nowoczesnych wzorców React, miało za sobą doświadczenia z ich niewłaściwym użyciem – z efektami ubocznymi, podwójnymi renderami czy trudnymi do śledzenia zależnościami. Te problemy są szerzej opisane w analizie ukrytych kosztów stosowania hooków. Uporządkowana ścieżka aktualizacji, połączona z przeglądem wzorców w kodzie, pomaga uniknąć ponownego wpadania w te same pułapki oraz lepiej wykorzystać nowe możliwości React 18.

Przed przejściem do optymalizacji wydajności warto zatrzymać się i upewnić, że kilka kluczowych warunków zostało spełnionych:

• aplikacja buduje się poprawnie na docelowych platformach,
• zestaw testów jednostkowych i integracyjnych przechodzi bez regresji,
• aplikacja uruchamia się na urządzeniach z React Native 0.76+ i React 18, bez krytycznych błędów w podstawowych przepływach użytkownika.

Accelerating Startup with Metro Resolver and Bundle Optimizations

Metro to domyślny bundler i resolver modułów w projektach React Native. Odpowiada za analizę zależności, łączenie plików JavaScript w paczki wykorzystywane przez aplikację oraz obsługę zmian podczas developmentu. Jego sprawność wpływa nie tylko na czas budowania i szybkość hot reload, ale także – w przypadku dużych projektów – na czas uruchamiania samej aplikacji.

Nowoczesne wersje Metro wprowadziły szereg usprawnień: inteligentniejsze cache’owanie, bardziej wydajny system monitorowania plików oraz szybsze algorytmy rozwiązywania ścieżek modułów. W praktyce przekłada się to na krótsze czasy bundlowania i mniejszą liczbę pełnych przebudowań.

Konfiguracja w pliku metro.config.js stała się realnym narzędziem optymalizacyjnym. Kilka obszarów warto rozważyć w pierwszej kolejności:

• włączenie inline requires, aby opóźnić ładowanie części modułów do momentu, gdy faktycznie są potrzebne,
• dostosowanie liczby maxWorkers do zasobów maszyny buildowej, aby skrócić czas bundlowania,
• korzystanie z nowoczesnego resolvera oraz wykluczenie z analizy ścieżek, które nie są potrzebne (katalogi testowe, duże, nieużywane zasoby),
• konsekwentne porządkowanie zależności, aby uniknąć powielania tego samego kodu w wielu częściach bundla.

Istotnym elementem jest redukcja rozmiaru początkowego bundla. Im mniej kodu musi zostać załadowane i zinterpretowane przy pierwszym uruchomieniu, tym szybciej użytkownik zobaczy pierwszy ekran. W React Native możliwe jest stosowanie prostych strategii podziału kodu, na przykład za pomocą dynamicznego importowania modułów.

Typowymi kandydatami do opóźnionego ładowania są:

• rozbudowane ekrany konfiguracyjne odwiedzane rzadko,
• ciężkie biblioteki analityczne i marketingowe,
• skomplikowane komponenty wizualizacyjne, takie jak wykresy czy mapy.

Można je ładować dopiero po wyrenderowaniu pierwszej ramki – na przykład korzystając z React.lazy lub dynamicznego import() wywoływanego w efektach, które nie blokują renderowania elementarnego interfejsu. Użytkownik w pierwszej kolejności widzi więc prostą, lekką strukturę, a cięższe moduły dołączane są później.

Aby ocenić efekt takich zmian, warto mierzyć metryki związane z zimnym startem. Proste podejście zakłada rejestrowanie czasu w kluczowych punktach: tuż po uruchomieniu aplikacji, w momencie wyświetlenia pierwszego widocznego ekranu oraz po załadowaniu głównych danych. Dane te można wysyłać do systemu analitycznego lub zapisywać lokalnie na potrzeby testów.

Dla biznesu skrócenie startu o kilkaset milisekund może oznaczać zauważalny wzrost wskaźników aktywacji i pierwszego użycia. Użytkownik, który widzi natychmiastową reakcję na tapnięcie w ikonę, ma wrażenie obcowania z dopracowanym, solidnym produktem, co przekłada się na większą skłonność do pozostania w aplikacji.

Jeśli mimo optymalizacji Metro i podziału kodu nadal pojawiają się wątpliwości co do narzutu związanego z bundlowaniem w środowisku React, warto zapoznać się z perspektywą lżejszych frameworków – na przykład w analizie porównującej Svelte i React z punktu widzenia rozmiaru bundla i narzutu runtime. Takie porównanie dobrze uzupełnia pracę optymalizacyjną, choć w większości przypadków poprawna konfiguracja Metro i dobór strategii ładowania modułów w React Native pozwalają uniknąć kosztownego przepisania aplikacji.

Harnessing Automatic Batching in React 18 for Smoother UI Updates

React 18 wprowadził automatyczne batchowanie aktualizacji stanu, co ma bezpośredni wpływ na wydajność aplikacji mobilnych. W poprzednich wersjach wiele wywołań setState lub useState skutkowało wieloma osobnymi renderami, szczególnie jeśli pochodziły z różnych asynchronicznych źródeł, takich jak zapytania sieciowe, timery czy zdarzenia natywne.

Automatic batching polega na tym, że React potrafi inteligentnie grupować aktualizacje stanu w jednym cyklu renderowania, nawet jeśli są one rozproszone w czasie i pochodzą z różnych miejsc w kodzie. Dla React Native oznacza to mniej pracy wykonywanej na głównym wątku JavaScript, a tym samym płynniejsze animacje i interakcje – zwłaszcza na słabszych urządzeniach.

Dla programisty efekt jest często „bezpłatny”: istniejące sekwencje wielu wywołań aktualizacji stanu w obrębie jednego zdarzenia lub łańcucha asynchronicznego zaczynają być batchowane automatycznie. Zdarzenia takie jak kliknięcie przycisku, odpowiedź z API czy callback z setTimeout nie powodują już serii pojedynczych renderów, lecz jedną, skondensowaną aktualizację interfejsu.

Warto jednak mieć świadomość kilku konsekwencji. Po pierwsze, niektóre efekty uboczne, które wcześniej uruchamiały się wielokrotnie przy każdej pojedynczej zmianie stanu, mogą teraz zostać wywołane rzadziej, bo React połączy kilka zmian w jedno renderowanie. Po drugie, istnieją sytuacje, w których konieczne jest natychmiastowe odświeżenie widoku – wtedy React pozwala na świadome wyłączenie batchowania i wymuszenie synchronizacji za pomocą flushSync, co powinno być stosowane bardzo oszczędnie.

Aby w pełni wykorzystać automatic batching, opłaca się uporządkować zarządzanie stanem. Zamiast wielu pól stanu opisujących ten sam fragment logiki biznesowej, lepiej zastosować reduktory lub struktury danych, które aktualizuje się jednym zwięzłym wywołaniem. Redukuje to złożoność i ułatwia myślenie o tym, co dokładnie powinno się zmienić podczas danego renderu.

Pomaga również unikanie „pochodnego stanu”, który można wyliczyć na bieżąco z innych danych, oraz przenoszenie efektów ubocznych do useEffect z przemyślanymi zależnościami. Dzięki temu batched renderowanie pozostaje przewidywalne: wiesz, kiedy i dlaczego efekty się uruchamiają.

Sprawdzenie, czy mechanizm przynosi oczekiwane korzyści, można przeprowadzić na kilka sposobów. React DevTools pozwala profilować liczbę renderów poszczególnych komponentów i ich czas trwania. Prostsze, choć mniej eleganckie metody to logowanie w konsoli każdej instancji renderu lub implementacja prostych liczników w stanie aplikacji, eksportowanych do narzędzi analitycznych.

Wiele nieporozumień wokół hooków i zarządzania stanem wynikało z obserwacji zachowania React przed wprowadzeniem automatic batching. Problemy takie jak niespodziewane podwójne rendery czy trudne do zrozumienia sekwencje efektów ubocznych zostały opisane szerzej m.in. w tekście The Dark Side of React Hooks Nobody Talks About. React 18 łagodzi część z tych zjawisk, ale jednocześnie wymaga przemyślenia, jak najlepiej strukturyzować stan pod kątem batchowania. Zrozumienie interakcji między hookami a automatycznym grupowaniem aktualizacji jest kluczowe w bardziej złożonych bazach kodu.

Using Concurrent Rendering and Transitions to Keep the UI Feeling Instant

Najbardziej widoczną nowością React 18 dla użytkownika końcowego jest renderowanie współbieżne (concurrent rendering) oraz transitions. W praktyce oznacza to, że React potrafi przygotowywać cięższe aktualizacje widoku „w tle”, nie blokując przy tym podstawowych interakcji – takich jak wpisywanie tekstu czy przewijanie listy.

Dwa kluczowe narzędzia udostępnione programiście to startTransition oraz hook useTransition. Pozwalają one oznaczyć część aktualizacji stanu jako mniej pilną (non-urgent). React może wtedy priorytetyzować szybkie odpowiedzi na działania użytkownika, a cięższe przeliczenia i głębokie zmiany w drzewie komponentów wykonywać wtedy, gdy nie zaburzają płynności.

Przykładem może być ekran wyszukiwania w dużej liście produktów. W klasycznym podejściu każda zmiana w polu tekstowym powodowała natychmiastowe przefiltrowanie tysięcy elementów i ponowne wyrenderowanie całej listy. Na słabszych urządzeniach skutkowało to wyraźnymi przycięciami: użytkownik widział opóźnienia podczas wpisywania kolejnych liter, a przewijanie listy stawało się szarpane.

Zastosowanie transitions pozwala rozdzielić te dwa światy. Aktualizacja stanu powiązanego bezpośrednio z polem tekstowym pozostaje „pilna” i wykonywana jest natychmiast, co zapewnia płynne wpisywanie. Natomiast przeliczenie wyników wyszukiwania i odświeżenie listy można opakować w startTransition. W efekcie React najpierw reaguje na klawiaturę, a następnie aktualizuje widok, gdy tylko ma na to „okno czasowe”. Użytkownik widzi lekkie, możliwie natychmiastowe UI, a zaktualizowane wyniki pojawiają się chwilę później, bez zauważalnego zrywania animacji.

Hook useTransition udostępnia dodatkowo flagę isPending, której można użyć do wyświetlania subtelnego wskaźnika zajętości, takiego jak mały spinner w obszarze wyników czy prosty skeleton. Dzięki temu interfejs pozostaje czytelny: wiadomo, że aplikacja „pracuje” nad aktualizacją, ale nie sprawia wrażenia zawieszonej.

Kluczowym zadaniem zespołu staje się rozróżnienie, co w aplikacji jest „pilne”, a co może zostać przesunięte w czasie. Bezpośrednie reakcje na dotknięcia, gesty, nawigację czy krytyczne komunikaty błędów powinny pozostać aktualizacjami o najwyższym priorytecie. Natomiast złożone przeliczenia, zapytania sieciowe generujące dużą liczbę zmian w drzewie komponentów czy głębokie odświeżanie zagnieżdżonych list często mogą zostać oznaczone jako transitions.

Warto przy tym podkreślić, że renderowanie współbieżne nie oznacza wielowątkowości w klasycznym sensie. JavaScript w środowisku React Native wciąż działa w jednym wątku. Zyski wynikają z mądrzejszego planowania prac przez React i możliwości przerywania oraz wznawiania renderowania tak, by nie blokować interakcji użytkownika. Nie zwalnia to jednak zespołu z obowiązku unikania ciężkich, synchronicznych operacji na wątku JS.

Dyskusja o concurrency w React pojawia się często w kontekście porównań z innymi bibliotekami reaktywnymi. Solid.js, na przykład, stawia na bardzo drobnoziarnistą reaktywność, w której aktualizacje propagują się wyłącznie do bezpośrednio zależnych fragmentów UI. Zespoły zainteresowane tym podejściem mogą sięgnąć po analizę Solid.js: The React Killer Nobody Is Talking About, która zestawia te różne filozofie projektowania interfejsu. Dla wielu istniejących projektów React Native wprowadzenie transitions i concurrent rendering będzie jednak prostszą drogą do wyraźnej poprawy responsywności bez zmiany całego stosu technologicznego.

Dobrym punktem wyjścia jest identyfikacja najbardziej odczuwalnych spowolnień w aplikacji – najczęściej są to wyszukiwarki, listy z rozbudowanymi filtrami lub ekrany raportowe – i eksperymentowanie z transitions właśnie w tych miejscach, zanim rozpocznie się szersze refaktoryzacje.

Practical Patterns to Modernize Legacy Screens Without Starting From Scratch

Dla wielu organizacji pełne przepisanie aplikacji mobilnej jest po prostu nierealne – ze względów kosztowych, czasowych lub ryzyka biznesowego. Zdecydowanie bardziej realistycznym podejściem jest modernizacja istniejących ekranów w sposób stopniowy, z zachowaniem dotychczasowej logiki biznesowej i układu interfejsu.

Pierwszym krokiem powinno być zidentyfikowanie najbardziej problematycznych miejsc. Dane analityczne, opinie użytkowników oraz wewnętrzne testy użyteczności pozwalają wskazać ekrany, na których użytkownicy odczuwają największe opóźnienia. To tam inwestycja w optymalizację przyniesie najszybszy i najbardziej wymierny zwrot.

Dla typowego ekranu legacy można zaplanować sekwencję działań modernizacyjnych:

• stopniowe przechodzenie na komponenty funkcyjne tam, gdzie jest to zasadne,
• weryfikacja zgodności z funkcjami React 18, w tym z automatycznym batchowaniem,
• uporządkowanie zarządzania stanem pod kątem batchowania (reduktory, context, nowoczesne biblioteki),
• lazy loading ciężkich podkomponentów i komponentów zależnych od dużych bibliotek,
• owinięcie kosztownych aktualizacji w transitions, aby nie blokowały one interfejsu,
• audyt efektów i nasłuchiwaczy zdarzeń pod kątem wycieków pamięci i zbędnych subskrypcji.

Przykładowy ekran listy, wcześniej zaimplementowany jako komponent klasowy z wieloma wywołaniami setState w odpowiedziach z API i handlerach zdarzeń, można przekształcić w komponent funkcyjny, który:

• używa useReducer do skupienia modyfikacji stanu w jednym miejscu,
• korzysta z automatic batching, aby ograniczyć liczbę renderów,
• stosuje memoizowane selektory danych, dzięki którym przeliczenia są wykonywane tylko wtedy, gdy jest to konieczne,
• wydziela cięższe elementy (np. nagłówki raportów, wykresy) do komponentów ładowanych dynamicznie,
• otacza kosztowne operacje filtrowania lub sortowania listy w startTransition, aby zachować płynne przewijanie.

Istotne jest, że taka modernizacja nie musi – i zwykle nie powinna – zmieniać zachowania biznesowego ekranu. Użytkownik widzi znajomy układ, te same akcje i te same dane, ale subiektywnie odczuwa znacznie większą płynność i szybkość działania. Z perspektywy zespołu ryzyko regresji biznesowych jest dużo niższe niż w przypadku całkowitego przepisania funkcjonalności.

Wyzwanie mogą stanowić biblioteki trzecie – w szczególności rozwiązania nawigacyjne lub komponenty UI, które nie zostały jeszcze zaktualizowane pod kątem współbieżnego renderowania. W takich sytuacjach dobrym rozwiązaniem jest „otulenie” ich cienką warstwą własnych komponentów, które pełnią rolę adapterów. Umożliwia to stosowanie transitions i nowoczesnych struktur stanu w kodzie aplikacji, jednocześnie zachowując kompatybilność z mniej elastycznymi zależnościami.

Modernizacja bywa też momentem, w którym zespoły zastanawiają się, czy React Native pozostaje najlepszym wyborem na kolejne lata. Porównania z alternatywami – takimi jak Svelte – można znaleźć w analizach typu Svelte vs React: The End of an Era?. Takie materiały warto traktować jako uzupełnienie wiedzy i kontekst strategiczny, a nie jako automatyczną rekomendację do migracji. W praktyce wiele aplikacji może odzyskać znaczną część potencjału wydajnościowego, pozostając w ekosystemie React Native i skupiając się na systematycznej modernizacji.

Kluczowe jest dokumentowanie zmian wraz z mierzalnymi rezultatami. Przed i po każdej optymalizacji warto zanotować czas ładowania ekranu, liczbę dropów klatek czy wyniki testów syntetycznych. Daje to materiał dowodowy, który buduje zaufanie interesariuszy do inwestycji w wydajność i ułatwia uzasadnianie kolejnych etapów modernizacji.

Measuring Success and Building a Long-Term Performance Culture

Najnowocześniejsze mechanizmy optymalizacji nie przyniosą trwałej poprawy, jeśli w zespole nie powstanie kultura systematycznego dbania o wydajność. Kluczowe dźwignie to poprawa konfiguracji Metro i wielkości bundla, wykorzystanie automatic batching do ograniczenia zbędnych renderów oraz świadome używanie renderowania współbieżnego i transitions, aby interakcje pozostały płynne.

Wszystko to musi być jednak powiązane z pomiarem. Nawet średnio zaawansowane zespoły mogą wdrożyć prosty, ale skuteczny framework monitorowania. Składa się on z kilku elementów:

• zdefiniowania docelowych metryk, takich jak czas zimnego startu, czas do pierwszej interakcji oraz liczba dropów klatek na kluczowych ekranach,
• instrumentacji aplikacji, która rejestruje te wartości i przesyła do systemów analitycznych lub logów,
• wprowadzania zmian wydajnościowych w formie kontrolowanych eksperymentów (A/B lub stopniowe rollouty),
• porównywania wyników sprzed i po optymalizacji, aby ocenić faktyczny wpływ.

Realistyczne efekty często zawierają się w przedziale kilkuset milisekund skrócenia startu aplikacji oraz znaczącej poprawy odczuwalnej płynności na najbardziej obciążonych ekranach, takich jak wyszukiwarki czy listy z filtrami. Dla użytkownika są to różnice, które łatwo wychwycić: aplikacja „po prostu działa szybciej”.

W dłuższej perspektywie warto wbudować w proces wytwórczy regularne „haczyki” wydajnościowe. Każda nowa funkcja powinna przechodzić krótką sesję profilowania, konfiguracja metro.config.js i ustawienia React (w tym użycie transitions i struktur stanu przyjaznych batchowaniu) powinny stać się stałym elementem przeglądów technicznych. Monitorowanie produkcyjne z kolei powinno systematycznie wskazywać wolne ścieżki, które wymagają uwagi.

Pomocne może być również tworzenie wewnętrznych wzorców architektonicznych: dokumentów pokazujących, kiedy stosować transitions, jak organizować stan, aby korzystać z automatic batching, oraz jak konfigurować Metro dla nowych modułów i zależności. Standaryzacja sprawia, że każdy nowy fragment kodu z większym prawdopodobieństwem będzie od razu napisany w sposób przyjazny wydajności.

Alternatywne stosy technologiczne – takie jak Solid.js czy Svelte – oferują odmienne modele wydajności i często bardzo lekkie runtime’y, co opisują m.in. analizy Solid.js i Svelte vs React. Równolegle jednak większość zespołów może odzyskać znaczącą część potencjału wydajnościowego, nie porzucając React Native, a raczej konsekwentnie wykorzystując jego nowoczesne możliwości.

React Native będzie w kolejnych latach ewoluować, przynosząc dalsze usprawnienia architektury i narzędzi. Zespoły, które już dziś zainwestują w aktualizację do wersji 0.76+, adopcję React 18 oraz budowę kultury pracy z wydajnością, będą dużo lepiej przygotowane na te zmiany. Pozwoli im to korzystać z nowych możliwości z minimalnymi zakłóceniami, jednocześnie zapewniając użytkownikom szybkie, płynne i konkurencyjne aplikacje mobilne.