Expo App Store screenshots: waarom EAS Submit ze overslaat en hoe je ze snel klaar hebt (2026)

Als je een Expo-app uitbrengt, eindigt je releaseproces waarschijnlijk met één commando: eas submit. Het neemt de build die EAS heeft geproduceerd en levert die af bij Apple of Google. Schoon, saai, betrouwbaar. Dan open je App Store Connect om de build live te zetten en — de screenshot-sloten zijn leeg. Elke keer.

Dit overvalt veel mensen, omdat EAS aanvoelt alsof het alles doet. Het bouwt, signeert en submittet. Surely doet het ook screenshots? Dat doet het niet, en de documentatie zegt dat ook gewoon. Dit is geen bug of een ontbrekende feature waar je op kunt klagen — het valt simpelweg buiten waar EAS Submit voor bedoeld is.

Wat EAS Submit daadwerkelijk doet (en niet doet)

EAS Submit is een service voor het afleveren van binaire bestanden. Het uploadt precies één ding: je gecompileerde app-archief — een .ipa voor iOS, een .aab voor Android — in de verwerkingspipeline van de store. De Expo-documentatie is expliciet over die grens:

"EAS Submit uploadt je binaire bestand maar beheert geen store-listing-metadata, screenshots of releaseopmerkingen."

Er is een bijbehorende tool, EAS Metadata, die wel delen van je App Store-listing kan automatiseren — appnaam, ondertitel, gelokaliseerde beschrijvingen, trefwoorden, support-URL's — vanuit een configuratiebestand. Het is echt nuttig en het opzetten ervan loont. Maar lees de scope goed: screenshots zitten er niet in. EAS Metadata pusht tekst, geen afbeeldingen. Je screenshots, op beide stores, blijven jouw verantwoordelijkheid om te produceren en te uploaden.

Het Expo-screenshot-probleem valt dus uiteen in twee duidelijk afgebakende taken, en het helpt om die in je hoofd gescheiden te houden:

1. Vastleggen — ruwe frames van de echte schermen van je app uit een build halen.
2. Componeren & lokaliseren — die ruwe frames omzetten in de omlijste, van bijschriften voorziene, meertalige marketingpanelen die de stores daadwerkelijk tonen.

EAS doet geen van beide. Expo's eigen store-assets-richtlijnen verwijzen je naar het zelf vastleggen van frames en het ontwerpen van de panelen in een tool als Figma. Laten we beide taken doorlopen met concrete commando's.

Taak 1: frames vastleggen vanuit een dev- of preview-build

Je wilt screenshots van de echte app, dus je hebt de app ergens actief nodig om te kunnen vastleggen. Voor Expo betekent dat een dev-client of een preview-build — niet Expo Go, want Expo Go toont de Expo-wrapper-UI en je native config kan afwijken. Bouw en start lokaal met de standaard Expo-commando's:

• npx expo run:ios — prebuildt native iOS, compileert, en start je app in de iOS Simulator.
• npx expo run:android — hetzelfde voor een Android-emulator (of een aangesloten apparaat).

Met de app op het scherm in de iOS Simulator leg je vast met één commando vanuit je Mac-terminal:

xcrun simctl io booted screenshot home.png

booted richt zich op de actief draaiende simulator en schrijft een pixel-exacte PNG naar je werkmap. Twee vlaggen zijn van belang voor store-werk: --type=png (de standaard, en wat de stores willen) en --mask=ignored versus --mask=black — het masker bepaalt of de notch en afgeronde hoeken in de afbeelding worden weergegeven. Voor App Store-uploads wil je doorgaans de vlakke rechthoekige pixels, en voeg je het device frame later toe tijdens de compositie, dus de ongemaskeerde vastlegging is meestal het beste startpunt.

Op Android leg je rechtstreeks vast vanuit de emulator (of het apparaat) met adb:

adb exec-out screencap -p > home.png

Gebruik exec-out, niet shell screencap. Het gewone shell-pad pipt de PNG via een pseudo-terminal die het binaire bestand op sommige setups beschadigt (je krijgt een corrupt bestand met ongeldige regeleinden); exec-out streamt de bytes rechtstreeks door en is de betrouwbare vorm. Als je meerdere emulators draait, richt je je op één met adb -s <serial> via adb devices.

Dat is de complete handmatige opname-toolkit: twee commando's, één per platform, geen afhankelijkheden buiten Xcode en de Android SDK die je al hebt voor een Expo-native-build.

Taak 1, geautomatiseerd: Maestro of Detox

Handmatig naar het juiste scherm navigeren en die commando's uitvoeren is prima voor een handvol screenshots. Zodra je acht schermen hebt voor twee apparaatklassen, of je wilt screenshots bij elke release opnieuw laten genereren zodat ze nooit afwijken van de echte UI, automatiseer je de vastlegging met een end-to-end-testtool die de app kan aansturen én frames kan vastleggen.

Maestro is de tool waarnaar Expo zelf grijpt in zijn gedocumenteerde EAS Workflows-voorbeelden. Flows zijn gewone YAML, wat de drempel laag houdt. Een flow die naar een scherm navigeert en het vastlegt, ziet er zo uit:

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

Voer het uit met maestro test flows/home.yaml. Het takeScreenshot-commando schrijft een PNG naar de testoutputmap (stel MAESTRO_TESTS_DIR in op waar je de assets wilt bewaren). Dezelfde flows draaien in CI via EAS Workflows — het gedocumenteerde Expo-voorbeeld bouwt een .apk met een e2e-test-buildprofiel en draait vervolgens een .maestro/-flow ertegen — zodat je screenshot-vastlegging kunt koppelen aan dezelfde job die je e2e-suite uitvoert.

Detox is de andere gevestigde optie, met een striktere, meer programmatische JavaScript-API:

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

Wees eerlijk met jezelf over de Detox-met-Expo-setup. Detox ondersteunt Expo niet officieel. In de praktijk werkt het als je npx expo prebuild uitvoert om de native projecten te genereren en een release-achtige client bouwt (geen dev-client) zodat de JS-bundle ingebakken zit — en Detox vervolgens op dat binaire bestand richt. Het heeft meer onderdelen dan de YAML van Maestro, en de toegevoegde waarde is Detox's striktere synchronisatie- en assertion-API. Als je Detox al gebruikt, hergebruik het dan voor vastlegging; als je nu kiest en je doel store-screenshots zijn, is Maestro de lichtere route.

Taak 1, handmatig: de juiste keuze voor sporadische releases

Automatisering loont als je vaak uitbrengt. Als je één tot drie releases per jaar uitbrengt — wat de meeste indie Expo-apps beschrijft — is het opzetten van Maestro-flows of een Detox-config voor screenshot-vastlegging werk dat je eenmalig doet en nauwelijks terugverdient. Voor dat ritme geldt: doe gewoon het volgende:

1. Start de build met npx expo run:ios / run:android, gevuld met realistische demo-data.
2. Navigeer handmatig naar elk hoofdscherm.
3. Leg elk scherm vast met het simctl- / adb-commando hierboven.

Twintig minuten klikken is beter dan een halve dag aan een testharnas dat je bij de volgende release vergeten bent hoe je het moet onderhouden. Handmatige opname is nergens genant voor — de stores zien niet hoe de PNG is gemaakt.

Taak 2: compositie en lokalisatie naar 50 talen

Dit is het deel dat capture-tools bewust niet aanraken, en het is het deel waar de stores je daadwerkelijk op beoordelen. Een ruwe simctl-PNG is de UI van je app op een witte achtergrond. Wat scoort in zoekresultaten en converteert op de productpagina is het marketingpaneel: de screenshot in een device frame, op een merkgebonden achtergrond, met een bijschrift op één regel dat uitlegt waarom het scherm relevant is — doorgaans als een meerpaneel-carrousel die van links naar rechts leest. En in de App Store zijn screenshots gelokaliseerd per apparaatformaat en per taal, dus een serieuze launch bestaat uit tientallen varianten, niet vijf.

Dit is precies de plek waar Mokbi past, en het is de moeite waard om die grens scherp te stellen. Mokbi legt je app niet vast — de bronframes maak je nog steeds met de Expo-commando's hierboven. Wat het doet is die frames nemen en je in de browser laten: ze in echte device frames zetten, bijschriften en kleurverlopen toevoegen, meerpaneel-carrousels opbouwen, de bijschrifttekst met één klik naar 50 talen vertalen, en alle App Store- en Play Store-afmetingen tegelijk in bulk exporteren. Ontwerpen is gratis met een voorbeeld met watermerk; onbeperkt exporteren zit bij een abonnement — Solo €29.99/mo (1 app) of Studio €49.99/mo (tot 5 apps), geen eenmalige aankoop. Het vervangt de Figma-sjabloonstap die Expo's gids even noemt — niet meer, niet minder.

De realistische gecombineerde workflow

1. Bouw een dev/preview-client. npx expo run:ios en npx expo run:android, gevuld met goede demo-data.
2. Leg bronframes vast. Handmatig via xcrun simctl io booted screenshot en adb exec-out screencap -p, of geautomatiseerd via Maestro takeScreenshot / Detox device.takeScreenshot — bij voorkeur via EAS Workflows zodat ze bij elke release opnieuw worden gegenereerd.
3. Componeer de marketingpanelen. Omlijst, voorzie van bijschriften en orden de carrousel op basis van die ruwe frames.
4. Lokaliseer en exporteer in bulk. Vertaal bijschriften naar je doeltalen en exporteer alle vereiste afmetingen voor beide stores.
5. Upload de listing-assets. Screenshots naar App Store Connect en Play Console; combineer met EAS Metadata voor de tekstvelden als je dat gebruikt.
6. Submit het binaire bestand. eas submit — de ene stap die EAS wel voor zijn rekening neemt.
7. Volgende release: leg gewijzigde schermen opnieuw vast, open het opgeslagen compositieproject opnieuw, vervang de frames en exporteer opnieuw. De bijschriften en vertalingen blijven staan.

Wanneer je de automatisering kunt overslaan

Grijp naar Maestro of Detox wanneer screenshot-drift een echte kostenpost is: je brengt wekelijks uit, je UI verandert voortdurend, of je beheert veel apps en kunt je geen verouderde store-afbeeldingen veroorloven. In die gevallen verdienen door CI opnieuw gegenereerde frames zich terug, en is het verhaal over React Native screenshot-tooling (dat Expo erft) de investering waard.

Voor iedereen die één keer per kwartaal uitbrengt: sla het over. Handmatige vastlegging met twee terminalcommando's, gevolgd door browsergebaseerde compositie en lokalisatie, levert in één middag een gepolijste, meertalige listing op zonder iets te hoeven onderhouden tussen releases. Kies de tooling die bij jouw ritme past, niet wat indrukwekkend staat op een CI-dashboard.

Hoe dan ook is de binaire helft opgelost: eas submit regelt dat. Controleer je screenshots wel aan de hand van de actuele store-vereisten voordat je uploadt — Apple keurt een listing af om één pixel verschil — en de rest van de launch is puur ontwerp.

Verder lezen

• Voor Expo-developers
• React Native App Store screenshots
• Naast elkaar: Mokbi vs Fastlane
• App Store-screenshot-formaten
• App Store-screenshot-vereisten

Editor openen →