App Store Screenshot Rejection: Fix Without a New Build

An App Store screenshot rejection almost never needs a new build. Screenshots are metadata, so a rejection over them lands as a Metadata Rejected status: you edit the screenshots in App Store Connect, keep the same build you already uploaded, and resubmit. Most fixes ship the same day, not after a multi-day rebuild.

That gap between what the rejection feels like and what it actually requires is where solo developers lose time. The email says "rejected," the instinct is to open Xcode, bump the version, archive, and re-upload. None of that is necessary when the only thing Apple flagged is an image. You're one metadata edit and one reply away from being back in the queue.

TL;DR:

• A screenshot rejection is a metadata rejection. Apple's status for it is "Metadata Rejected," which means "App Review didn't accept your metadata," not your code [1].
• No new binary required. You can resubmit the same build after resolving a metadata issue [2]. Edit the screenshots in App Store Connect, don't rebuild.
• Resubmit or reply. Fix the rejected item and tap Resubmit to App Review [3], or reply in Resolution Center with the changes you made and any supporting attachments [2].
• It's fast. On average, 90% of submissions are reviewed in less than 24 hours [4], and a metadata re-review usually clears even quicker.
• Know the exceptions. A screenshot that shows a feature your app doesn't have, or one at the wrong pixel size, is still a metadata fix, but a true functionality rejection that happens to mention screenshots is not.

The full list of what triggers each screenshot rejection covers prevention. This guide is about recovery: what to do once the rejection has already landed.

Table of Contents

• Is a screenshot rejection a metadata rejection or a binary rejection?
• Do you need a new build to fix a rejected screenshot?
• How do you fix and resubmit after a screenshot rejection?
• When should you reply in Resolution Center instead of resubmitting?
• How long does the re-review take, and can you speed it up?
• Which screenshot rejections need more than a metadata fix?
• Takeaways

Is a screenshot rejection a metadata rejection or a binary rejection?

It's a metadata rejection. Apple separates the two in App Store Connect. The Metadata Rejected status means "App Review didn't accept your metadata," and the required action is to "edit the metadata to resolve the issue, and reply to the message from App Review" [1]. A plain Rejected status means "your app wasn't accepted" [1], which is the one that points at the binary.

Screenshots, app previews, descriptions, keywords, and promotional text are all metadata. When App Review flags any of them, your code passed. The reviewer looked at the image, found it broke one of the App Store Review Guidelines under Section 2.3 [5], and stopped there. The build sitting in App Store Connect is the same build that's about to go live once the image is fixed.

Knowing which status you're in tells you which tool to open. Metadata Rejected means you stay inside App Store Connect and never touch Xcode. A binary Rejected status, or a rejection that cites your app's behavior rather than its images, is the one that sends you back to a new build.

Do you need a new build to fix a rejected screenshot?

No. Apple's own help is explicit: "If your app was rejected for a metadata issue, you can resubmit the same build after resolving the issue" [2]. The build you already uploaded stays attached to the version. You replace the offending screenshots in App Store Connect, and that same binary goes back into review with new images.

This is the single most useful thing to know when a rejection lands, because the rebuild reflex costs the most time for no reason. A fresh archive and upload means waiting for the binary to process, re-running any TestFlight checks, and re-attaching it to the version. A screenshot swap skips all of it. You upload the corrected images to the version, confirm them, and resubmit.

There's one more lever the rebuild reflex hides. You can correspond with Apple directly: "You can correspond with Apple, and include attachments, such as screenshots and supporting documents, until you resubmit to App Review" [2]. So if you think the reviewer misread your screenshot, you can attach a corrected version or an explanation in the same thread rather than guessing at a silent re-upload. The build never moves.

How do you fix and resubmit after a screenshot rejection?

Open App Store Connect, read the exact guideline the reviewer cited, replace the flagged screenshots on the version, then resubmit the corrected item. When any item in a submission is rejected, the submission status changes to Unresolved Issues [3], and you "edit and resubmit, or remove the rejected items from the submission" [3].

The concrete steps for a screenshot-only rejection:

1. Read the message first. App Review tells you which guideline failed and often which screenshot. Fixing the wrong image just earns a second rejection.
2. Re-export the corrected screenshots. Strip the flagged element: the splash-screen frame, the price overlay, the Android device, the unreleased feature. Keep the exact required pixel dimensions so you don't trade one rejection for a sizing one.
3. Replace the images on the version in App Store Connect. Upload the new set to the same version. The build stays where it is.
4. Resubmit the item. "Once you edit or remove all rejected items, click Resubmit to App Review from the submission details page" [3]. That's the whole loop.

You can edit an item once before resubmission [3], so make the fix complete the first time rather than nudging one image and hoping. If two screenshots were flagged, correct both before you resubmit.

When should you reply in Resolution Center instead of resubmitting?

Reply when you disagree with the reviewer or need to show your fix, rather than silently swapping images. When your app is rejected, "you'll get a message containing information about the rejection," and you can correspond with Apple and attach screenshots and supporting documents until you resubmit [2]. That thread is where a contested rejection gets resolved.

Use the reply path in two situations. First, when you believe the screenshot already complied and the reviewer misread it: attach the image with an explanation instead of changing a set that was fine. Second, when the fix needs context the reviewer can't infer, such as proof that a "superlative" claim in your caption is documented. For a Metadata Rejected status, editing the metadata and replying is the documented action [1], so the reply isn't optional politeness, it's part of the loop.

If you simply agree and fix it, you don't need a drawn-out conversation. Correct the images, resubmit the item, and the review continues. The reply channel is there for the cases where a fix alone won't settle the question.

How long does the re-review take, and can you speed it up?

Usually under a day. Apple reports that "on average, 90% of submissions are reviewed in less than 24 hours" [4], and a metadata re-review is lighter than a full binary review because the reviewer is checking one corrected asset, not retesting your app. Most screenshot fixes clear well inside that window.

When a day is still too long, you can ask for an expedited review. Apple grants it "if you face extenuating circumstances, such as fixing a critical bug in your app or releasing your app to coincide with an event you're directly associated with" [4]. A cosmetic screenshot swap rarely qualifies on its own. A screenshot rejection that's blocking a launch tied to a dated event is a stronger case, and the request needs the event, its date, and your app's association with it [4].

Don't burn an expedite request on a routine fix. The metadata re-review is already fast, and expedited reviews are a finite goodwill budget you'll want for a genuine launch-day emergency.

Which screenshot rejections need more than a metadata fix?

A screenshot that promises a feature your app doesn't have. That's the one case where swapping the image isn't the whole story. Under Guideline 2.3.1, screenshots must represent what the app actually does [5], so if you showed a timer screen that isn't in the build, you either remove that screenshot (a metadata fix) or actually ship the feature (a new build). The honest answer depends on which you intended.

Two adjacent cases stay in metadata territory:

• Wrong dimensions. A sizing rejection is fixed by re-exporting at the exact required pixels and re-uploading, no new build. The current required sizes live in the App Store screenshot sizes guide and the full dimension reference.
• Updating a live app's screenshots later. Changing screenshots on an app that's already approved and on sale is a different workflow from in-review recovery. Once an app is live, a routine new version carrying metadata changes still needs a freshly uploaded build, so the one genuine no-build route for screenshots is a Product Page Optimization test applied to your product page. That path is covered in updating App Store screenshots without a new build.

The line to watch: if the rejection cites your app's behavior or a crash and only mentions screenshots in passing, that's a binary rejection wearing a metadata costume. Fix the functionality, ship a new build, and treat the screenshot note as secondary.

Takeaways

A screenshot rejection reads like a wall and works like a door. The status is Metadata Rejected, the build stays put, and the fix is an image swap followed by a resubmit or a Resolution Center reply. Treat the rebuild reflex as the actual time sink, because that's what it is.

Before your next submission, it's cheaper to not get rejected at all. Walk the pre-submission compliance checklist so the flagged elements never make it into the upload, and keep your set inside the screenshot best practices that reviewers reward. Exporting at exact App Store dimensions and keeping visible app UI above the 60/40 line removes the two most common reasons a fix becomes necessary in the first place.