· Publishing · 5 min leestijd

Gelokaliseerde screenshots in bulk uploaden naar beide app stores

Gelokaliseerde screenshots in bulk uploaden naar beide app stores
TL;DR. Geen enkele store heeft echte bulk-upload van screenshots over locales heen. In App Store Connect en Google Play Console upload je per taal, per device-formaat-familie, één bakje tegelijk in de web-UI. De enige manieren om het slepen te omzeilen zijn de App Store Connect API en de Google Play Developer API (of fastlane deliver/supply die daarbovenop draaien). Mokbi rendert elke locale × device en publiceert de set voor je naar beide stores — rechtstreeks naar Google Play via de Play Developer API, en klaargezet in App Store Connect voor je definitieve indiening.

Je zit midden in een release. De screenshots zijn af. Nu moeten ze beide stores in, in elke taal die je ondersteunt, op elk device-formaat dat elke store eist. Dit is het deel waar niemand je voor waarschuwt — en het deel waarbij mensen stilletjes gaan zoeken op iets als "bulk upload localized screenshots app store connect / google play all languages".

Eerst het eerlijke antwoord, zodat je kunt stoppen met zoeken: geen van beide stores heeft een native bulk-upload die over locales heen werkt. Je uploadt per locale, per device-formaat-familie, in de web-UI, één bakje tegelijk.

Wat "geen bulk-upload" echt betekent

In App Store Connect open je je app, kies je de versie, scroll je naar de screenshots-sectie, en sleep je PNG's naar een specifieke display-type-slot — 6,9", 6,5", 13" iPad, enzovoort. Daarna zet je de localisatie-dropdown op de volgende taal en doe je het opnieuw. Apple laat je maximaal 10 screenshots toevoegen per device-type, per localisatie. Er is geen "toepassen op alle talen"-knop voor afbeeldingen.

Google Play Console werkt hetzelfde. Onder Hoofdvermelding kies je een locale, en upload je vervolgens screenshots in elke device-sectie — telefoon, 7-inch tablet, 10-inch tablet, en eventueel Chromebook, Wear OS, Android TV en nieuwere types. Maximaal 8 per device-type. Taal wisselen, opnieuw beginnen.

De eenheid van werk is dus niet "een screenshot-set". Het is één bakje = één taal × één device-formaat-familie, en je vult elk bakje met de hand.

De omvang van het sleepwerk, in cijfers

Tel de bakjes eerlijk. Bij Apple vult een normale indiening minstens een iPhone-displayfamilie en een iPad-displayfamilie — reken 2, meer als je ook een aparte 6,5"-iPhone-set naast de 6,9" aanhoudt. Bij Play vult een normale indiening telefoon plus twee tabletformaten — reken 3, meer als je Chromebook of Wear OS toevoegt.

  • Eén taal, beide stores: ongeveer 2 Apple-bakjes + 3 Play-bakjes = 5 handmatige uploads.
  • Tien talen: ongeveer 20 + 30 = 50 bakjes om te vullen, elk met maximaal 8–10 afbeeldingen.
  • Vijftig talen: ongeveer 100 + 150 = 250 losse drag-and-drop uploads, nog voordat je hebt gecontroleerd of de juiste afbeelding in het juiste slot terechtkwam.

Dertig minuten slepen per locale is een cijfer dat mensen niet voor niets noemen. Bij elk serieus aantal talen wordt dit geen taak meer maar een middag — een middag die je bij de volgende release herhaalt.

De enige twee automatiseringsroutes

Als je de web-UI helemaal wilt overslaan, zijn er precies twee ondersteunde deuren, één per store:

  • App Store Connect API. De screenshots-resource laat je programmatisch een set aanmaken en afbeeldingen uploaden voor een gegeven localisatie en device-displaytype. Je authenticeert met een API-key en pusht afbeeldingen per locale, per displayfamilie.
  • Google Play Developer API. De methode edits.images.upload uploadt één afbeelding van een opgegeven taal en afbeeldingstype (phoneScreenshots, sevenInchScreenshots, tenInchScreenshots, enzovoort) in een lopende edit, die je vervolgens commit.

De meeste teams roepen dit niet rechtstreeks aan. Ze gebruiken fastlane erbovenop: deliver (ook bekend als upload_to_app_store) stuurt de App Store Connect API aan, en supply (upload_to_play_store) stuurt de Play Developer API aan. Supply zet zelfs meerdere upload-threads op om gelokaliseerde afbeeldingen gelijktijdig te pushen. Dat is de echte "bulk-upload" — het is een API-lus, geen knop in het dashboard.

Goed om de kosten helder te hebben: fastlane betekent een Ruby-toolchain, een fastfile, store-API-credentials, en (voor de Apple-kant) de gebruikelijke code-signing- en simulator-loodgieterij. Het betaalt zich terug als je vaak uitbrengt. Voor een app die een paar keer per jaar indient, kan het opzetten alleen voor het uploaden van afbeeldingen meer werk zijn dan het sleepwerk dat het vervangt. Als je het al draait voor builds, is de screenshot-stap toevoegen bijna gratis.

Waar de screenshots vandaan komen is het echte knelpunt

Merk op dat elke bovenstaande route ervan uitgaat dat de bestanden al bestaan — correct op formaat, één set per device-familie, per taal vertaald. Dat is het echte lastige deel. De App Store Connect API en de Play Developer API verplaatsen afgeronde afbeeldingen; ze ontwerpen ze niet, schalen ze niet en vertalen de bijschriften niet. Als je 50 taalvarianten op 5 device-formaten met de hand produceert in een ontwerptool, was de upload nooit je knelpunt.

Dit is het gat dat Mokbi dicht. Je bouwt één ontwerp, en het rendert elk device-formaat en elk van 50 talen vanuit die ene bron — bijschriften vertaald, layout herverdeeld, elk frame geëxporteerd op de exacte pixelafmetingen die het storeslot verwacht. De output is een batch: een nette set locale × device bestanden, benoemd en georganiseerd, klaar om in de juiste bakjes te droppen.

Met één klik publiceren naar beide stores

Mokbi lost precies dit op. Je bouwt één set, en het rendert elke locale × elk device-formaat en publiceert ze naar beide stores — rechtstreeks naar Google Play via de Play Developer API, en klaargezet in App Store Connect zodat jij kunt indienen. Apple vereist de definitieve Submit en review, dus die laatste tap blijft bij jou; alles daarvoor is geregeld. Geen handmatige upload per locale, per device meer.

Draai je fastlane of de store-API's al in je eigen CI, dan voeden dezelfde geëxporteerde bestanden rechtstreeks deliver en supply. Hoe dan ook: het ontwerp, het schalen en de vertaling naar 50 talen zijn voor je gedaan — en nu de publicatie ook.

De workflow die de middag echt uitspaart

  1. Eén keer ontwerpen. Bouw de carrousel één keer in de editor.
  2. Exporteer de matrix in bulk. Elk device-formaat × elke taal, op exacte store-afmetingen, in één export.
  3. Publiceer naar beide stores. Mokbi pusht de sets naar Google Play en zet ze klaar in App Store Connect voor je definitieve indiening — of geef de bestanden aan fastlane deliver/supply als je je eigen CI draait.
  4. Volgende release: opnieuw exporteren en herhalen. Verander het ontwerp één keer, genereer de hele matrix opnieuw, upload weer.

De rekensom die ertoe doet: het aantal bakjes verandert niet, maar de tijd per bakje stort in zodra je een afgerond, correct geformatteerd bestand droppt in plaats van het eerst te ontwerpen en te formatteren. Dat is het verschil tussen een middag en een koffiepauze.

Wat je hierna kunt lezen

Open de editor →