Jak tworzyć zrzuty ekranu App Store dla aplikacji React Native (2026)

Oto czego nikt ci nie mówi, gdy wysyłasz swoją pierwszą aplikację React Native do App Store: nie ma wbudowanego sposobu na wygenerowanie zrzutów ekranu, których sklep wymaga. Deweloperzy natywni iOS sięgają po rejestrator testów UI Xcode; deweloperzy natywni Android mają Espresso wbudowane w build. React Native siedzi na wierzchu obu, z rzeczywistą logiką aplikacji działającą w JavaScript — i żadne z tych narzędzi nie wie o twoim JS. Musisz samodzielnie wypełnić tę lukę.

Ten wpis opisuje podejścia, które rzeczywiście działają w erze Nowej Architektury (RN 0.7x i nowsze, 2026), z konkretnymi poleceniami. Jest też uczciwy co do kosztów, bo każda z opcji ma swoje realne koszty. Następnie omawia etap, który przychodzi po przechwytywaniu — kompozycja marketingowa i lokalizacja — który jest osobnym problemem niezależnie od tego, w jaki sposób pozyskasz źródłowe klatki.

Rzeczywisty problem: brak własnego pipeline'u

App Store Connect oczekuje zrzutów ekranu o dokładnych wymiarach pikseli — najlepiej po jednym zestawie na klasę urządzenia i jeden zestaw na każdą obsługiwaną lokalizację. Google Play ma swoje własne rozmiary. Natywny projekt iOS może sterować symulatorem przez XCUITest i zapisywać klatki; React Native technicznie też może, ale test, który piszesz, działa na natywnej powłoce — skompilowanym pliku binarnym — nie bezpośrednio na twoich komponentach JavaScript. Automatyzujesz czarną skrzynkę, która akurat renderuje twój JS.

Ta różnica ma większe znaczenie, niż mogłoby się wydawać. Oznacza to, że automatyzacja zrzutów ekranu psuje się z powodów niemających nic wspólnego z twoim kodem React (Metro bundler, który nie był uruchomiony, symulator utknięty na oknie dialogowym uprawnień, natywny build, który rozjechał się z twoim JS), i oznacza to, że krzywa uczenia się jest krzywą dwóch natywnych frameworków testowych, nie twojego znajomego stosu RN. Są trzy poważne drogi przez to. Wybierz na podstawie tego, jak często publikujesz.

Opcja 1 — Fastlane snapshot (iOS) i screengrab (Android)

Fastlane to kanoniczny open-source'owy framework automatyzacji mobilnej, a jego moduły do zrzutów ekranu to najbardziej sprawdzona opcja. To też opcja wymagająca najwięcej pracy przy konfiguracji dla React Native, bo zostały zbudowane dla projektów natywnych i jedynie tolerują RN.

iOS, przez snapshot. Dodajesz cel testowania UI w Xcode i piszesz przypadki testowe XCUITest w Swift, które prowadzą aplikację do każdego ekranu, który chcesz przechwycić. fastlane snapshot init umieszcza Snapfile i SnapshotHelper.swift w folderze fastlane/. W teście wywołujesz setupSnapshot(app), uruchamiasz, a następnie snapshot("01_home") przy każdym stanie. Uruchamiasz to z terminala poleceniem fastlane snapshot — nie z wnętrza Xcode, bo to nie przyniesie poprawnych wyników. Narzędzie przebiega przez każdy symulator i lokalizację w twoim Snapfile i zapisuje PNG-i do fastlane/screenshots/.

Haczyk React Native: snapshot uruchamia skompilowaną aplikację, która w trybie debug potrzebuje już działającego Metro bundlera. Dlatego twój Fastfile (lub skrypt opakowujący) musi najpierw uruchomić Metro — popularny trik to uruchomienie npx react-native start w sesji tmux w tle przed wywołaniem snapshot, a następnie zatrzymanie jej po zakończeniu. Buildy release z wbudowanym pakietem JS unikają tego problemu, ale kosztują cię pełny build release przy każdym uruchomieniu.

Android, przez screengrab. Zupełnie inny framework: screengrab używa Espresso. Dodajesz wywołania Screengrab.screenshot("nazwa") wewnątrz testów instrumentowanych JUnit, deklarujesz uprawnienia (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION i uprawnienia do storage), budujesz debug APK i test APK przez ./gradlew assembleDebug assembleAndroidTest, i uruchamiasz fastlane screengrab. Wyniki trafiają do fastlane/metadata/android/. Podobnie jak na iOS, Metro i emulator muszą być już uruchomione — screengrab nie uruchamia ich za ciebie.

Zalety:

• Zintegrowane z CI, odporne na rozbieżności. Podłącz do swojego pipeline'u, a zrzuty ekranu będą się regenerować przy każdym buildzie wydania, zawsze odpowiadając wysyłanej aplikacji.
• Prawdziwe renderowanie per lokalizacja. Każda lokalizacja uruchamia się w symulatorze/emulatorze z rzeczywistymi ustawieniami locale, więc daty, liczby i waluty renderują się natywnie — nie sfałszowane w narzędziu projektowym.
• Bezpłatne, open-source, dojrzałe. Brak subskrypcji, duża społeczność, dobrze udokumentowane tryby awarii.

Wady (bądź ze sobą szczery):

• Utrzymujesz dwa natywne zestawy testów. XCUITest w Swift dla iOS, Espresso/JUnit w Kotlin/Java dla Android — jako deweloper RN to mogą być dwa nieznane stosy.
• Testy działają na natywnej powłoce, nie na logice JS. Testy operują na renderowanych widokach natywnych; nie są świadome drzewa twoich komponentów.
• Konfiguracja zajmuje dzień lub dwa przy pierwszym podejściu, a taniec z Metro bundlerem to regularnie źródło niestabilnych uruchomień CI.
• Wynik to surowe klatki. Bez podpisów, bez ramek urządzeń, bez gradientów, bez karuzeli — tylko nagie UI aplikacji w rozdzielczości symulatora.
• Mac wymagany dla iOS. Symulator potrzebuje Xcode.

Szczegółowe porównanie dotyczące konkretnie kwestii kompozycji znajdziesz w artykule Fastlane snapshot a narzędzia no-code dla zrzutów ekranu App Store oraz w porównaniu Mokbi vs Fastlane.

Opcja 2 — zrzuty ekranu Detox (stworzony dla React Native)

Detox to framework do testów end-to-end metodą szarej skrzynki, stworzony specjalnie dla React Native przez zespół z Wix. Jeśli już używasz Detox do testów e2e, zrzuty ekranu są niemal darmowe, a krzywa uczenia się jest tą, którą i tak chciałbyś pokonać — to JavaScript API, nie Swift ani Kotlin.

Wywołanie przechwytywania to jednolinijkowiec wewnątrz dowolnego testu:

// full screen
const path = await device.takeScreenshot('01_home');

// a single element
await element(by.id('paywallRoot')).takeScreenshot('paywall');

To, czy te obrazy są zachowywane jako artefakty, kontroluje flaga --take-screenshots (none, failing, manual lub all) skonfigurowana w .detoxrc.js. W trybie manual lub all przechodzące testy zapisują do <artifacts-location>/✓ [test name]/[name].png. Prowadzisz aplikację do każdego stanu tymi samymi matcherami Detox, których używasz do asercji, a następnie robisz zrzut.

Zalety:

• To JavaScript API. Piszesz testy w języku, w którym napisana jest twoja aplikacja — bez osobnego, obcojęzycznego zestawu testów natywnych.
• Szara skrzynka, więc rozumie RN. Detox synchronizuje się z mostem/JSI aplikacji i czeka na bezczynność, co sprawia, że zrzuty ekranu są znacznie mniej niestabilne niż ślepo zaplanowane oczekiwania XCUITest.
• Jeden framework, obie platformy. Ten sam plik testowy przechwytuje iOS i Android.
• Prawdopodobnie już go masz, jeśli robisz testy e2e — wtedy krańcowy koszt dodania zrzutów ekranu jest minimalny.

Wady:

• Postawienie Detox od zera nie jest trywialne — konfiguracja natywnego buildu, dedykowany build testowy oraz konfiguracja emulatora/symulatora. Jeśli jeszcze go nie używasz, to realna inwestycja.
• Obsługa locale należy do ciebie. Detox nie przejdzie automatycznie przez wszystkie locale App Store tak jak snapshot ze swoim Snapfile; musisz samodzielnie skryptować zmiany locale lub restartować z innymi ustawieniami.
• Wynik to nadal surowe klatki. Tak samo jak Fastlane — nagie UI aplikacji, bez warstwy marketingowej.
• Zrzuty ekranu mogą się różnić między maszynami hosta (znany problem Detox), co ma znaczenie przy porównywaniu w CI, ale jest nieszkodliwe dla materiałów sklepowych.

Opcja 3 — ręczne przechwytywanie (najprostsze i niedoceniane)

Otwórz iOS Simulator lub emulator Android, ręcznie przejdź do każdego ekranu swojej aplikacji i pobierz klatkę. Na iOS, Cmd-S w Simulatorze zapisuje poprawnie wymiarowany PNG na pulpicie; xcrun simctl io booted screenshot home.png robi to samo z terminala i łatwo to lekko oskryptować. Na Android przycisk aparatu emulatora lub adb exec-out screencap -p > home.png przechwytuje ekran. Urządzenie fizyczne też działa — przechwytuj, potem prześlij pliki przez AirDrop lub inną metodą.

Ta opcja jest zbyt pochopnie odrzucana. Ma zerową konfigurację, nigdy nie psuje się w CI, bo nie ma żadnego CI, i dla aplikacji publikowanej kilka razy w roku jest genuinely najszybszą ścieżką do zestawu źródłowych klatek. Wada jest oczywista i realna: to praca ręczna, więc nie regeneruje się sama, a jeśli zmienisz ekran, twoje przechwycenia starzeją się, dopóki ich nie ponowisz. Dla pięcioekranowej karuzeli to dziesięć minut pracy na wydanie — tańsze niż utrzymywanie automatyzacji testów, którą uruchamiasz dwa razy w roku.

Etap, o którym wszyscy zapominają: kompozycja i lokalizacja

Oto co łączy wszystkie trzy opcje: każda z nich produkuje surowe zrzuty ekranu aplikacji, a surowe zrzuty ekranu aplikacji to nie to, co konwertuje w sklepie. Karuzela App Store, która rzeczywiście zwiększa instalacje, ma ramkę urządzenia wokół ekranu, jednolinijkowy podpis u góry wyjaśniający korzyść, tło inne niż biel aplikacji i spójność we wszystkich pięciu panelach. Żadne z powyższych narzędzi do przechwytywania nie produkuje niczego z tego — zatrzymują się na nagiej klatce. To nie jest ich wada; to po prostu inna praca.

To jest etap, w którym mieści się Mokbi, i warto precyzyjnie opisać tę granicę: narzędzie nie przechwytuje twoich źródłowych zrzutów ekranu — to zadanie symulatora, urządzenia lub Fastlane/Detox powyżej. Mokbi zajmuje się warstwą kompozycji marketingowej i lokalizacji, która następuje potem. Wrzucasz surowe klatki do edytora w przeglądarce, owijasz je prawdziwymi ramkami urządzeń, dodajesz podpisy, układasz wielopanelowe karuzele, a następnie jednym kliknięciem tłumaczysz podpisy na 50 języków i eksportujesz wsadowo we wszystkich wymiarach sklepu. Projektowanie jest bezpłatne z podglądowym znakiem wodnym; nieograniczony eksport i publikowanie w sklepie są dostępne w ramach subskrypcji — Solo €29.99/mo (1 aplikacja) lub Studio €49.99/mo (do 5 aplikacji), bez jednorazowego zakupu. Pasuje tu tak dobrze dlatego, że rozwiązuje problem, którego twój pipeline przechwytywania nawet nie próbuje rozwiązać: przekształcenie folderu PNG-ów w zlokalizowaną, gotową do sklepu karuzelę bez otwierania Photoshop i ręcznego skalowania dla 50 języków.

Realistyczny połączony przepływ pracy

1. Przechwytuj źródłowe klatki. Wybierz jedno: Fastlane (snapshot + screengrab) na CI przy częstych wydaniach, Detox jeśli już używasz testów e2e, lub ręczne przechwytywanie z symulatora przy rzadkich wydaniach. Wynik: folder surowych PNG-ów na ekran, na urządzenie.
2. Komponuj, dodawaj podpisy i ramki. Wrzuć surowe klatki do edytora w przeglądarce. Dodaj ramki urządzeń, napisz podpisy opisujące korzyści, zbuduj pięciopanelową karuzelę, wybierz tło.
3. Tłumacz. Jednym kliknięciem tłumacz wsadowo podpisy na 50 języków, a następnie ręcznie sprawdź języki, które są dla ciebie najważniejsze.
4. Eksportuj wsadowo. Wyeksportuj każdą lokalizację we wszystkich wymaganych wymiarach zarówno dla App Store Connect, jak i Google Play w jednym przebiegu.
5. Podmień przy kolejnym wydaniu. Ponownie przechwyć zmienione klatki (uruchom ponownie Fastlane/Detox lub pobierz ręcznie), otwórz zapisany projekt, zamień zrzuty ekranu, wyeksportuj ponownie. Praca nad podpisami i tłumaczeniem jest już zrobiona.

Kiedy możesz pominąć automatyzację

Jeśli publikujesz jedno do trzech wydań rocznie — co opisuje większość indie aplikacji React Native — koszt konfiguracji Fastlane lub Detox prawie nigdy się nie zwraca. Spędziłbyś dzień na podłączaniu XCUITest i tańcu z Metro bundlerem, żeby zaoszczędzić dziesięć minut ręcznego przechwytywania dwa razy w roku. Ta matematyka się nie zgadza. Przechwytuj ręcznie z symulatora, komponuj i lokalizuj w przeglądarce, i skończysz w mniejszym łącznym czasie niż konfigurowanie automatyzacji raz.

Automatyzacja zarabia na siebie, gdy publikujesz co tydzień lub codziennie, gdy rozbieżność zrzutów ekranu staje się regularnym błędem lub gdy obsługujesz portfolio aplikacji i koszt przechwytywania na aplikację się mnoży. W tej skali Fastlane na CI (lub Detox, jeśli jest już w twoim stosie) to właściwy wybór dla etapu przechwytywania — i nadal łączysz go z narzędziem do kompozycji w przeglądarce dla warstwy marketingowej, bo żaden pipeline przechwytywania nie produkuje gotowej karuzeli.

Przed eksportowaniem czegokolwiek warto sprawdzić cele: rozmiary zrzutów ekranu App Store, które faktycznie musisz przesłać, oraz wymagania dotyczące zrzutów ekranu App Store, przez które zgłoszenia są odrzucane. Ustalenie tego raz pozwala uniknąć rundy z App Review.

Co przeczytać dalej

• Dla deweloperów React Native
• Porównanie: Mokbi vs Fastlane
• Fastlane snapshot a narzędzia no-code dla zrzutów ekranu App Store
• Rozmiary zrzutów ekranu App Store
• Wymagania dotyczące zrzutów ekranu App Store

Otwórz edytor →