Can You Update App Store Screenshots Without a New Build? (2026)
TL;DR: Yes. Screenshots, app previews, description, keywords, and your support and marketing URLs all live on a version entry in App Store Connect, not inside your compiled binary. You do not need to build, archive, or upload anything to change them. What you actually need is a new version entry with your existing approved build reattached, then a submission through App Review. The one exception is promotional text, which updates on a live app with no new version and no review at all.
This comes up because App Store Connect's own interface makes screenshots and builds look like the same step. They are not. Apple's App Store Connect Help documentation treats app metadata (screenshots, description, keywords, pricing, URLs) and the app binary as two separate objects that happen to ship together inside one version. Once you see them as separate, the workaround for a screenshot refresh stops requiring a code release at all.
The confusion has a real cost. Teams that treat every screenshot update as a code release end up queuing ASO work behind sprint planning, feature freezes, and QA cycles that have nothing to do with a product page image. If your last screenshot refresh shipped alongside a feature release three months ago because "that's when we had a build going out," this post is for you. The mechanism for changing a version's assets does not care when your engineering team last shipped code.
What actually needs a new build, and what does not
Most of what shows up on your product page is metadata, not code. Here is the breakdown that matters before you touch anything in App Store Connect:
- Screenshots and app previews. Stored as version metadata. No new build required.
- Description and keywords. Also version metadata. No new build required.
- Promotional text. A version field you can edit on a live app with no review at all. See the next section.
- Support URL and marketing URL. Version metadata. No new build required.
- App icon. Pulled from the binary's asset catalog, not from App Store Connect. This one does need a new build.
- App name and subtitle. App Information fields, editable without a new version, though Apple can still flag a name change for manual review if it reads as a trademark or spam issue.
Everything in that list except the app icon can change with the build you already have live. The confusion comes from App Store Connect requiring a version entry to hold the new screenshots, and a version entry looking, at a glance, like something that needs a build attached to mean anything.
The one field that skips App Review entirely: promotional text
Promotional text is a 170-character field that sits above your description. Apple built it specifically so you can change a line without a submission cycle: no new version, no build, no review queue. Edits typically show up on the live listing within a few hours.
It cannot carry a screenshot or an app preview, so it will not solve a stale visual set. What it is good for is exactly the kind of thing that used to sit behind a full review: a launch discount window, a seasonal note, a "now available in 12 more languages" line the day your localization work ships. If the change is a sentence and not an image, put it here first and see if it is enough.
Step by step: updating screenshots without a new build
1. Start a new version in App Store Connect
From your app's page, add a new version for the platform you are updating. You cannot edit screenshots on a version that is already live or already in review. A new version is the only place they can go.
2. Reattach your existing build, do not upload a new one
The new version will ask you to select a build before it can be submitted. Choose the build that is already live. There is no requirement that the build be new, only that one is attached. This is the step that actually answers the question in this post's title.
3. Replace the screenshots and app previews
Upload the new set for each device size and each localization you support. Check current required dimensions before you start; Apple has changed size requirements more than once as new device classes shipped, and a size mismatch is a rejection you can avoid entirely. Our App Store screenshot sizes reference stays current on exactly which pixel dimensions each device class needs.
4. Update description, keywords, or URLs if the refresh calls for it
You are already inside a version edit, so this is the point to fix anything else that has drifted: a description that references a removed feature, keywords that stopped matching what the app does, a support URL that redirects somewhere stale.
5. Submit for review
Submit the version. It goes through the same App Review queue as a binary submission, because Apple reviews the version as a whole, screenshots included. The build was already approved once; you are not resubmitting it, but the version around it still gets checked.
New build, new version, or neither
| Field | New build needed? | App Review needed? |
|---|---|---|
| Screenshots / app previews | No | Yes |
| Description | No | Yes |
| Keywords | No | Yes |
| Promotional text | No | No |
| Support / marketing URL | No | Yes |
| App icon | Yes | Yes |
| App name / subtitle | No | Usually |
| In-app purchase name/description | No | Yes |
Updating screenshots for one locale without touching the rest
Screenshots are set per localization within the same version, so you can replace the German set without re-uploading English, French, or Japanese. This matters for anyone running a staggered localization rollout: you do not need every language ready on the same day to ship an update. Fix the locale that is actually broken (a translation error, a screenshot showing a UI string that overflowed, a feature callout that no longer matches the app) and leave the rest of the version untouched.
The submission still covers the whole version, so App Review checks all localizations you have live, not only the one you changed. A localized screenshot that shows English UI text under a non-English caption is a real rejection reason under the metadata guidelines, and it is also the kind of gap that is easy to miss when you are only looking at the language you just fixed. Check the set you are not touching, not only the one you are.
What App Review actually checks on a metadata-only submission
A version with no new build still goes through full review, and the checks are not rubber-stamped just because the binary already passed once. Reviewers verify that screenshots depict the app as it currently behaves, that the description does not promise a feature the app does not have, and that the keywords are not stuffed with unrelated terms. A screenshot that shows a paywall the reviewer cannot reach, or a screen your last redesign removed, gets rejected the same way it would on a full binary submission. Removing the build from the equation removes an upload step from your side, not a review step from Apple's.
Practically, this means a metadata-only update is not a shortcut around App Review scrutiny. It is a shortcut around the build pipeline. Budget for the same review wait you would budget for any submission, and make sure whatever you are shipping (new screenshots, a rewritten description) would survive a reviewer actually reading it.
Product Page Optimization is a different tool for a different question
App Store Connect also offers Product Page Optimization, which lets you run up to three alternate screenshot or icon treatments against a share of your traffic and compare conversion. It is easy to conflate with a plain screenshot update because both involve uploading new screenshots inside App Store Connect, but they answer different questions. A version update changes what every visitor sees. A PPO test changes what a percentage of visitors see, temporarily, so you can measure which version wins before committing it as the default. We cover the setup and traffic-split mechanics in our Product Page Optimization guide.
If you already know your new screenshots are better, a version update ships them to everyone today. If you are not sure, PPO is the tool that tells you before you commit.
Why this trips people up
The most common version of this mistake is batching. A team decides screenshots need a refresh, then waits for the next feature release to "bundle it in," because updating screenshots feels like it belongs with a build. That wait is unnecessary and it costs real time. Stale screenshots keep converting at whatever rate they were converting at, for however many weeks the next release takes to ship.
There are two real constraints worth knowing before you start. You cannot edit a version that is already Ready for Sale or Pending Developer Release directly, which is why step one is always a new version, not an edit of the current one. You also cannot have two submissions in flight for the same platform at once, so if a build is currently in review, your metadata-only version has to wait for that review to clear before you can submit it.
One more reason to get this right the first time: Apple now indexes the text inside your screenshots for App Store search, which we cover in detail in our screenshot text indexing guide. A caption describing a feature you removed two releases ago costs you more than looks. It can be part of why your listing surfaces for searches that no longer match what the app does.
Frequently asked
Do screenshot-only updates require App Review?
Yes, with one exception. A new version carrying only screenshot changes still goes through App Review, the same as any other version submission. Promotional text is the single field that updates on a live app with no review at all.
Can I skip creating a new version entirely?
No. Screenshots and app previews are stored on a version entry, so at least one new version is required to change them, even though that version does not need a new build. Promotional text and, in most cases, your app name and subtitle are the fields you can edit without a new version.
Does updating screenshots reset my App Store ranking?
There is no published evidence that a metadata-only version update affects ranking. Apple's own ranking-factor guidance does not list version-update frequency as a signal. What can genuinely affect discovery is screenshot text itself, since Apple indexes it for search.
How long does a metadata-only review take?
Apple does not publish a separate review-time figure for metadata-only submissions versus binary submissions. Both enter the same App Review queue. If your update is time-sensitive, promotional text is the only field guaranteed to avoid the queue completely.