Lokalisierte Screenshots im Bulk in beide App Stores hochladen
deliver/supply, die darauf aufsetzen). Mokbi rendert jede Sprache × jedes Gerät und veröffentlicht den ganzen Satz für dich in beiden Stores — es pusht direkt zu Google Play über die Play Developer API und stellt es in App Store Connect für deine finale Einreichung bereit.Du steckst mitten in einem Release. Die Screenshots sind fertig. Jetzt müssen sie in beide Stores, in jeder Sprache, die du unterstützt, in jeder von jedem Store geforderten Geräte-Größe. Das ist der Teil, vor dem dich niemand warnt — und der Punkt, an dem Leute leise nach etwas wie "bulk upload localized screenshots app store connect / google play all languages" suchen.
Hier zuerst die ehrliche Antwort, damit du aufhören kannst zu suchen: Kein Store hat einen nativen Bulk-Upload, der über Sprachen hinweg funktioniert. Du lädst pro Sprache, pro Geräte-Größenfamilie in der Web-Oberfläche hoch, einen Bucket nach dem anderen.
Was „kein Bulk-Upload" wirklich bedeutet
In App Store Connect öffnest du deine App, wählst die Version aus, scrollst zum Screenshot-Bereich und ziehst PNGs in einen bestimmten Display-Typ-Slot — 6.9", 6.5", 13" iPad und so weiter. Dann wechselst du im Lokalisierungs-Dropdown zur nächsten Sprache und machst es noch einmal. Apple erlaubt bis zu 10 Screenshots pro Gerätetyp, pro Lokalisierung. Es gibt keinen „Auf alle Sprachen anwenden"-Button für Bilder.
Die Google Play Console funktioniert genauso. Unter Haupt-Store-Eintrag wählst du eine Sprache aus und lädst dann Screenshots in jeden Gerätebereich hoch — Smartphone, 7-Zoll-Tablet, 10-Zoll-Tablet und optional Chromebook, Wear OS, Android TV und neuere Typen. Bis zu 8 pro Gerätetyp. Sprache wechseln, wiederholen.
Die Arbeitseinheit ist also nicht "ein Screenshot-Satz". Es ist ein Bucket = eine Sprache × eine Geräte-Größenfamilie, und du füllst jeden Bucket von Hand.
Der Umfang des Drag-and-Drops, in Zahlen
Zähl die Buckets ehrlich. Bei Apple füllt eine normale Einreichung mindestens eine iPhone-Displayfamilie und eine iPad-Displayfamilie — sag 2, mehr, wenn du zusätzlich noch einen separaten 6.5"-iPhone-Satz neben dem 6.9"-Satz pflegst. Bei Play füllt eine normale Einreichung Smartphone plus zwei Tablet-Größen — sag 3, mehr, wenn du Chromebook oder Wear OS ergänzt.
- Eine Sprache, beide Stores: etwa 2 Apple-Buckets + 3 Play-Buckets = 5 manuelle Uploads.
- Zehn Sprachen: etwa 20 + 30 = 50 Buckets zum Füllen, jeder mit bis zu 8–10 Bildern.
- Fünfzig Sprachen: etwa 100 + 150 = 250 einzelne Drag-and-Drop-Uploads — bevor du überhaupt geprüft hast, ob das richtige Bild im richtigen Slot gelandet ist.
Dreißig Minuten Drag-and-Drop pro Sprache ist eine Zahl, die nicht ohne Grund kursiert. Bei jeder echten Sprachanzahl wird daraus keine Aufgabe mehr, sondern ein ganzer Nachmittag — ein Nachmittag, den du beim nächsten Release wiederholst.
Die beiden einzigen Automatisierungswege
Willst du die Web-Oberfläche komplett umgehen, gibt es genau zwei unterstützte Türen, eine pro Store:
- App Store Connect API. Die Screenshots-Ressource lässt dich programmatisch einen Satz anlegen und Bilder für eine bestimmte Lokalisierung und einen Gerätedisplay-Typ hochladen. Du authentifizierst dich mit einem API-Schlüssel und lädst Bilder pro Sprache, pro Displayfamilie hoch.
- Google Play Developer API. Die Methode
edits.images.uploadlädt ein Bild einer bestimmten Sprache und eines bestimmten Bildtyps (phoneScreenshots,sevenInchScreenshots,tenInchScreenshotsund so weiter) in eine ausstehende Bearbeitung hoch, die du anschließend übernimmst.
Die meisten Teams rufen diese APIs nicht direkt auf. Sie nutzen fastlane obendrauf: deliver (auch als upload_to_app_store bekannt) steuert die App Store Connect API, und supply (upload_to_play_store) steuert die Play Developer API. Supply startet sogar mehrere Upload-Threads, um lokalisierte Bilder parallel hochzuladen. Das ist der echte „Bulk-Upload" — eine API-Schleife, kein Button im Dashboard.
Wichtig ist, den Preis zu kennen: fastlane bedeutet eine Ruby-Toolchain, eine Fastfile, Store-API-Zugangsdaten und (auf Apple-Seite) die übliche Code-Signing- und Simulator-Verkabelung. Das zahlt sich aus, wenn du häufig releast. Für eine App, die nur ein paar Mal im Jahr eingereicht wird, kann das Aufsetzen nur für den Bild-Upload mehr Arbeit sein als das Ziehen, das es ersetzt. Läuft es bereits für Builds, ist der zusätzliche Screenshot-Schritt fast kostenlos.
Der eigentliche Engpass: Woher kommen die Screenshots
Beachte: Jeder Weg oben setzt voraus, dass die Dateien bereits existieren — korrekt bemessen, ein Satz pro Gerätefamilie, pro Sprache übersetzt. Das ist der eigentlich harte Teil. Die App Store Connect API und die Play Developer API bewegen fertige Bilder; sie entwerfen sie nicht, skalieren sie nicht und übersetzen die Untertitel nicht. Wenn du 50 Sprachvarianten in 5 Gerätegrößen von Hand in einem Design-Tool produzierst, war der Upload nie dein Engpass.
Genau diese Lücke schließt Mokbi. Du baust ein Design, und es rendert daraus jede Gerätegröße und jede der 50 Sprachen — Untertitel übersetzt, Layout neu umbrochen, jedes Frame in exakt den Pixelmaßen exportiert, die der Store-Slot erwartet. Das Ergebnis ist ein Batch: ein sauberer Satz aus Sprache-×-Gerät-Dateien, benannt und organisiert, bereit zum Ablegen im richtigen Bucket.
Veröffentlichung in beiden Stores mit einem Klick
Genau das löst Mokbi. Du baust einen Satz, und es rendert jede Sprache × jede Gerätegröße und veröffentlicht sie in beiden Stores — es pusht direkt zu Google Play über die Play Developer API und stellt sie in App Store Connect bereit, fertig für deine Einreichung. Apple verlangt das finale Submit und die Review, dieser letzte Klick bleibt also bei dir; alles davor ist erledigt. Kein manuelles Hochladen mehr pro Sprache, pro Gerät.
Nutzt du bereits fastlane oder die Store-APIs in deiner eigenen CI, fließen dieselben exportierten Dateien direkt in deliver und supply. So oder so sind Design, Skalierung und die Übersetzung in 50 Sprachen für dich erledigt — und jetzt auch die Veröffentlichung.
Der Workflow, der dir wirklich den Nachmittag rettet
- Einmal designen. Bau das Karussell einmal im Editor.
- Die Matrix im Batch exportieren. Jede Gerätegröße × jede Sprache, in exakten Store-Maßen, in einem Export.
- In beiden Stores veröffentlichen. Mokbi lädt die Sätze zu Google Play hoch und stellt sie in App Store Connect für deine finale Einreichung bereit — oder übergib die Dateien an fastlane
deliver/supply, wenn du deine eigene CI nutzt. - Beim nächsten Release erneut exportieren und wiederholen. Design einmal ändern, die ganze Matrix neu erzeugen, erneut hochladen.
Die Rechnung, die zählt: Die Anzahl der Buckets ändert sich nicht, aber die Zeit pro Bucket schrumpft drastisch, wenn du eine fertige, korrekt bemessene Datei ablegst, statt sie erst zu designen und zu skalieren. Das ist der Unterschied zwischen einem Nachmittag und einer Kaffeepause.