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

Aplikacja Expo działa w preview, a produkcyjny build EAS pada, zanim zdążysz wysłać cokolwiek na TestFlight albo do App Store.

TL;DR

Padający produkcyjny build EAS to nie losowy problem Expo. Zwykle znaczy, że aplikacja opiera się na lokalnym stanie, rozjechanych natywnych paczkach, brakujących produkcyjnych zmiennych środowiskowych, starych certyfikatach albo konfiguracji, która działa tylko w Expo Go. Zacznij od odczytania fazy, w której build padł, potem odtwórz warunki jak najbliższe produkcji. Jeśli błąd jest odizolowany, popraw zależność, konfigurację, certyfikat albo asset i zbuduj ponownie. Jeśli każda poprawka rodzi nową awarię, przestań łatać i zaudytuj fundament. Zepsuty produkcyjny build blokuje launch, bo wysyłka do App Store, płatności, analityka, usuwanie konta i testy recenzenta zależą od jednego działającego binarium.

Najważniejsze fakty

• EAS Build startuje z czystego środowiska, więc obnaża brakujące pliki, brakujące zmienne i lokalne założenia.

• Sukces w Expo Go nie dowodzi, że natywne moduły, config plugins, podpisywanie i build release są gotowe.

• Użyteczna wskazówka to pierwsza padająca faza buildu, a nie ostatnia ogólna linijka "build failed".

• Produkcyjne profile buildu padają często dlatego, że używają innych zmiennych, bundle identifiers, schematów, certyfikatów albo kanałów update.

• Aplikacje Expo budowane przez AI dokładają paczki, dopóki preview nie zadziała, i tym psują produkcyjną ścieżkę buildu.

• Naprawiaj istniejącą aplikację, gdy padająca faza jest jasna, a drzewo zależności da się wytłumaczyć.

• Przepisz, gdy nikt nie potrafi wyjaśnić paczek, natywnej konfiguracji, logowania, płatności i profili buildu.

Diagnoza: co jest naprawdę zepsute

Najczęstsze błędne założenie: to EAS zepsuł działającą aplikację. Zwykle EAS po prostu pokazuje, że aplikacja nigdy nie była gotowa na produkcję.

Lokalny development w Expo jest wybaczający. Masz sekrety w lokalnym shellu, zbuforowane projekty natywne, stan symulatora i assety, które akurat leżą na Twoim dysku. Produkcyjny build EAS startuje z czystego checkoutu. Właśnie dlatego awarie wychodzą pierwszy raz tam.

Czytaj log buildu po fazach. Etykieta ma znaczenie:

• Install dependencies: menedżer paczek, lockfile, wersja Node, peer dependency albo konflikt natywnej zależności.

• Prebuild: konfiguracja aplikacji, config plugin, uprawnienia, generowanie projektu natywnego albo rozjazd Expo SDK.

• CocoaPods albo Gradle: problem z natywną zależnością na iOS lub Androidzie, wersja SDK, brakujący zasób, niekompatybilny moduł.

• Bundle JavaScript: błąd składni, brakujący plik, wielkość liter w imporcie, ścieżka do assetu albo konfiguracja Metro.

• Signing albo credentials: bundle ID, provisioning profile, certyfikat, keystore albo rozjazd w App Store Connect.

• Submit albo post-build: binarium jest poprawne, ale dostarczenie do sklepu albo dostęp do konta są złe.

Pierwszy prawdziwy błąd zwykle siedzi nad finalnym komunikatem. "Gradle build failed with unknown error" to opakowanie, nie diagnoza.

Przy buildach Expo wspieranych przez AI wzorzec jest przewidywalny. Cursor, Lovable, Bolt, Replit, Rork i podobne narzędzia szybko generują ekrany, ale optymalizują pod następny widoczny błąd w terminalu. Stąd wymuszone instalacje, stare paczki, zdublowane biblioteki, natywne moduły bez config plugins, paczki webowe w natywnych przepływach albo sekrety, które istnieją tylko w lokalnym .env.

Produkcyjne awarie EAS wpadają zwykle w pięć kubełków.

Po pierwsze, konfiguracja aplikacji jest niespójna. Bundle identifier, nazwa pakietu, schemat, pluginy, uprawnienia albo runtime version różnią się między buildem lokalnym a profilem produkcyjnym. Typowe, gdy app.json, app.config.js, eas.json i foldery natywne się rozjeżdżają.

Po drugie, zależności nie pasują do Expo SDK. Paczka może zainstalować się lokalnie, a paść przy prebuildzie, Podach, Gradle albo bundlowaniu release. Zwykli podejrzani to natywne moduły: zakupy, kamera, notyfikacje, mapy, storage, SDK logowania i analityka.

Po trzecie, brakuje produkcyjnych zmiennych środowiskowych. Zdalny build produkcyjny widzi tylko to, co wrzuciłeś do środowiska EAS albo profilu buildu. Brakujący adres API, klucz Supabase, klucz RevenueCat, schemat OAuth, URL bramki AI albo flaga funkcji potrafią zepsuć build albo wywalić aplikację przy starcie.

Po czwarte, certyfikaty są stare albo rozjechane. Provisioning profiles na iOS, certyfikaty, bundle ID, dostęp do App Store Connect, keystore na Androidzie i nazwa pakietu muszą się zgadzać.

Po piąte, system plików Cię okłamuje. Ścieżki na macOS nie rozróżniają wielkości liter, więc chowają błędy w importach. Pliki z gitignore istnieją lokalnie, ale nie w zdalnym archiwum. Pliki generowane są na Twojej maszynie, a nie ma ich w czystym checkoucie.

Ścieżka naprawy: najpierw wyizoluj fazę buildu

Nie zaczynaj od proszenia narzędzia AI, żeby "naprawiło błąd EAS" bez żadnych granic. To zwykle tworzy drugi problem, zanim ktokolwiek zrozumie pierwszy.

Zacznij od nudnego triage.

1. Otwórz log buildu EAS i znajdź pierwszą padającą komendę.

2. Zapisz platformę, profil buildu, Expo SDK, wersję Node, menedżera paczek i padającą fazę.

3. Odtwórz lokalnie w trybie jak najbliższym release.

4. Napraw jedną przyczynę.

5. Odpal ten sam profil produkcyjny jeszcze raz.

Jeśli pada instalacja zależności, najpierw zablokuj menedżera paczek. Jeden lockfile, jedna wersja Node, jedna komenda instalacji. Wyrzuć paczki, których nie ma na ścieżce do launchu.

Jeśli pada prebuild, obejrzyj konfigurację aplikacji. Sprawdź, czy pluginy są obecne dla tych natywnych modułów, które ich potrzebują. Sprawdź opisy uprawnień i konfigurację per platforma. Jeśli w repo są foldery ios albo android, upewnij się, że zespół świadomie je utrzymuje.

Jeśli padają Pody albo Gradle, przestań traktować to jak buga na ekranie. Jesteś w krainie natywnych zależności. Sprawdź, czy każda natywna paczka wspiera Twoje Expo SDK i wersję React Native. Jeśli jedna paczka wymusza downgrade, wymień paczkę, zanim zatruje fundament.

Jeśli pada bundlowanie JavaScriptu, sprawdź importy, wielkość liter w nazwach plików, brakujące assety, aliasy ścieżek i kod zależny od środowiska. Plik Button.tsx zaimportowany jako button zadziała lokalnie na macOS i padnie na czystym Linuksie.

Jeśli padają certyfikaty, oddziel build od podpisywania. Kod może być w porządku, a tożsamość w Apple albo Google zła. Zweryfikuj bundle ID, aplikację w App Store Connect, provisioning profile, certyfikat, team ID, nazwę pakietu na Androidzie i keystore.

Potem zdecyduj: naprawa czy przepisanie.

Naprawiaj istniejącą aplikację, gdy padająca faza jest konkretna, Expo SDK jest spójne, natywnych modułów jest mało i są znane, profil buildu da się wytłumaczyć, a produkt ma jedną czystą ścieżkę przez onboarding, logowanie, płatności i główną funkcję.

Zaudytuj przed naprawą, gdy aplikacja była generowana albo mocno modyfikowana przez narzędzia AI i nikt nie umie wyjaśnić, dlaczego zestaw paczek wygląda tak, jak wygląda. Ratunek dla aplikacji w Silpho powstał na ten moment: przejrzeć kod Expo albo React Native, wskazać blokery launchu i zdecydować, co naprawić, co wyrzucić, a co napisać od nowa.

Przepisz krytyczną ścieżkę, gdy drzewo zależności jest niestabilne, Expo zostało zdowngradowane pod jedną paczkę, foldery natywne są w repo bez intencji, stan logowania i płatności jest zduplikowany po ekranach, a produkcyjne buildy padają po każdej łatce z innego powodu. Zachowaj zwalidowany pomysł, teksty, kierunek UI, assety i działającą logikę. Wymień fundament, który blokuje launch.

Strona cennika pokazuje produktyzowane ścieżki: Ship React Native Full za 799 zł dla robiących samodzielnie, Kickstart za 1 990 zł netto z boilerplate i pomocą 1 na 1, Launch za 15 900 zł netto z iOS, Androidem i warstwą przychodową oraz Launch + Growth za 23 900 zł netto z pełnym systemem materiałów i optymalizacją ASO.

Porównanie

FAQ

Dlaczego EAS pada, skoro Expo Go działa?

Expo Go to powłoka deweloperska. Nie dowodzi, że Twój samodzielny build natywny, config plugins, podpisywanie, produkcyjne zmienne środowiskowe i bundle release są poprawne. Produkcyjne buildy EAS działają na czystym środowisku i tworzą prawdziwe binarium potrzebne na TestFlight albo do sklepu.

Co sprawdzić najpierw przy padającym buildzie EAS?

Znajdź pierwszą padającą komendę w logu. Nie zatrzymuj się na końcowym "build failed". Padająca faza mówi, czy problem jest w instalacji, prebuildzie, kompilacji natywnej, bundlowaniu JavaScriptu, podpisywaniu czy wysyłce.

Czy usunąć foldery ios i android?

Tylko jeśli rozumiesz, po co tam są. W projektach zarządzanych przez Expo foldery natywne w repo powodują rozjazd konfiguracji, bo EAS może użyć istniejącego projektu natywnego zamiast wygenerować go od nowa. Jeśli projekt świadomie utrzymuje kod natywny, usunięcie folderów kasuje prawdziwą pracę.

Kiedy przepisać zamiast naprawiać build?

Gdy każda poprawka odsłania kolejny problem z zależnościami albo architekturą. Jeśli nikt nie potrafi wyjaśnić zestawu paczek, natywnych modułów, stanu logowania, stanu płatności i profili buildu, awaria buildu jest objawem słabego fundamentu.

Czy naprawiony EAS oznacza gotowość na App Review?

Nie. Udany build produkcyjny to tylko bramka binarium. Dalej potrzebujesz usuwania konta, odpowiedzi o prywatność, informacji o paywallu, restore purchases, analityki, crash reportingu, materiałów do sklepu, notatek dla recenzenta i testów na urządzeniach.

Czy Silpho może naprawić sam problem z EAS?

Czasem tak. Jeśli awaria jest odizolowana, wystarczy skupiona ścieżka ratunkowa. Jeśli build wiąże się z logowaniem, płatnościami, rozjazdem zależności albo gotowością na App Store, lepiej zacząć od audytu, który rozstrzyga naprawę kontra przepisanie.

Następne kroki

• Porównaj opcje launchu i cennik Silpho

• Zacznij od Ratunku dla aplikacji, jeśli awaria EAS wskazuje na kruchy kod

• Przeczytaj przewodnik Expo kontra bare React Native