Update App Store Screenshots Without a New Build [2026]

You can update App Store screenshots without uploading a new build by creating a metadata-only version in App Store Connect, or by running a Product Page Optimization (PPO) test that doesn't include alternate app icons. Both routes skip Xcode entirely. Apple's own docs are explicit that PPO tests without alt icons "can be submitted for review independent of a new app version" [3].

The catch is that Apple's documentation explains each piece in a different help page: the screenshots page, the create-a-new-version page, the PPO page, the promotional text page. There's no single map of which surface needs which submission. This post is that map.

TL;DR:

• Screenshots, app preview videos, description, keyword field, subtitle, name, and category can all be updated via a metadata-only version submission. No binary upload, no Xcode. The version still goes through App Review, usually inside 24 hours.
• App icons are the one exception. The icon variants must be compiled into the binary, so any icon change needs a new build.
• Promotional text is the only field you can edit at any time without submitting any version at all. 170 characters, propagates in 2 to 48 hours [4].
• PPO is for visual elements only: app icons, screenshots, app preview videos [3]. Text fields (name, subtitle, description, keywords) are not PPO-testable. Use a straight metadata version for text changes.
• Bundle everything. Apple auto-transfers the previous version's metadata into the new version [2], so a metadata-only submission is the right time to also rewrite the description, swap keywords, refresh the subtitle, or update the category. One review cycle, multiple changes.

Table of Contents

• What counts as metadata vs. what needs a new build?
• How do you submit a metadata-only version in App Store Connect?
• When should you use PPO instead of a metadata-only version?
• What other metadata can you bundle into the same submission?
• Which fields can you change without any submission at all?
• What gets a metadata-only submission rejected?
• Ship the change, not a release

What counts as metadata vs. what needs a new build?

Metadata is everything in your App Store listing that lives in App Store Connect rather than inside the app binary. Screenshots, captions, descriptions, keywords, and preview videos are metadata. The app icon is the one visible field that's part of the binary, so icon changes need a new build [3]. The decision is binary by field, not a judgment call.

Here's the field-by-field map. Metadata means a version can ship without a build upload. Binary means you have to compile and upload through Xcode.

The asymmetry is what catches indie devs. Most assume any visual change needs a build. Apple's actual line is the opposite: visuals on the product page are metadata, the icon is the only exception, and text fields are always metadata.

For a deeper write-up of the text fields specifically (name, subtitle, keyword field), see the metadata for indie devs guide. Use the character counter tool to check captions against per-field limits before submitting.

How do you submit a metadata-only version in App Store Connect?

A metadata-only submission is a regular new app version where you change the metadata fields and skip the binary upload. Apple's docs don't use the phrase "metadata-only version," but the workflow is supported: create a version, edit fields, submit for review, reuse the current build [2]. Review typically lands inside 24 hours for minor changes.

The exact steps:

1. Open App Store Connect. Pick the app. Confirm the current version status is "Ready for Distribution" before initiating a new version [2].
2. Click the plus icon next to "iOS App" (or the equivalent for your platform) in the sidebar. Enter a new version number that increments the current one (e.g., 1.4.1 if currently 1.4.0).
3. Apple auto-transfers the current version's metadata into the new version [2]. Every field is pre-filled with what's live today.
4. Edit the fields you want to change. Upload new screenshots and previews. Rewrite the subtitle. Refresh the keyword field. The auto-transfer means you only touch what you want changed.
5. Skip the build upload section. Under "Build," select the current live build instead of uploading a new one. This is the move that makes the submission metadata-only.
6. Submit for review. Minor changes (caption edits, screenshot swaps, subtitle tweaks) usually clear App Review in a few hours, sometimes overnight. Larger changes (a full description rewrite or category change) tend to go to human review and clear inside 24 hours.
7. Wait for rollout. Once approved, the change propagates to all App Store regions within 24 hours.

The end state is a new version number with refreshed metadata pointing at the same compiled binary that was already live. From the user's perspective, the listing looks updated; the app they download is identical to what they would have gotten yesterday.

One gotcha worth flagging. Submit on a Tuesday or Wednesday morning Pacific time if you can. Apple's review queues are most predictable mid-week. Friday submissions sometimes carry over the weekend.

When should you use PPO instead of a metadata-only version?

Use PPO when you want to A/B test a creative change against your live listing. Use a metadata-only version when you've already decided what to ship and just need to roll it out. PPO splits traffic across treatments for up to 90 days [3]; a metadata version replaces the live page outright.

The two routes solve different problems.

Use PPO when:

• You're testing whether a new frame 1, hero shot, or app preview video lifts conversion versus your current set.
• You want to compare two or three creative directions before committing.
• You can afford to leave a chunk of your traffic on the original page during the test.
• The change is to screenshots, app icons, or preview videos. (PPO does not support testing text fields like name, subtitle, description, or keywords [3]. Those go through a metadata version.)

Use a metadata-only version when:

• You've already decided the new set is better and want 100% of traffic on it.
• The change includes text fields PPO can't test (subtitle rewrite, description refresh, keyword swap).
• You're shipping a seasonal swap, a bug fix, a localization fix, or a category-driven update where there's no question of "which version is better."
• You're outside a PPO test window and the four-week keyword stabilization period from the last metadata update [reference: the cadence guide covers the stabilization math].

PPO's traffic-split math is also worth flagging because it surprises people. From Apple's own example: "if you allocate 40% of your traffic to your test and have two treatments, each treatment receives 20% of your total traffic and your original product page receives the remaining 60%" [3]. The original page keeps serving most users until you explicitly apply the winning treatment. A test is not a swap. The PPO A/B testing guide covers test design and stop conditions.

One more constraint. You can run one PPO test at a time per app, for up to 90 days [3]. If you want to test two unrelated creative ideas back to back, that's two cycles of three months each, plus the four-week stabilization window between them. PPO is slow on purpose.

What other metadata can you bundle into the same submission?

Bundle every metadata change you have queued into the same submission. Apple auto-transfers the previous version's metadata when you create a new version [2], so you're starting from the current live state. Edit screenshots, description, subtitle, keyword field, and category in one pass. One review cycle, multiple changes shipped together.

This is the part most cadence guides skip. A metadata-only version submission is not "the screenshots submission." It's a full re-edit of every metadata field, with most fields pre-filled to today's live values. Treating it like a screenshots-only event leaves easy wins on the table.

The bundling pattern that works:

• Pair a screenshot refresh with a caption rewrite. If you're swapping the hero image, also rewrite the caption stack so the visual and the text reinforce each other. Use the screenshot copy tool to draft caption variants before opening App Store Connect.
• Pair a screenshot refresh with a subtitle update. Subtitle is the second line under your app name on the listing, and it carries keyword weight. If you're rethinking your positioning enough to redesign screenshots, the subtitle probably needs a pass too. Check the subtitle optimizer for character-bound options.
• Pair a screenshot refresh with a keyword field rewrite. Apple's algorithm extracts keywords from your screenshot captions on top of the keyword field [reference: the screenshot captions guide covers OCR ranking]. If your new captions surface keywords that aren't in your 100-character keyword field, drop the redundant ones and add the ones you've just exposed in copy. The keyword field optimizer handles the dedup math.
• Pair a screenshot refresh with a category audit. App Store categories have shifted over the last two years (Productivity is more crowded, Lifestyle is broader). If your category was set at launch and you haven't reviewed it, the metadata version is the right time.

The wrong move is sequential submissions: screenshots one week, keywords the next, description the week after. Each submission resets the four-week keyword stabilization window. Apple's own conversion benchmarks reward stability after a change, not constant change [5]. Bundling into one submission lets the algorithm settle once.

The one thing you should NOT bundle: a metadata version and a binary upload on the same day. Let your last app release settle before introducing another variable. App reviews and screenshot reviews run on different tracks, and a collision means neither change gets clean conversion measurement.

Which fields can you change without any submission at all?

Three fields are editable on the live App Store listing without going through any version submission or App Review: promotional text, in-app event metadata, and per-locale localization fixes to already-approved fields. Promotional text is the most useful for time-sensitive messaging because it's a 170-character banner that takes 2 to 48 hours to propagate [4].

Promotional text appears at the top of your description on the live listing. You can edit it at any time without submitting a new version [4]. The use case is time-sensitive callouts: a Black Friday sale, a feature launch, a press hit, a seasonal campaign. Update it, save in App Store Connect, and the new text rolls out without review. Apple's caveat: "promotional text doesn't affect your app's search ranking so it should not be used to display keywords" [4]. Use it for conversion messaging, not for stuffing the keyword surface.

In-app event metadata has its own review track separate from the main app version. You can create or edit events without touching the listing itself. Most indie devs ignore in-app events; the surface is built for games and content apps with calendar-driven moments.

Per-locale fixes are a gray area. If a locale was previously approved and you're fixing a typo in the description for one specific locale (without changing other fields), the change usually rides through with minimal review. Any substantial per-locale change still goes through the standard metadata version submission.

The honest constraint on promotional text: it's a banner, not a strategy. The 170 characters sit at the top of the description block, so they're scanned by users who already opened the product page. Don't expect promotional text to fix a conversion drop caused by a weak frame 1. The fix for a weak frame 1 is a new frame 1, shipped through a metadata version or PPO test.

What gets a metadata-only submission rejected?

Metadata-only submissions get rejected for the same reasons binary submissions do: screenshots that misrepresent app functionality, screenshots referencing features not in the build, screenshots showing competitor brand IP, and descriptions that claim functionality the app doesn't have. The metadata-only path doesn't get a softer review; it's the same App Review team checking the same rules.

The high-frequency rejection patterns for metadata-only submissions:

• Screenshots show a feature that isn't in the live binary. This is the most common. If your screenshots show a "new dashboard" or a "new export option" that isn't in the build the user would download today, the submission gets metadata-rejected. The fix is to either ship the binary first or remove the screenshot showing the unbuilt feature. App Review's principle: "Screenshots should match real, testable app states. If it's not accessible in the build submitted, it shouldn't be shown."
• Captions reference platforms or surfaces the app doesn't support. A caption saying "Sync to Apple Watch" on an app that hasn't shipped watchOS is a rejection. Same for "Available on Vision Pro," "Now on iPad," or any platform claim that doesn't match the binary's supported platforms.
• Captions contain pricing or promotional claims that don't match the current pricing. "Free for limited time" while the app is paid will get flagged. Pricing claims belong in promotional text (where they can be edited without review), not in screenshot captions.
• Localized screenshots have hardcoded text in another language. A French locale screenshot with English captions baked into the image is a localization rejection. Each locale needs its own per-language image asset. The Germany screenshot text expansion guide covers per-locale image production.
• Description mentions competitor names, "best of" rankings, or third-party trademarks. Apple's review guidelines treat description copy strictly. "Beats Calm" or "Better than Headspace" gets rejected.
• Description claims certification or awards that aren't verifiable. "Apple's #1 productivity app" without a public award reference, or "FDA approved" without filings, gets flagged.

If you get a metadata rejection, you usually don't need to upload a new build to fix it. Edit the offending field in the same version (often you can fix the issue and resubmit the same metadata version), and the resubmission flows back through review. The build attached to the version stays the same.

The 5 mistakes that kill conversions guide covers screenshot patterns that don't get rejected but still hurt conversion. Avoiding both is the right bar.

Ship the change, not a release

Metadata-only submissions are the underused path for keeping a listing fresh between app releases. The mistake indie devs make is treating "update screenshots" as a side quest that needs a coordinated app release. It doesn't. Open App Store Connect, create a metadata version, edit the fields, submit. Inside 24 hours you have a refreshed listing on the same binary that's been live for weeks.

Bundle every queued metadata change into the same submission. Use promotional text for time-sensitive messages without any submission at all. Reserve PPO for genuine A/B tests, not for shipping a decided change. And keep the four-week keyword stabilization window in mind so each submission has time to mean something before the next one lands.

The screenshot production itself doesn't need to take more than an afternoon. Try AppScreenshotStudio today for free until the new frames are ready, then ship the metadata version the same day.