Why Apple Rejects App Store Screenshots (and How to Avoid It)

Apple rejects App Store screenshots when they don't accurately show the app, under section 2.3 (Accurate Metadata) of the App Review Guidelines. The most common triggers are screenshots that don't show the app in use (2.3.3), iPad screenshots that are stretched iPhone images, imagery or names from other platforms such as Android (2.3.10), prices in the image (2.3.7), and features the app doesn't actually have (2.3 and 2.3.1). A rejected screenshot usually puts the app in Metadata Rejected status, which you fix in App Store Connect and answer with a reply to App Review, without a new build.

Below is each guideline that affects screenshots, in Apple's own wording, the triggers we see most, the upload errors that look like rejections but aren't, and how to respond.

Which App Review guidelines cover screenshots?

All of them live in section 2.3 of Apple's App Review Guidelines, which opens: "make sure all your app metadata, including privacy information, your app description, screenshots, and previews accurately reflect the app's core experience." The numbered points that matter for screenshots:

The table paraphrases for space; quote the exact guideline text when you reply to App Review. Guideline numbers do get renumbered occasionally, so check the live page rather than an old blog post (including this one) before you cite one.

The most common screenshot rejection triggers

1. The screenshot doesn't show the app in use (2.3.3)

Guideline 2.3.3 reads: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen." It also allows "text and image overlays," so a designed screenshot with a caption, background and device frame is fine. What gets flagged is a screenshot where the app itself is missing or reduced to a token: a slogan on a gradient, a logo, a sign-in form, an onboarding carousel. Keep real, populated UI on every screenshot, and treat the first one with extra care, because it's the most visible (we covered what to put on your first App Store screenshot separately).

2. iPad screenshots that are really iPhone screenshots (2.3.3)

This is one of the rejections developers report most often on Apple's forums: the 13-inch iPad slot is filled with an iPhone screenshot that has been stretched, padded, or placed in an iPad frame. App Review treats that as not showing the app in use on iPad. The fix is to capture the app running on an iPad (or the iPad Pro 13-inch simulator) and design the iPad set around those captures. If your app doesn't support iPadOS, you don't need an iPad set at all.

3. Other platforms in the image (2.3.10)

Guideline 2.3.10 asks you not to "include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality." In screenshots that usually means:

• An Android phone frame, or Android status and navigation bars, often from reusing a Google Play set
• "Get it on Google Play" badges or an "Available on Android" caption
• Android-specific UI in a cross-platform app captured on the wrong device

Keep separate sets per store. Generators that export both from one project make this easy; so does a naming convention in Figma.

4. Prices and promotional claims (2.3.7)

Guideline 2.3.7 says "Metadata such as app names, subtitles, screenshots, and previews should not include prices, terms, or descriptions that are not specific to the metadata type." Captions like "Just $2.99/month", "Launch sale: 50% off" or a free-trial price banner are typical triggers. Describe what the app does instead; prices are already shown by the App Store.

5. Features the app doesn't have (2.3, 2.3.1)

Mockups of upcoming features, a design that differs noticeably from the shipping UI, or a capture from a different version of the app can all be read as misleading. Guideline 2.3.1 calls out "promoting content or services that it does not actually offer" specifically. Capture screenshots from the build you are submitting.

6. Paid features shown without a hint that they're paid (2.3.2)

Guideline 2.3.2 asks that the "app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases." If your hero screenshot shows a Pro feature, a small "Pro" or "Premium" label in the UI or caption, plus clear wording in the description, avoids the question.

7. Real data, licensed content and unfinished UI

Guideline 2.3.9 asks for fictional account information instead of a real person's data, and makes you responsible for the rights to everything shown. Celebrity photos, sports team logos or movie posters in a demo feed are a risk unless you have rights to them. Separately, guideline 2.1 asks that submissions be final versions, with placeholder text and other temporary content removed, so debug menus, "Lorem ipsum" and test-environment banners don't belong in screenshots either. Our guide to clean simulator and emulator screenshots covers setting up demo data and a tidy status bar.

Upload errors that aren't rejections

Some screenshot problems never reach App Review because App Store Connect refuses the file at upload. These are quicker to fix but just as blocking.

Apple's screenshot specifications list every accepted size per device group, and our screenshot sizes reference has the common ones in one table.

How to respond to a screenshot rejection

1. Read the message in App Store Connect

Rejection details appear in the App Review section of your app's page in App Store Connect (many developers still call it the Resolution Center, its older name). Apple includes the guideline number and usually a note about which screenshots and which device size triggered it. Read it closely: "your 13-inch iPad screenshots" and "your iPhone screenshots" need different fixes.

2. Fix the metadata, not the build

For the Metadata Rejected status, Apple's status reference says: "Read the message from App Review, edit the metadata to resolve the issue, and reply to the message from App Review." Replace the flagged screenshots for every localization that has them; a fix in English alone won't clear a problem that exists in your German set too. Check the scaled sizes in Media Manager as well.

3. Reply briefly and specifically

Say what you changed and where. Something like:

Thanks for the review. We've replaced the 13-inch iPad screenshots
in all 6 localizations with captures of the app running on iPad Pro
(13-inch). The previous images were scaled iPhone screenshots.
The build is unchanged.

4. If you disagree, explain or appeal

If you think the reviewer misread the screenshot (for example, a feature they couldn't find is behind a sign-in), reply with the steps to reach it and include demo account details in App Review Information. If that doesn't resolve it, Apple's App Review page describes an appeal to the App Review Board: give specific reasons the app complies, submit one appeal per rejected submission, and answer any outstanding questions first. Apple also offers 30-minute App Review appointments to talk through the guidelines before you submit.

A pre-submission checklist

• Every screenshot shows real, populated app UI from the build you're submitting
• iPad screenshots are real iPad captures, or there are none because the app doesn't support iPadOS
• No Android frames, Android system UI, Google Play badges or other-platform names
• No prices, discounts or trial pricing in the images
• Paid features are labelled as paid somewhere in the listing
• Imagery is suitable for a 4+ audience and you hold the rights to it
• Demo data is fictional; no placeholder text or debug UI
• Exact accepted pixel sizes, PNG or JPEG, no transparency, up to 10 per size
• Fixes applied to every localization, not just the primary language

For design issues that won't get you rejected but will cost you installs, see common app screenshot mistakes, and for the full build-to-upload process, how to make App Store screenshots.