Expo czy bare React Native w 2026: kiedy co ma sens

Mit "bare workflow, kiedy wyrośniesz z Expo" jest nieaktualny od dwóch lat. Oto jak to wygląda naprawdę.

TL;DR

W 2026 Expo managed workflow z EAS Build jest właściwym domyślnym wyborem dla prawie każdego projektu React Native. Stara reguła "bare workflow, gdy potrzebujesz natywnych modułów" już nie działa, bo Expo SDK 53 i nowsze obsługuje praktycznie każde natywne API przez config plugins albo pierwszoklasowe API. Bare workflow wybieraj tylko wtedy, gdy masz konkretny natywny moduł, którego nie da się opakować, albo kontrybuujesz do samego rdzenia React Native. Większość historii "poszliśmy w bare dla elastyczności" kosztowała zespół od 3 do 6 miesięcy i skończyła się wolniej dowiezioną aplikacją. Poniżej realne ramy decyzyjne na 2026.

Najważniejsze fakty

• Expo SDK 53 (koniec 2024) i SDK 54 (początek 2026) dodały obsługę niemal wszystkich produkcyjnych API natywnych.

• Config plugins i Expo Modules pozwalają opakować dowolny kod natywny bez ejectowania.

• EAS Build, EAS Update i EAS Submit ogarniają CI/CD, aktualizacje OTA i wysyłkę do sklepów jako usługa zarządzana.

• Zespół Expo zatrudnia sporą część kontrybutorów rdzenia React Native, a oba workflowy szybko się zbiegają.

• Wejście w bare w 2026 to prawdziwa decyzja inżynierska, a nie domyślna ścieżka rozwoju projektu.

Co zmieniło się między 2024 a 2026

Przez lata mądrość ludowa mówiła: "zacznij od Expo do prototypu, zrób eject do bare React Native, gdy potrzebujesz elastyczności". Ta rada była trafna w latach 2018 do 2022. Dziś w większości przypadków jest błędna.

Co się zmieniło:

1. Expo Modules. Pierwszoklasowe API do pisania kodu natywnego, który działa i w managed, i w bare. Piszesz Swift albo Kotlin w projekcie Expo bez ejectowania.

2. Config plugins. Modyfikujesz natywną konfigurację iOS i Androida z JavaScriptu na etapie buildu. Prawie każdy przypadek "muszę edytować Info.plist" jest rozwiązany.

3. EAS Build. Chmurowy pipeline buildów, który ogarnia podpisywanie, provisioning i wysyłkę. Koniec z lokalnym utrzymywaniem Xcode, Android Studio i fastlane.

4. Pierwszoklasowe API natywne w Expo SDK. HealthKit, App Tracking Transparency, zakupy w aplikacji (przez expo-iap), background fetch, push notyfikacje, BLE (przez expo-bluetooth), kamera w wysokiej jakości, system plików, secure storage, biometria. Expo pokrywa prawie wszystko.

5. Reanimated, gesture handler i inne kluczowe biblioteki są pierwszoklasowe w managed workflow.

Efekt: historyczny argument "bare daje więcej elastyczności" dotyczy dziś wąskiego zestawu przypadków brzegowych.

Kiedy wybrać Expo managed (domyślny wybór w 2026)

Wybierz Expo, jeśli którekolwiek z tych pasuje:

• Robisz konsumencką aplikację B2C ze standardowym zestawem funkcji (logowanie, paywall, AI, media).

• Chcesz, żeby EAS Build ogarnął CI/CD i wysyłki do sklepów.

• Chcesz aktualizacji OTA przez EAS Update.

• Chcesz najkrótszej drogi od pomysłu do App Store.

• Nie masz mocnego powodu, żeby lokalnie zarządzać Xcode i Android Studio.

To pokrywa mniej więcej 95 procent projektów mobilnych w 2026.

Boilerplate Ship React Native używa Expo managed workflow, bo to właściwy wybór dla aplikacji, które dowozi Silpho.

Kiedy wybrać bare workflow

Wybierz bare React Native, jeśli którekolwiek z tych pasuje:

• Używasz natywnego modułu, który nie ma wrappera w Expo i sensownie nie da się go opakować (bardzo rzadkie w 2026).

• Pracujesz w mocno kontrolowanym środowisku korporacyjnym, gdzie pipeline buildu musi działać on-premise, bez usług zewnętrznych.

• Kontrybuujesz do rdzenia React Native.

• Prowadzisz długi projekt, który zaczął jako bare w 2020, a koszt migracji przewyższa korzyści.

• Musisz dzielić kod natywny (Swift, Kotlin) z osobnym zespołem iOS/Android w tym samym monorepo.

Twarda prawda: większość projektów na bare w 2026 jest bare z powodów historycznych, nie technicznych.

Porównanie obok siebie

"A co, jeśli wyrosnę z Expo"

Ten strach pojawia się w dwóch scenariuszach.

Scenariusz 1: potrzebujesz natywnego modułu, którego nie ma

W 2026 to rzadkość. Zanim to zaakceptujesz, sprawdź:

• Czy istnieje wrapper w Expo? (Poszukaj w npm expo- plus nazwa modułu.)

• Czy istnieje wrapper społecznościowy? (Poszukaj w npm react-native- plus nazwa modułu.)

• Czy sam napiszesz cienki Expo Module wokół kodu natywnego? (W większości przypadków od 1 do 3 dni.)

Jeśli wszystkie trzy odpowiedzi to nie, bare jest uzasadniony. Ale "może kiedyś będę tego potrzebować" nie jest powodem, żeby zaczynać od bare.

Scenariusz 2: potrzebujesz egzotycznej konfiguracji buildu

Przykłady: specjalne wymagania podpisywania, architektury hybrydowe, własny pipeline CI. Większość z tego rozwiązują config plugins.

Jeśli naprawdę nie da się tego zrobić przez config plugins, bare jest uzasadniony. Dalej rzadkie w 2026.

A co z ejectem z managed do bare?

Ścieżka migracji istnieje (npx expo prebuild), ale dla większości projektów to drzwi w jedną stronę. Po ejekcie powrót do managed wymaga cofnięcia wszystkich zmian w kodzie natywnym.

Właściwe podejście: nie myśl o bare jak o "managed plus więcej". Myśl o bare jak o osobnym workflow z własnymi kompromisami. Wybierz właściwy na starcie i się go trzymaj.

Różnice w wydajności

Dla 99 procent aplikacji nie ma różnicy w wydajności między managed a bare. Runtime jest ten sam.

Ten 1 procent to aplikacje ekstremalnie wrażliwe na wydajność (multiplayer w czasie rzeczywistym, niskopoziomowe przetwarzanie wideo), gdzie bare daje więcej swobody wokół modułów natywnych. Nawet tam Reanimated, gesture handler i Skia w managed pokrywają większość potrzeb wydajnościowych w UX.

Co mówi sam zespół React Native

W 2024 zespół React Native ogłosił zbliżenie z Expo i zarekomendował Expo managed workflow jako domyślny dla nowych projektów. Bare workflow pozostaje wspierany, ale nie jest już rekomendowanym punktem startu.

To nie jest zagrywka marketingowa. Luka w możliwościach faktycznie się zamknęła.

FAQ

Czy Expo obsłuży każde natywne API, którego kiedykolwiek będę potrzebować?

Przy aplikacjach konsumenckich w 2026: tak. Przy aplikacjach korporacyjnych albo specjalistycznych (obronność, medycyna regulowana, głęboka integracja z IoT): prawdopodobnie tak, ale zweryfikuj konkretne API, zanim się zwiążesz.

Ile kosztuje EAS?

Darmowy plan pokrywa małe projekty. Plan produkcyjny to 399 zł miesięcznie za nielimitowane buildy i funkcje zespołowe. Większość indie founderów zostaje na darmowym, agencje i małe zespoły przechodzą na produkcyjny dla priorytetu w kolejce buildów.

Czy managed workflow ma karę wydajnościową?

Nie. Runtime jest identyczny. Rozmiar bundle bywa nieco większy, bo Expo dorzuca domyślnie więcej API. Po optymalizacji Hermesa to pomijalne.

Co z aplikacjami, które zaczęły przed SDK 53?

Jeśli jesteś na Expo SDK 50 albo nowszym, aktualizacja do 53 albo 54 jest prosta. Jeśli jesteś na SDK 49 albo starszym, czeka Cię kilka migracji z breaking changes, ale nie zmiana workflow.

Czy mogę dodać kod natywny do projektu Expo managed?

Tak. Expo Modules pozwalają pisać w Swift i Kotlin i wołać to z JavaScriptu. Zostajesz na managed workflow.

A jeśli potrzebuję aktualizacji over-the-air?

EAS Update jest oficjalnym narzędziem. Obsługuje stopniowe wdrożenia, kanały i rollbacki. CodePush od Microsoftu jest wycofany od 2025, więc tam nie zaczynaj.

Czy nowa architektura React Native (Fabric, Turbo Modules) działa w managed?

Tak. Nowa architektura jest domyślnie włączona w SDK 54 i nowszych dla nowych projektów managed. Istniejące projekty mogą ją włączyć w konfiguracji.

Jakie jest stanowisko Silpho?

Boilerplate Ship React Native i każdy projekt klienta w Silpho używa Expo managed workflow z EAS. Boilerplate przychodzi ze skonfigurowanym EAS Build, EAS Update i EAS Submit. Na tym stacku dowieźliśmy ponad 25 aplikacji.

Następne kroki:

• Weź boilerplate Ship React Native oparty na Expo

• Albo zleć Silpho dowiezienie aplikacji

Powiązane:

• Build EAS się wywala na produkcji? Co naprawić przed launchem

• Ile kosztuje zbudowanie aplikacji mobilnej w 2026?