How to change App Store screenshots without a new app version
You want to swap the screenshots on a live app today, you open App Store Connect, and the screenshot fields on the current version are read-only. That is Apple working as designed, not a bug. Screenshots are part of a version's metadata, and once a version is approved and released, its metadata is frozen. Here are the routes that actually change what shoppers see, and what each one costs you in build uploads and review time.
Why the fields are locked
App Store Connect stores screenshots against a specific app version. When your app is live, that version sits in a released state and its screenshots, description, and keywords are all locked. To edit any of them you work on a separate, editable version record, the one in the "Prepare for Submission" state. The live listing keeps showing the old screenshots until a new version is approved and released over the top of it.
Apple's own documentation is blunt about this: once your app is submitted and approved, you must create a new version to update the screenshots. So the question is not "can I edit the live version" (you can't). It's "which mechanism produces the smallest, fastest change."
Route 1: a new version record (the default)
This is the path most developers already know. In App Store Connect you create a new version, open the editable "Prepare for Submission" record, replace the screenshots, and submit for review. The important detail: you do not need to ship a new feature or a bug fix, but you do need a build attached to the version.
App Store Connect will not offer the build that is currently live in the new version's build picker. So in practice you do one of two things: pick another build you have already uploaded (a leftover from a past TestFlight upload works), or push a fresh binary with the same source code and a bumped build number. Neither adds functionality. But a build has to be there, and the whole version, screenshots included, goes through App Review. The new screenshots appear only after that version is approved and you release it.
Use this route when you are changing more than screenshots anyway, say a new description and keyword set alongside the visuals, since all of it can ride the same submission.
Route 2: Product Page Optimization (no new version, no new build)
Product Page Optimization (PPO) is Apple's built-in A/B testing feature, and it doubles as the one way to change screenshots and preview videos with no new version and no new build at all. You create a test, add a treatment with your new screenshots, and submit that treatment. Apple states directly that this metadata can be submitted without submitting a new version of your app.
The catch that keeps it honest: the new creative still passes App Review before the test can run. The one exception is reordering screenshots that are already approved and on the store, which needs no fresh review. Everything genuinely new gets looked at first.
PPO is built as an experiment, so results come back as an estimated lift in conversion rate, a percentage against your current page with a confidence read on the data. If you just want the new screenshots live for everyone rather than a measured test, you can create the test, run it, and then apply the winning treatment to your default product page. Applying a treatment ends the test and pushes that creative to every shopper, still with no binary upload.
One boundary worth stating plainly: screenshots and preview videos are build-free through PPO, but alternate app icons are not. An icon has to be compiled into the binary that is already on the store, so a genuinely new icon still requires a build. Keep icons out of a build-free screenshot swap.
Route 3: Custom Product Pages, for targeted variants
If you want a different screenshot set for a specific audience or ad campaign rather than a change to your main listing, Custom Product Pages let you publish alternate versions on their own URLs. Each variant is reviewed separately and is reached by link, so your default page is untouched. This is a targeting tool more than a "change the live listing" tool, but it belongs on the map when you are deciding how to move screenshots around without a full app release.
The one field you can change anytime: promotional text
Promotional text is the single App Store field you can edit with no new version and no App Review. It is a 170-character block that sits at the top of your description, and edits roll out on their own within a few hours (Apple allows up to 48). It is not indexed for keyword ranking, so it will not move your search position, but it is the right place for a time-sensitive line while a screenshot change is still in review.
Route by route: build and review at a glance
| Route | New build? | App Review? | Goes live |
|---|---|---|---|
| New version record | Yes, a build must be attached (code can be identical) | Yes | After approval and release |
| Product Page Optimization | No (screenshots and previews only; icons need a build) | Yes, unless reordering approved shots | When you apply the treatment |
| Custom Product Page | No | Yes, reviewed separately | After approval, reached by link |
| Promotional text | No | No | Within a few hours |
Which route to pick
- Just swapping screenshots, fastest path. Product Page Optimization. No build, one review pass on the new creative, then apply the treatment and it is live for everyone.
- Changing screenshots plus text or keywords. New version record, so the whole update ships in one submission.
- Different visuals for one campaign, not the main page. Custom Product Page.
- A line you need live in the next hour. Promotional text, while the real screenshot change is in review.
Where Mokbi fits
Mokbi runs the whole screenshot refresh end to end. It designs the new screenshots and the Google Play feature graphic, then writes the full listing, title, subtitle, description, and promotional text, and translates all of it into 50 languages in one pass. That is the part that usually stalls a screenshot refresh, and Mokbi does it in a single flow.
Then it publishes. Mokbi pushes the listing and the finished assets straight to Google Play through the Play Developer API, where they go live directly, and stages everything in App Store Connect ready for you to submit. Apple requires that final Submit and App Review pass on your own account, so that one click stays with you, but the creative and the copy are already in place, in every language, sitting in a new version or a Product Page Optimization test the moment you open the console.