Dlaczego odejście Shopify od React Native nie zagraża Expo
Wyjaśnia, dlaczego przejście Shopify z React Native na natywny Swift i Kotlin nie oznacza końca rozwoju aplikacji wieloplatformowych przy użyciu Expo dla większości zespołów.
10 września 2026 roku Shopify poinformował, że usuwa swoje podstawowe aplikacje mobilne z React Native i odbudowuje je w formie natywnej przy użyciu Swift i Kotlin. W ciągu zaledwie kilku godzin fora programistyczne wypełniły się spekulacjami. W dyskusjach na mediach społecznościowych toczyły się debaty na temat tego, czy oznacza to koniec React Native. Kilka wpisów na blogach posunęło się nawet do stwierdzenia, że rozwój aplikacji mobilnych międzyplatformowych dobiegł końca.
Jeśli korzystasz z Expo, nic z tego nie powinno cię martwić.
Co tak naprawdę zrobił Shopify — i dlaczego
Uzasadnienie podane przez Shopify było dość proste: asystenci do pisania kodu oparte na AI znacznie obniżyły koszty utrzymania dwóch oddzielnych baz kodu natywnego dla iOS i Android. Pierwotną zaletą React Native było oszczędzanie czasu inżynierów poprzez współdzielenie kodu między platformami. Gdy narzędzia AI potrafią szybko generować kod natywny w językach Swift i Kotlin, takie rozliczenia zmieniają się dla organizacji o wielkości Shopify.
Kluczowym elementem jest „organizacja tak duża jak Shopify”.
Shopify obsługuje jedną z najbardziej skomplikowanych aplikacji mobilnych na świecie – z setkami inżynierów, milionami sprzedawców oraz wymaganiami wydajnościowymi, które wystawiają na próbę każdą architekturę. Gdy Shopify twierdzi, że sztuczna inteligencja sprawiła, iż rozwój aplikacji w formacie natywnym stał się bardziej dostępny cenowo, mówi to z pozycji firmy, która potrafi jednocześnie zarządzać dwoma dużymi, złożonymi bazami kodu.
Większość deweloperów używających Expo nie znajduje się w takiej sytuacji, podobnie jak typowe zespoły tworzące aplikacje obecnie.
Expo i Shopify rozwiązują różne problemy
Dla Shopify React Native był przede wszystkim sposobem na obniżenie kosztów w ogromnej organizacji inżynieryjnej. Dla deweloperów Expo React Native to narzędzie, które pozwala pojedynczemu twórcy lub małej grupie wydać kompletną, dopracowaną aplikację zarówno na iOS, jak i Android, bez konieczności bycia specjalistą od żadnej z tych platform.
Te dwa przypadki użycia prawie w niczym się nie przypominają.
Expo ma dedykowany zespół podstawowy, który od lat doskonali jedno z najlepszych doświadczeń deweloperskich w świecie mobilnym. Niedawno wydane SDK 57 przyniosło dalsze ulepszenia pod względem wydajności, narzędzi do budowania aplikacji oraz ergonomii pracy deweloperów na co dzień. Biblioteki takie jak NativeWind, Reanimated i Expo Router są bardziej stabilne i gotowe do użycia w produkcji niż kiedykolwiek wcześniej.
To wszystko nie zmieni się tylko dlatego, że jakiś duży detalista zdecydował się przenieść na inne rozwiązanie.
Liczby opowiadają inną historię
Podczas gdy komentatorzy zajmowali się stwierdzaniem, że React Native jest już ukończony, dane dotyczące jego adopcji wskazywały inaczej.
NativeWind, rozwiązanie do stylizacji w stylu Tailwind CSS dla React Native, osiągnął 1,3 miliona tygodniowych pobierania w 2026 roku i nadal rośnie. Expo pozostaje ważnym elementem w społecznościach programistów i dyskusjach. Nowsze biblioteki do stylizacji, takie jak Uniwind, zostały wprowadzone i już w ciągu zaledwie kilku miesięcy zdobyły setki tysięcy tygodniowych pobierania.
Ty te liczby nie opisują ekosystemu, który się kurczy. Opisują ekosystem, który wciąż dojrzewa.
Ludzie, którzy porzucili React Native w momencie ogłoszenia przez Shopify, to prawdopodobnie ci sami, którzy i tak znaleźliby jakiś inny powód do odejścia w przyszłym miesiącu. Programiści, którzy rzeczywiście tworzą produkty przy użyciu Expo, nie przemyślają niczego na nowo.
Sztuczna inteligencja przyspiesza rozwój w Expo, a nie sprawia, że staje się ono przestarzałe
W argumentacji, że to sztuczna inteligencja zabiła React Native, kryje się prawdziwa ironia: narzędzia oparte na sztucznej inteligencji w rzeczywistości znacznie ułatwiły pracę z Expo, a nie utrudniły ją.
Asystenci tacy jak Claude, Cursor i GitHub Copilot doskonale rozumieją ekosystem Expo. Dzięki dobrze zorganizowanemu plikowi CLAUDE.md, który dokumentuje konwencje komponentów i wzorce architektoniczne, jeden z tych asystentów może dodać nowe ekrany, rozwijać funkcjonalności oraz refaktoryzować istniejący kod, zachowując spójność z resztą bazy kodu.
Ludzie, którzy czerpią największe korzyści z tego procesu pracy, czasami nazywani „vibe coders”, ponieważ opisują zamierzony wynik i pozwalają asystentowi zająć się implementacją, nadal potrzebują solidnej struktury wyjściowej. Narzędzia AI doskonale radzą sobie z pisaniem kodu, ale są znacznie mniej niezawodne przy podejmowaniu decyzji architektonicznych, projektowaniu ścieżek nawigacji, tworzeniu systemów tematycznych czy budowaniu spójnego zestawu komponentów od zera.
To właśnie tę lukę wypełnia dobrze przygotowany szablon startowy dla Expo. Nie chodzi tu o kod, który asystent AI mógłby wygenerować na żądanie – chodzi o podstawową strukturę, która sprawia, że kodowanie z wykorzystaniem AI jest rzeczywiście produktywne.
Szablony stanowią podstawową warstwę w rozwoju wspomaganym przez AI
Gdy programista otwiera Cursor lub Claude, aby rozpocząć pracę nad nowym aplikacją, pierwszym istotnym pytaniem jest to, od jakiej bazy kodowej będzie startował.
Rozpoczynanie od czystego wyniku wygenerowanego przez create-expo-app oznacza spędzenie pierwszych godzin na konfiguracji nawigacji, dodaniu obsługi trybu ciemnego, budowie podstawowych komponentów interfejsu oraz ustaleniu konwencji. Sztuczna inteligencja może pomóc w niektórych częściach tej pracy, ale nadal wymaga ludzkich decyzji, konfiguracji oraz wielokrotnych modyfikacji, zanim powstanie użyteczna baza.
Rozpoczęcie natomiast od gotowego do użycia szablonu oznacza, że prace przygotowawcze są już zakończone. Otwierasz edytor sterowany sztuczną inteligencją, opisujesz funkcję, którą chcesz dodać, a asystent ma już spójną i dobrze zorganizowaną bazę kodu do rozbudowy.
Dlatego właśnie szablony zaprojektowane z myślą o procesach wspomaganych przez sztuczną inteligencję — zawierające szczegółową dokumentację w formacie CLAUDE.md, jasne notatki na poziomie komponentów oraz spójne wzorce — są dziś ważniejsze niż dwa lata temu, a nie mniej.
Rozwijający, którzy naprawdę powinni się martwić
Jeśli decyzja Shopify powinna kogoś zaniepokoić, to rozwijających tworzących proste aplikacje React Native poza ekosystemem Expo, którzy polegają bezpośrednio na narzędziu React Native CLI oraz obsługujących klientów na poziomie korporacyjnym, posiadających wystarczającą liczbę inżynierów, by uzasadnić pełne rozwijanie aplikacji w formacie natywnym.
To opisuje dość wąski zakres osób korzystających z React Native.
Jeśli natomiast jesteś niezależnym rozwijającym, freelancerem, małym studiem lub kimś, kto tworzy swoją pierwszą aplikację głównie poprzez opisywanie jej asystentowi AI, Expo pozostaje najszybszą drogą od pomysłu do gotowej aplikacji na obu głównych platformach mobilnych. Decyzja Shopify nic nie zmienia w tych założeniach.
Co to oznacza dla ciebie
Kontynuuj rozwój z użyciem Expo. Kontynuuj publikowanie aplikacji za pomocą Expo. Ekosystem jest w dobrym stanie, narzędzia stale się udoskonalają z każdą nową wersją, a społeczność wokół niego nie znika.
Jeśli rozpoczynasz nowy projekt React Native, zacznij od gotowego szablonu przygotowanego do produkcji, a nie od pustego projektu, i pozwól asystentom AI zająć się szczegółami implementacji na tej podstawie. Taka kombinacja pozwala ci publikować aplikacje szybciej, niż to możliwe przy pracy od zera.
Część programistów spędzi nadchodzące tygodnie na czytaniu kontrowersyjnych opinii i kwestionowaniu swoich wyborów technologicznych z powodu ogłoszenia jednej firmy. Inni po prostu będą kontynuować publikowanie swoich aplikacji.
Dąż do należenia do drugiej grupy.
Literatura pokrewna
- Nitro Modules: Jak staticzne wiązania przewyższają React Native TurboModules — Wyjaśnia, w jaki sposób Nitro Modules wykorzystuje uprzednio skompilowane staticzne wiązania zamiast dynamicznego wyszukiwania, dzięki czemu znacznie przewyższają TurboModules i Expo Modules w React Native.
- React Native, Flutter i inne: Mobilne rozwiązania krośn platformowe w 2026 roku — Porównawcze omówienie React Native, Flutter, Kotlin Multiplatform, Ionic, NativeScript oraz PWA pod kątem wydajności, doświadczenia programisty i dojrzałości ekosystemu.