2026-07-04 · Workflow · 9 min lezen

App Store screenshots maken voor een React Native-app (2026)

TL;DR. React Native heeft geen eigen screenshot-pipeline. Je realistische opties voor het vastleggen van de ruwe frames zijn Fastlane (XCUITest op iOS, screengrab/Espresso op Android), Detox (speciaal gebouwd voor RN en het eenvoudigst van de drie), of gewoon handmatig vastleggen vanuit de simulator. Welke je ook kiest, je krijgt alleen kale app-screenshots — die omzetten naar een kant-en-klare carrousel met bijschriften, device frames en gelokaliseerde varianten is een aparte marketingstap. Voor de meeste teams die een paar keer per jaar uitbrengen, is handmatige opname plus browsercompositie sneller dan een dag Fastlane-configuratie.

Dit vertelt niemand je als je je eerste React Native-app naar de App Store stuurt: er is geen ingebouwde manier om de screenshots te genereren die de store wil. Native iOS-developers grijpen naar Xcode's UI-testrecorder; native Android-developers hebben Espresso ingebakken in de build. React Native zit bovenop beide, met je daadwerkelijke app-logica in JavaScript — en geen van die tooling weet dat je JS bestaat. Je moet het gat zelf overbruggen.

Dit artikel beschrijft de aanpakken die daadwerkelijk werken in de New Architecture-era (RN 0.7x en hoger, 2026), met concrete commando's. Het is eerlijk over de kosten, want elk van deze opties heeft er echte. Daarna behandelt het het deel dat na het vastleggen komt — de marketingcompositie en lokalisatie — wat een volkomen apart probleem is, ongeacht hoe je de bronframes bemachtigt.

Het echte probleem: geen eigen pipeline

App Store Connect wil screenshots op exacte pixelafmetingen, bij voorkeur één set per apparaatklasse en één set per locale die je ondersteunt. Google Play wil zijn eigen formaten. Een native iOS-project kan de simulator aansturen via XCUITest en frames dumpen; React Native kan dat technisch ook, maar de test die je schrijft draait tegen de native shell — het gecompileerde binaire bestand — niet direct tegen je JavaScript-componenten. Je automatiseert een black box die toevallig je JS weergeeft.

Dat onderscheid is belangrijker dan het klinkt. Het betekent dat je screenshot-automatisering kapot gaat om redenen die niets met je React-code te maken hebben (een Metro bundler die niet draaide, een simulator vastgelopen op een toestemmingsdialoog, een native build die afweek van je JS) en het betekent dat de leercurve die is van twee native test-frameworks, niet je vertrouwde RN-stack. Er zijn drie serieuze manieren om dit aan te pakken. Kies op basis van hoe vaak je uitbrengt.

Optie 1 — Fastlane snapshot (iOS) en screengrab (Android)

Fastlane is hét open-source mobiele automatiseringsframework, en de screenshot-modules zijn de meest beproefde optie. Ze kosten ook het meeste werk om op te zetten voor React Native, omdat ze zijn gebouwd voor native projecten en RN slechts tolereren.

iOS, via snapshot. Je voegt een UI-testtarget toe in Xcode en schrijft XCUITest-cases in Swift die de app naar elk scherm sturen dat je wilt vastleggen. fastlane snapshot init zet een Snapfile en een SnapshotHelper.swift neer in je fastlane/-map. In je test roep je setupSnapshot(app) aan, start je de app, en dan snapshot("01_home") bij elke toestand. Je voert het uit vanuit de terminal met fastlane snapshot — niet vanuit Xcode, dat geeft geen correcte output. Het doorloopt elke simulator en locale in je Snapfile en schrijft PNG's naar fastlane/screenshots/.

Het React Native-complicatie: snapshot start de gecompileerde app, die in debug-modus de Metro bundler al actief nodig heeft. Je Fastfile (of een wrapper-script) moet Metro dus eerst starten — de gebruikelijke truc is npx react-native start starten in een tmux-sessie op de achtergrond voordat je snapshot aanroept, en die daarna afbreken. Release-builds met de JS-bundle ingebakken vermijden dit, maar kosten je een volledige release-build per run.

Android, via screengrab. Heel ander framework: screengrab gebruikt Espresso. Je voegt Screengrab.screenshot("name")-aanroepen toe in JUnit-instrumentatietests, declareert permissies (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION, en opslagpermissies), bouwt een debug-APK en een test-APK met ./gradlew assembleDebug assembleAndroidTest, en voert fastlane screengrab uit. Output belandt in fastlane/metadata/android/. Net als bij iOS moeten Metro en de emulator al actief zijn — screengrab start ze niet voor je.

Sterke punten:

CI-geïntegreerd en driftbestendig. Koppel het aan je pipeline en screenshots worden bij elke release-build opnieuw gegenereerd, altijd overeenkomend met de uitgebrachte app.
Echte locale-weergave. Elke locale draait in de simulator/emulator met de echte locale-instellingen, zodat datums, getallen en valuta native worden weergegeven — niet nagebootst in een ontwerptool.
Gratis, open source, volwassen. Geen abonnement, grote community, bekende foutpatronen.

Zwakke punten (wees eerlijk met jezelf):

Je onderhoudt twee native test-suites. XCUITest in Swift voor iOS, Espresso/JUnit in Kotlin/Java voor Android — als RN-developer zijn dat mogelijk twee onbekende stacks.
Het test de native shell, niet je JS-logica. De tests controleren weergegeven native views; ze kennen je componentenstructuur niet.
Opzetten kost een à twee dagen de eerste keer, en de Metro-bundler-dans is een terugkerende bron van onstabiele CI-runs.
Output zijn ruwe frames. Geen bijschriften, geen device frames, geen kleurverlopen, geen carrousel — alleen de kale app-UI op simulatorresolutie.
Mac vereist voor iOS. De simulator heeft Xcode nodig.

Voor een uitgebreide vergelijking specifiek over de compositievraag, zie Fastlane snapshot vs no-code App Store screenshots en de Mokbi vs Fastlane-vergelijking.

Optie 2 — Detox screenshots (gebouwd voor React Native)

Detox is een gray-box end-to-end-testframework speciaal gemaakt voor React Native, door het team van Wix. Als je Detox al gebruikt voor e2e-tests, zijn screenshots bijna gratis, en de leercurve is precies de curve die je toch wilt klimmen — het is een JavaScript-API, geen Swift of Kotlin.

De vastlegroep is één regel in elke test:

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

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

Of die afbeeldingen worden bewaard als artefacten, wordt bepaald door de --take-screenshots-vlag (none, failing, manual, of all) en geconfigureerd in .detoxrc.js. In manual- of all-modus schrijven geslaagde tests naar <artifacts-location>/✓ [test name]/[name].png. Je stuurt de app naar elke toestand met dezelfde Detox-matchers die je voor assertions zou gebruiken, en maakt dan een snapshot.

Sterke punten:

Het is een JavaScript-API. Je schrijft tests in de taal waarin je app is geschreven — geen tweede native test-suite in een andere taal.
Gray-box, dus begrijpt het RN. Detox synchroniseert met de bridge/JSI van de app en wacht tot die inactief is, waardoor screenshots veel minder foutgevoelig zijn dan blindelings getimede XCUITest-waits.
Één framework, beide platforms. Hetzelfde testbestand legt iOS en Android vast.
Je hebt het waarschijnlijk al als je e2e-tests doet, waardoor de extra kosten voor screenshots verwaarloosbaar zijn.

Zwakke punten:

Detox van nul opzetten is geen sinecure — native build-configuratie, een aparte testbuild en emulator/simulator-setup. Als je het nog niet gebruikt, is dit een serieuze investering.
Locale-afhandeling is je eigen verantwoordelijkheid. Detox doorloopt niet automatisch alle App Store-locales zoals de Snapfile van snapshot doet; je scriptt de locale-wijzigingen zelf of herstart met andere instellingen.
Output zijn nog steeds ruwe frames. Net als Fastlane — kale app-UI, geen marketinglaag.
Screenshots kunnen verschillen per hostmachine (een bekend Detox-probleem), wat ertoe doet als je ze vergelijkt in CI, maar onschadelijk is voor store-assets.

Optie 3 — Handmatige opname (eenvoudigst, en onderschat)

Open de iOS Simulator of een Android-emulator, stuur je eigen app handmatig naar elk scherm en leg het frame vast. Op iOS slaat Cmd-S in de Simulator een correct formaat PNG op naar het bureaublad; xcrun simctl io booted screenshot home.png doet hetzelfde vanuit de terminal en is eenvoudig los te scripten. Op Android legt de cameraknop van de emulator of adb exec-out screencap -p > home.png het scherm vast. Een fysiek apparaat werkt ook — vastleggen en daarna via AirDrop of bestandsoverdracht overzetten.

Dit wordt te snel afgedaan. Het heeft nul installatie nodig, breekt nooit in CI omdat er geen CI is, en voor een app die een paar keer per jaar uitbrengt is het echt de snelste weg naar een set bronframes. Het nadeel is duidelijk en reëel: het is handmatig, dus het genereert niet opnieuw uit zichzelf, en als je een scherm aanpast zijn je opnames verouderd totdat je ze opnieuw maakt. Voor een carrousel van vijf schermen is dat tien minuten werk per release — goedkoper dan test-automatisering onderhouden die je twee keer per jaar uitvoert.

Het deel dat iedereen vergeet: compositie en lokalisatie

Dit is wat alle drie de opties gemeen hebben: elk van hen produceert ruwe app-screenshots, en ruwe app-screenshots zijn niet wat converteert in de store. De App Store-carrousel die daadwerkelijk installaties oplevert heeft een device frame om het scherm, een éénregelig bijschrift erboven dat het voordeel uitlegt, een achtergrond die niet de witte achtergrond van je app is, en consistentie over de vijf panelen. Geen van de bovenstaande opname-tools produceert dat — ze stoppen bij het kale frame. Dat is geen fout van die tools; het is een andere taak.

Dit is de stap waar Mokbi past, en het is de moeite waard om de grens precies aan te geven: het legt je bronscreenshots niet vast — dat is de simulator, het apparaat, of Fastlane/Detox hierboven. Wat het doet is de marketingcompositie- en lokalisatielaag die daarna komt. Je zet je ruwe frames in een browser-editor, omhult ze met echte device frames, voegt bijschriften toe, bouwt multi-paneel carrousels, en vertaalt de bijschriften daarna met één klik naar 50 talen en exporteert in bulk op elk store-formaat. Ontwerpen met een preview met watermerk is gratis; onbeperkt exporteren en publiceren zit bij een abonnement — Solo €29.99/mo (1 app) of Studio €49.99/mo (tot 5 apps), geen eenmalige aankoop. De reden dat het er naadloos in past is dat het het probleem oplost dat je opname-pipeline niet eens probeert: een map met PNG's omzetten in een gelokaliseerde, kant-en-klare carrousel zonder Photoshop te openen of handmatig te schalen voor 50 talen.

De realistische gecombineerde workflow

Leg bronframes vast. Kies er één: Fastlane (snapshot + screengrab) op CI voor frequente releases, Detox als je al e2e-tests draait, of handmatige simulatoropname voor sporadische releases. Output: een map met ruwe PNG's per scherm, per apparaat.
Componeer, voeg bijschriften toe en omlijst. Zet de ruwe frames in een browser-editor. Voeg device frames toe, schrijf de voordeel-bijschriften, bouw de vijf-paneel carrousel, kies een achtergrond.
Vertalen. Vertaal de bijschriften met één klik naar 50 talen en controleer handmatig de talen die voor jou het belangrijkst zijn.
In bulk exporteren. Exporteer elke locale op elk vereist formaat voor zowel App Store Connect als Google Play in één keer.
Vervangen bij de volgende release. Leg de gewijzigde frames opnieuw vast (Fastlane/Detox opnieuw draaien, of handmatig ophalen), open het opgeslagen project opnieuw, vervang de screenshots en exporteer opnieuw. Het bijschrift- en vertaalwerk is al gedaan.

Wanneer je de automatisering kunt overslaan

Als je één tot drie releases per jaar uitbrengt — wat de meeste indie React Native-apps beschrijft — betalen de Fastlane- of Detox-setupkosten zich bijna nooit terug. Je zou een dag besteden aan het configureren van XCUITest en de Metro-bundler-dans om twee keer per jaar tien minuten handmatige opname te besparen. Dat rekent niet uit. Leg handmatig vast vanuit de simulator, componeer en lokaliseer in de browser, en je bent in minder totale tijd klaar dan de automatisering zou kosten om eenmalig te configureren.

De automatisering verdient zijn plek als je wekelijks of dagelijks uitbrengt, als screenshot-drift een terugkerende bug wordt, of als je een portfolio van apps beheert en de opname-kosten per app zich vermenigvuldigen. Op die schaal is Fastlane op CI (of Detox als het al in je stack zit) de juiste keuze voor de opname-stap — en je combineert het alsnog met een browser-compositietool voor de marketinglaag, want geen enkele opname-pipeline produceert een afgewerkte carrousel.

Voordat je iets exporteert, loont het de moeite om de doelen te bevestigen: de App Store-screenshot-formaten die je daadwerkelijk moet uploaden, en de App Store-screenshot-vereisten waar indieningen op worden afgekeurd. Die één keer goed krijgen bespaart een heen-en-weer met App Review.

Verder lezen

Editor openen →