Bulk-uploading localized screenshots to both app stores
deliver/supply
sitting on top of them). Mokbi renders every locale × device and publishes the set to both
stores for you — pushing straight to Google Play over the Play Developer API and staging it in App
Store Connect ready for your final submit.
You are in the middle of a release. The screenshots are finished. Now you have to get them into both stores, in every language you support, at every device size each store demands. This is the part nobody warns you about — and the part where people quietly reach for a search like "bulk upload localized screenshots app store connect / google play all languages".
Here is the honest answer first, so you can stop looking: neither store has a native bulk upload that spans locales. You upload per locale, per device-size family, in the web UI, one bucket at a time.
What "no bulk upload" actually means
In App Store Connect you open your app, pick the version, scroll to the screenshots section, and drag PNGs into a specific display-type slot — 6.9", 6.5", 13" iPad, and so on. Then you switch the localization dropdown to the next language and do it again. Apple lets you add up to 10 screenshots per device type, per localization. There is no "apply to all languages" button for images.
Google Play Console works the same way. Under Main store listing you choose a locale, then upload screenshots into each device section — phone, 7-inch tablet, 10-inch tablet, and optionally Chromebook, Wear OS, Android TV, and newer types. Up to 8 per device type. Switch the language, repeat.
So the unit of work is not "a screenshot set". It is one bucket = one language × one device-size family, and you fill every bucket by hand.
The size of the drag, quantified
Count the buckets honestly. On Apple, a normal submission fills at least an iPhone display family and an iPad display family — call it 2, more if you keep a separate 6.5" iPhone set alongside the 6.9". On Play, a normal submission fills phone plus two tablet sizes — call it 3, more if you add Chromebook or Wear OS.
- One language, both stores: roughly 2 Apple buckets + 3 Play buckets = 5 manual uploads.
- Ten languages: about 20 + 30 = 50 buckets to fill, each holding up to 8–10 images.
- Fifty languages: about 100 + 150 = 250 separate drag-and-drop uploads, before you have even checked that the right image landed in the right slot.
Thirty minutes of dragging per locale is a figure people quote for a reason. At any real language count this stops being a task and becomes an afternoon — an afternoon you repeat on the next release.
The only two automation paths
If you want to skip the web UI entirely, there are exactly two supported doors, one per store:
- App Store Connect API. The screenshots resource lets you create a set and upload images programmatically for a given localization and device display type. You authenticate with an API key and push images per locale, per display family.
- Google Play Developer API. The
edits.images.uploadmethod uploads one image of a specified language and image type (phoneScreenshots,sevenInchScreenshots,tenInchScreenshots, and so on) into a pending edit, which you then commit.
Most teams do not call these raw. They use fastlane on top: deliver
(also exposed as upload_to_app_store) drives the App Store Connect API, and
supply (upload_to_play_store) drives the Play Developer API. Supply even
spawns multiple upload threads to push localized images concurrently. That is the real "bulk
upload" — it is an API loop, not a button in the dashboard.
Worth being clear about the cost: fastlane means a Ruby toolchain, a fastfile, store API credentials, and (for the Apple side) the usual code-signing and simulator plumbing. It pays off when you ship often. For an app that submits a few times a year, standing it up just to upload images can be more work than the drag it replaces. If you already run it for builds, adding the screenshot step is nearly free.
Where the screenshots come from is the real bottleneck
Notice that every path above assumes the files already exist — correctly sized, one set per device family, translated per language. That is the actual hard part. The App Store Connect API and the Play Developer API move finished images; they do not design them, resize them, or translate the captions. If you are producing 50 language variants at 5 device sizes by hand in a design tool, the upload was never your bottleneck.
This is the gap Mokbi closes. You build one design, and it renders every device size and every one of 50 languages from that single source — captions translated, layout re-flowed, each frame exported at the exact pixel dimensions its store slot expects. The output is a batch: a clean set of locale × device files, named and organized, ready to drop into the right buckets.
One-click publish to both stores
Mokbi solves exactly this. You build one set, and it renders every locale × every device size and publishes them to both stores — pushing straight to Google Play over the Play Developer API, and staging the sets in App Store Connect ready for you to submit. Apple requires the final Submit and review, so that last tap stays with you; everything up to it is handled. No manual per-locale, per-device uploading.
If you already run fastlane or the store APIs in your own CI, the same exported files feed straight
into deliver and supply. Either way the design, resize, and 50-language
translation are done for you — and now the publish is too.
The workflow that actually saves the afternoon
- Design once. Build the carousel a single time in the editor.
- Batch-export the matrix. Every device size × every language, at exact store dimensions, in one export.
- Publish to both stores. Mokbi pushes the sets to Google Play and stages them in App Store Connect for your final submit — or hand the files to fastlane
deliver/supplyif you run your own CI. - Next release, re-export and repeat. Change the design once, regenerate the whole matrix, upload again.
The math that matters: the number of buckets does not change, but the time per bucket collapses when you are dropping a finished, correctly-sized file instead of designing and resizing it first. That is the difference between an afternoon and a coffee break.