Zrzuty ekranu App Store dla aplikacji Expo: dlaczego EAS Submit ich nie tworzy i jak je szybko przygotować (2026)

Jeśli wysyłasz aplikację Expo, twoja ścieżka wydania pewnie kończy się jedną linią: eas submit. Bierze build wyprodukowany przez EAS i przekazuje go do Apple lub Google. Czysto, nudno, niezawodnie. Potem otwierasz App Store Connect, żeby uruchomić build — i miejsca na zrzuty ekranu są puste. Za każdym razem.

Wielu deweloperów jest tym zaskoczonych, bo EAS sprawia wrażenie, jakby robił wszystko. Buduje, podpisuje, wysyła. Chyba zajmuje się też zrzutami ekranu? Nie zajmuje się, a dokumentacja mówi to wprost. To nie jest błąd ani brakująca funkcja, którą można zgłosić — to po prostu wykracza poza zakres EAS Submit.

Co EAS Submit faktycznie robi (i czego nie robi)

EAS Submit to usługa dostarczania pliku binarnego. Przesyła dokładnie jedno: skompilowane archiwum aplikacji — .ipa dla iOS, .aab dla Android — do pipeline'u przetwarzania w sklepie. Dokumentacja Expo precyzyjnie określa tę granicę:

„EAS Submit przesyła plik binarny, ale nie zarządza metadanymi opisu sklepowego, zrzutami ekranu ani informacjami o wydaniu.”

Istnieje też siostrzane narzędzie, EAS Metadata, które potrafi zautomatyzować części opisu sklepowego App Store — nazwę aplikacji, podtytuł, zlokalizowane opisy, słowa kluczowe, adresy URL wsparcia — na podstawie pliku konfiguracyjnego. Jest naprawdę przydatne i warto je skonfigurować. Ale przeczytaj uważnie jego zakres: zrzuty ekranu nie wchodzą w grę. EAS Metadata przesyła tekst, nie obrazy. Twoje zrzuty ekranu — w obu sklepach — musisz nadal samodzielnie przygotować i przesłać.

Problem z zrzutami ekranu w Expo dzieli się więc na dwa odrębne zadania, i warto trzymać je osobno w głowie:

1. Przechwytywanie — pobranie surowych klatek rzeczywistych ekranów aplikacji z buildu.
2. Kompozycja i lokalizacja — przekształcenie tych surowych klatek w oprawione, podpisane, wielojęzyczne panele marketingowe, które sklepy faktycznie wyświetlają.

EAS nie robi żadnego z tych dwóch. Własne wytyczne Expo dotyczące zasobów sklepowych odsyłają do samodzielnego przechwytywania klatek i projektowania paneli w narzędziu takim jak Figma. Omówimy oba zadania z konkretnymi poleceniami.

Zadanie 1: przechwytywanie klatek z buildu deweloperskiego lub podglądowego

Potrzebujesz zrzutów ekranu rzeczywistej aplikacji, więc musisz mieć aplikację uruchomioną w miejscu, z którego możesz ją przechwycić. W przypadku Expo oznacza to dev client lub preview build — nie Expo Go, bo Expo Go pokazuje interfejs opakowujący Expo, a twoja konfiguracja natywna może się różnić. Zbuduj i uruchom lokalnie za pomocą standardowych poleceń Expo:

• npx expo run:ios — prebuilduje natywne iOS, kompiluje i uruchamia aplikację w symulatorze iOS.
• npx expo run:android — to samo dla emulatora Android (lub podłączonego urządzenia).

Gdy aplikacja jest widoczna w symulatorze iOS, przechwycenie to jedno polecenie z terminala na Macu:

xcrun simctl io booted screenshot home.png

booted celuje w aktualnie uruchomiony symulator i zapisuje pikselowo dokładny PNG w bieżącym katalogu roboczym. Dwie flagi mają znaczenie przy pracy ze sklepem: --type=png (domyślna, i tego chcą sklepy) oraz --mask=ignored kontra --mask=black — maska kontroluje, czy wcięcie i zaokrąglone narożniki są renderowane do obrazu. Do przesyłania w App Store zazwyczaj chcesz płaskie, prostokątne piksele, a ramkę urządzenia dodajesz później podczas kompozycji — więc przechwytywanie bez maski to zwykle właściwy punkt startowy.

Na Android przechwyć bezpośrednio z emulatora (lub urządzenia) za pomocą adb:

adb exec-out screencap -p > home.png

Używaj exec-out, nie shell screencap. Zwykła ścieżka przez shell przesyła PNG przez pseudo-terminal, który psuje plik binarny na niektórych konfiguracjach (dostajesz uszkodzony plik ze zbłąkanymi znakami powrotu karetki); exec-out przesyła bajty bezpośrednio i jest niezawodną formą. Jeśli uruchamiasz kilka emulatorów, wskaż konkretny przez adb -s <serial> z adb devices.

To cały zestaw do ręcznego przechwytywania: dwa polecenia, jedno na platformę, bez zależności poza Xcode i Android SDK, które masz już na potrzeby natywnego buildu Expo.

Zadanie 1, automatycznie: Maestro lub Detox

Ręczne nawigowanie do właściwego ekranu i uruchamianie tych poleceń jest w porządku dla kilku ujęć. Gdy masz osiem ekranów w dwóch klasach urządzeń, lub chcesz, żeby zrzuty ekranu były regenerowane przy każdym wydaniu tak, żeby nigdy nie rozjeżdżały się z rzeczywistym interfejsem, automatyzujesz przechwytywanie za pomocą narzędzia do testów end-to-end, które potrafi sterować aplikacją i robić klatki.

Maestro to narzędzie, po które sam Expo sięga w udokumentowanych przykładach EAS Workflows. Przepływy są w zwykłym YAML, co obniża próg wejścia. Przepływ, który prowadzi do ekranu i go przechwytuje, wygląda tak:

appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard

Uruchom go poleceniem maestro test flows/home.yaml. Polecenie takeScreenshot zapisuje PNG do katalogu wyjściowego testów (ustaw MAESTRO_TESTS_DIR tam, gdzie chcesz, żeby trafiały zasoby). Te same przepływy działają w CI na EAS Workflows — udokumentowany przykład Expo buduje .apk z profilem budowania e2e-test i uruchamia przepływ z .maestro/ — więc możesz podpiąć przechwytywanie zrzutów ekranu do tego samego zadania, które obsługuje twój pakiet e2e.

Detox to druga sprawdzona opcja, z bardziej programistycznym JavaScript API:

const path = await device.takeScreenshot('dashboard');

Bądź jednak ze sobą szczery w kwestii konfiguracji Detox z Expo. Detox oficjalnie nie wspiera Expo. W praktyce działa, jeśli użyjesz npx expo prebuild do wygenerowania natywnych projektów i zbudujesz klienta w stylu release (nie dev client), tak żeby pakiet JS był osadzony — a następnie wskażesz Detox ten plik binarny. To więcej ruchomych elementów niż YAML Maestro, a korzyść to ściślejsza synchronizacja i API asercji Detox. Jeśli już używasz Detox, wykorzystaj go do przechwytywania; jeśli dopiero wybierasz i twoim celem są zrzuty ekranu do sklepu, Maestro to lżejsza droga.

Zadanie 1, ręcznie: właściwy wybór przy rzadkich wydaniach

Automatyzacja opłaca się, gdy publikujesz często. Jeśli robisz jedno do trzech wydań rocznie — co opisuje większość indie aplikacji Expo — podłączanie przepływów Maestro lub konfiguracji Detox do przechwytywania zrzutów ekranu to praca, którą płacisz raz i ledwie amortyzujesz. Przy takim rytmie po prostu:

1. Uruchom build przez npx expo run:ios / run:android, uzupełnij realistycznymi danymi demo.
2. Przejdź ręcznie do każdego kluczowego ekranu.
3. Przechwyć każdy poleceniem simctl / adb opisanym powyżej.

Dwadzieścia minut klikania bije pół dnia konfigurowania frameworka testowego, który zapomnisz jak utrzymywać przed następnym wydaniem. Nie ma nic złego w ręcznym przechwytywaniu — sklepy nie wiedzą, w jaki sposób powstał PNG.

Zadanie 2: kompozycja i lokalizacja na 50 języków

Tu jest ta część, której narzędzia do przechwytywania celowo nie dotykają, a zarazem ta, na której sklepy faktycznie cię oceniają. Surowy PNG z simctl to interfejs twojej aplikacji na białym tle. To, co rankinguje w wyszukiwaniu i konwertuje na stronie produktu, to marketingowy panel: zrzut ekranu wewnątrz ramki urządzenia, na brandowym tle, z jednolinijkowym podpisem wyjaśniającym, dlaczego dany ekran ma znaczenie — zwykle jako wielopanelowa karuzela czytana od lewej do prawej. W App Store zrzuty ekranu są lokalizowane per rozmiar urządzenia i per język, więc poważna premiera to dziesiątki wariantów, nie pięć.

To jest dokładnie to miejsce, w którym mieści się Mokbi, i warto precyzyjnie opisać tę granicę. Mokbi nie przechwytuje twojej aplikacji — nadal produkujesz źródłowe klatki za pomocą poleceń Expo opisanych powyżej. Mokbi bierze te klatki i pozwala ci, w przeglądarce: wrzucić je do prawdziwych ramek urządzeń, dodać podpisy i gradientowe tła, ułożyć wielopanelowe karuzele, jednym kliknięciem przetłumaczyć teksty podpisów na 50 języków i wsadowo wyeksportować każdy wymagany rozmiar App Store i Play Store naraz. Projektujesz bezpłatnie z podglądowym znakiem wodnym; nieograniczony eksport wymaga subskrypcji — Solo €29.99/mo (1 aplikacja) lub Studio €49.99/mo (do 5 aplikacji), bez zakupu jednorazowego. Zastępuje etap szablonu Figma, który poradnik Expo jedynie napomyka — nic więcej, nic mniej.

Realistyczny połączony przepływ pracy

1. Zbuduj dev/preview client. npx expo run:ios i npx expo run:android, uzupełnione dobrymi danymi demo.
2. Przechwyć źródłowe klatki. Ręcznie przez xcrun simctl io booted screenshot i adb exec-out screencap -p, lub automatycznie przez Maestro takeScreenshot / Detox device.takeScreenshot — najlepiej na EAS Workflows, żeby regenerowały się przy każdym wydaniu.
3. Skomponuj panele marketingowe. Opraw, podpisz i ułóż karuzelę z surowych klatek.
4. Zlokalizuj i wyeksportuj wsadowo. Przetłumacz podpisy na docelowe języki, wyeksportuj każdy wymagany rozmiar dla obu sklepów.
5. Prześlij zasoby do opisu. Zrzuty ekranu do App Store Connect i Play Console; uzupełnij EAS Metadata dla pól tekstowych, jeśli go używasz.
6. Wyślij plik binarny. eas submit — jedyny krok, który EAS naprawdę wykonuje.
7. Przy kolejnym wydaniu: ponownie przechwyć zmienione ekrany, otwórz zapisany projekt kompozycji, zamień klatki, wyeksportuj ponownie. Podpisy i tłumaczenia zostają.

Kiedy możesz pominąć automatyzację

Sięgnij po Maestro lub Detox, gdy rozbieżność zrzutów ekranu to realny koszt: publikujesz co tydzień, twój interfejs ciągle się zmienia lub obsługujesz wiele aplikacji i nie możesz sobie pozwolić na przestarzałe obrazy w sklepie. W takich przypadkach klatki regenerowane w CI zwracają się z nawiązką, a narzędzia do zrzutów ekranu React Native (które Expo dziedziczy) to inwestycja warta zachodu.

Dla wszystkich pozostałych — publikujących raz na kwartał — pomiń to. Ręczne przechwytywanie dwoma poleceniami terminalowymi, a następnie kompozycja i lokalizacja w przeglądarce, pozwala dojść do dopracowanego, wielojęzycznego opisu w jedno popołudnie bez niczego do utrzymywania między wydaniami. Dopasuj narzędzia do swojego rytmu, nie do tego, co wygląda imponująco na tablicy CI.

W każdym przypadku połowa z plikiem binarnym jest rozwiązana: eas submit się tym zajmuje. Przed przesłaniem sprawdź zrzuty ekranu pod kątem aktualnych wymagań sklepu — Apple odrzuca opis przez jeden piksel różnicy — i resztę premiery to już tylko design.

Co przeczytać dalej

• Dla deweloperów Expo
• Zrzuty ekranu App Store dla React Native
• Porównanie: Mokbi vs Fastlane
• Rozmiary zrzutów ekranu App Store
• Wymagania dotyczące zrzutów ekranu App Store

Otwórz edytor →