Wzorce rozwoju Expo

Twój build EAS jest zielony, aplikacja działa w Expo Go na telefonie, a potem ktoś z zespołu dodaje react-native-vision-camera i Expo Go po cichu przestaje ładować aplikację. Połowa Twoich promptów zakłada managed workflow, druga połowa zakłada development build, a AI raz po raz generuje kod dla tego wariantu, który akurat zgadło. Lekarstwem nie jest „używaj AI częściej” - jest nim podanie AI dwóch faktów, które naprawdę określają projekt Expo: na jakim SDK jesteś i czy uruchamiasz Expo Go, czy development build.

Ten przepis pokazuje przepływy pracy z Expo, które przetrwają zderzenie z EAS, weryfikacją w sklepie z aplikacjami i aktualizacjami SDK, prowadzone przez Cursor, Claude Code i Codex.

Co z tego wyniesiesz

• Prompt do szkieletu, który przypina wersję Expo SDK i typ workflow, żeby AI przestało zgadywać
• Gotowy do wklejenia prompt na chroniony autoryzacją layout zakładek Expo Router, który radzi sobie z wyścigiem przekierowania
• Prompt do konfiguracji NativeWind, który tworzy typowany motyw, a nie tylko ciągi className
• Prompt na EAS Build + aktualizacje OTA wpięte w GitHub Actions przez serwer GitHub MCP
• Mapę „Gdy to się sypie” z trybami awarii, które naprawdę kosztują dzień pracy: aktualizacje SDK, niezgodność z Expo Go, poświadczenia EAS i niedopasowanie środowiska uruchomieniowego przy OTA

Tworzenie szkieletu aplikacji Expo

Największą dźwignią dla jakości wyniku jest wskazanie wersji SDK i typu workflow na samym początku. Na czerwiec 2026 aktualną linią jest Expo SDK 56 (React Native 0.85, React 19.2, Hermes jako domyślny silnik). Przypnij ją.

Cursor

Otwórz Cursor w pustym folderze, wejdź w tryb Agent (Cmd/Ctrl + I) i wklej:

Scaffold a new Expo SDK 56 app using npx create-expo-app@latest with the TypeScript template. Add Expo Router (file-based routing), NativeWind v4 for styling, and configure a development build (not Expo Go) because we will add native modules later. Set up eas.json with development, preview, and production profiles.

Tryb Agent uruchamia CLI, edytuje app.json/eas.json i pokazuje diff przed zastosowaniem. Przejrzyj profile w eas.json, zanim je zaakceptujesz.

Claude Code

Z pustego katalogu:

claude "Scaffold an Expo SDK 56 app with create-expo-app (TypeScript template), \
Expo Router, NativeWind v4, and an eas.json with development/preview/production \
profiles. We need a development build, not Expo Go."

Claude Code uruchamia scaffolder, a następnie w tej samej sesji iteruje po plikach konfiguracyjnych. Użyj kontynuacji w stylu claude "now add a typed env config with expo-constants and zod validation", żeby utrzymać kontekst.

Codex

W Codex CLI prompty są pozycyjne. Z pustego katalogu:

codex "Scaffold an Expo SDK 56 app with create-expo-app (TypeScript template), \
Expo Router, and NativeWind v4. Configure eas.json with development, preview, \
and production profiles for a development build."

Przy długo działającej konfiguracji EAS, której nie chcesz niańczyć, użyj codex --full-auto (sandbox workspace-write, zatwierdzenia na żądanie) albo przekaż zadanie do Codex Cloud, żeby uruchomił scaffold i otworzył PR.

Uwaga

Rozróżnienie managed-vs-bare zniknęło, ale rozróżnienie Expo Go vs development build już nie. Expo Go dostarcza tylko moduły, które Expo dołącza do siebie. W momencie, gdy dodasz natywny moduł firm trzecich (vision-camera, SDK płatności, własną wtyczkę konfiguracyjną), potrzebujesz development build (npx expo run:ios / eas build --profile development). Powiedz AI, który wariant jest celem, albo napisze kod, który „działa” w Expo Go i sypie się każdemu na development build.

Expo Router: zakładki chronione autoryzacją

Routing oparty na plikach to miejsce, gdzie idzie najwięcej czasu w Expo, a przekierowanie bramki autoryzacji to miejsce, gdzie siedzi najwięcej błędów: przekieruj, zanim layout się zamontuje, a dostaniesz ostrzeżenie „navigate before mounting the Root Layout”; przekieruj w renderze, a na jedną klatkę mignie chroniona treść.

Wskazówka

Gotowy do wklejenia prompt na chroniony autoryzacją layout zakładek Expo Router:

Build an Expo Router layout for SDK 56 with a (tabs) group for signed-in users and an (auth) group for login/register. Use a React context (useSession) backed by expo-secure-store for the token. In the root _layout.tsx, gate navigation with <Stack.Protected guard={isSignedIn}> so unauthenticated users only see (auth) routes - do not call router.replace during render. Show a SplashScreen until the session has finished loading from SecureStore. Include the file tree and the full app/_layout.tsx.

AI powinno wyprodukować drzewo takie jak poniżej oraz pasujące pliki layoutu:

app/
  _layout.tsx        // SessionProvider + Stack.Protected guard
  (auth)/
    _layout.tsx
    login.tsx
  (tabs)/
    _layout.tsx      // Tabs
    index.tsx
    profile.tsx

Jak ocenić wynik: potwierdź, że utrzymuje splash screen z SplashScreen.preventAutoHideAsync(), dopóki SecureStore się nie rozwiąże, oraz że bramka używa Stack.Protected (SDK 53+), a nie useEffect + router.replace, które powoduje mignięcie przy przekierowaniu. Jeśli widzisz router.replace w ścieżce renderowania, odeślij to z poleceniem „move the guard out of render.”

Stylowanie z NativeWind

Pułapka promptów dla NativeWind to ściana className="bg-blue-500" z magicznymi wartościami. Poproś o typowany motyw, żeby kolory pochodziły z jednego miejsca.

Wskazówka

Gotowy do wklejenia prompt na typowany motyw NativeWind z dark mode:

Configure NativeWind v4 for this Expo SDK 56 app. Define brand colors (primary, surface, danger) as CSS variables in global.css and map them in tailwind.config.js so bg-primary works in both light and dark mode. Wire useColorScheme from nativewind to follow the system theme with a manual override stored in SecureStore. Generate a typed <Button variant="primary | danger" loading> component using these classes with a pressed-state opacity animation via Pressable.

Odrzuć pierwszą wersję, jeśli przycisk wpisuje wartości szesnastkowe na sztywno zamiast bg-primary - cały sens polega na tym, że zmiana brandingu to modyfikacja jednego pliku.

EAS Build, aktualizacje OTA i CI

Tutaj serwer GitHub MCP zarabia na swoje miejsce. Bez niego AI pisze wiarygodnie wyglądający eas-build.yml, wklejasz go, pushujesz i odkrywasz, że nazwy sekretów są błędne. Z podłączonym serwerem GitHub MCP agent czyta Twoje rzeczywiste repozytorium - istniejące workflow, nazwy sekretów, ochronę gałęzi - i pisze CI, które pasuje.

Konfiguracja jest identyczna we wszystkich trzech narzędziach (to oficjalny zdalny serwer GitHub MCP):

Cursor

Dodaj do .cursor/mcp.json:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

Claude Code

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Przy pierwszym użyciu zautoryzuj się poleceniem /mcp wewnątrz REPL.

Codex

Dodaj do ~/.codex/config.toml:

[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"

Wskazówka

Gotowy do wklejenia prompt na EAS Build + OTA w GitHub Actions (z podłączonym serwerem GitHub MCP):

Using the GitHub MCP server, read this repo’s existing .github/workflows and configured secrets. Then create a workflow that runs eas build --profile preview --platform all --non-interactive on pull requests and eas update --branch production on pushes to main. Use the EXPO_TOKEN secret for auth - if a differently named token secret already exists, use that instead and tell me. Gate the build job on the existing lint/test jobs rather than duplicating them.

Uwaga

eas update dostarcza zmiany w JS/zasobach przez sieć (over the air), ale aktualizacja OTA może działać tylko na buildzie, którego natywne środowisko uruchomieniowe się zgadza. Jeśli podbijesz expo-updates, dodasz natywny moduł albo zmienisz runtimeVersion, musisz najpierw wypuścić nowy build do sklepu - w przeciwnym razie starsze instalacje po cichu przestaną otrzymywać aktualizacje. Uczyń politykę runtimeVersion jawną w prompcie ("runtimeVersion": { "policy": "appVersion" }), żeby AI nie generowało aktualizacji, które zostawiają użytkowników na lodzie.

Powiadomienia push

Powiadomienia Expo mają jeden produkcyjny haczyk, który AI rutynowo pomija: musisz wysłać token push do swojego backendu i obsłużyć deep link przy dotknięciu powiadomienia, a nie tylko poprosić o uprawnienie.

Wskazówka

Gotowy do wklejenia prompt na kompleksowe powiadomienia push w Expo:

Implement push notifications for this Expo SDK 56 app using expo-notifications. Register for a push token with getExpoPushTokenAsync, POST it to /api/devices on login, and re-register when the token changes. Configure a Notifications.setNotificationHandler that shows banners in foreground. Add a useLastNotificationResponse handler that deep-links a tapped notification to the right Expo Router screen. Include the Android channel setup and the iOS aps-environment entitlement note for the dev vs production APNs key.

Gdy to się sypie

Mobile to obszar, gdzie pewność siebie AI najbardziej rozjeżdża się z rzeczywistością. Cztery tryby awarii poniżej to te, które naprawdę kosztują dzień:

• Zepsucie przy aktualizacji SDK. npx expo install expo@^56 to łatwa część; przechodnie zależności natywne i wtyczki konfiguracyjne już nie. Uruchom npx expo-doctor i wklej jego pełny wynik do AI z poleceniem: „We just upgraded to SDK 56. Here is expo-doctor output. Fix each version mismatch using npx expo install --fix, and flag any third-party package with no SDK 56 support.” Nie pozwól AI ręcznie edytować wersji w package.json - expo install rozwiązuje zgodne zakresy.
• „Działa w Expo Go, ale nie na development build” (lub odwrotnie). To prawie zawsze moduł, którego nie ma w Expo Go, albo wtyczka konfiguracyjna, która działa tylko podczas prebuild. Powiedz AI, które środowisko zawodzi, i poproś o sprawdzenie, czy moduł wymaga development build oraz wpisu wtyczki konfiguracyjnej w app.json.
• Poświadczenia i provisioning EAS. Gdy eas build zawodzi na podpisywaniu, wklej log buildu. Zwykli winowajcy to wygasły certyfikat dystrybucyjny Apple lub brakujący klucz push. Poproś AI o zinterpretowanie konkretnego błędu EAS, zamiast regenerować poświadczenia na ślepo - eas credentials jest interaktywne i destrukcyjne przy niewłaściwym użyciu.
• Niedopasowanie środowiska uruchomieniowego OTA. Jeśli eas update „kończy się sukcesem”, ale urządzenia nigdy go nie pobierają, runtimeVersion aktualizacji nie pasuje do żadnego zainstalowanego buildu. Każ AI porównać wersję środowiska uruchomieniowego aktualizacji z najnowszym buildem ze sklepu, zanim założysz, że pipeline aktualizacji jest zepsuty.

Notatka

Do triażu awarii podłącz hostowany serwer Sentry MCP (https://mcp.sentry.dev/mcp), żeby agent mógł pobrać rzeczywisty stack trace i breadcrumbs dla danego wydania, zamiast zgadywać ze zrzutu ekranu. Wtyczka Sentry dla Expo (@sentry/react-native z wtyczką konfiguracyjną Expo) wgrywa source mapy przy buildach EAS, więc agent widzi zsymbolizowane trace’y. Kompromis względem jednorazowego skilla: serwer MCP to trwałe, odpytywalne połączenie z Twoimi realnymi błędami - warte tego, gdy już wypuszczasz do sklepów.

Co dalej

• Wzorce React Native dla bare workflow i szczegółów modułów natywnych
• Wzorce rozwoju Flutter, jeśli porównujesz stosy cross-platform
• Integracja backendu dla API, z którym rozmawiają Twoje endpointy tokenów urządzeń i synchronizacji