App Store screenshot rejections: guideline 2.3 and how to avoid it
Screenshots are a surprisingly common App Review rejection reason. What guideline 2.3.3 actually requires, the mistakes that trigger it, and how to fix a rejection fast.
You fixed the crash, wrote the privacy labels, waited in the review queue — and got rejected over marketing images. Screenshot rejections feel petty, but they're common, and they're nearly always avoidable. Here's what Apple actually checks, the patterns that trigger rejections, and how to recover quickly when it happens.
What guideline 2.3.3 requires
The core text of App Review Guideline 2.3.3 is short: screenshots should show the app in use, not merely title art, login pages, or splash screens. The umbrella guideline 2.3 ("Accurate Metadata") adds the broader rule: everything on your product page must reflect what the app actually does.
In practice, reviewers look for:
- Real app UI somewhere in the frame. Marketing framing — captions, backgrounds, device frames — is fine and universal. A screenshot that is only marketing graphics with no product is not.
- Honesty. Features shown must exist in the build you submitted; screenshots must not show content the app can't produce.
- Appropriateness. Screenshots must fit your age rating — even if the app can display racier user content, the screenshots can't.
- No platform confusion. Android device frames, Material Design UI, or "Get it on Google Play" badges in an iOS listing are instant flags.
The rejection patterns we see most
Do
- Show genuine app UI in every screenshot, styled however you like
- Use captions and device frames around real screens
- Keep screenshots consistent with your age rating
- Update screenshots when you remove or change a feature
- Use current-generation Apple device frames (or none)
Don't
- Submit concept art or design mockups of unbuilt features
- Show a competitor's name, logo, or trademarked content
- Include pricing in screenshots that contradicts your actual IAP prices
- Show people's photos or content you don't have rights to
- Reference other platforms or 'beta / coming soon' features
A subtle one that trips up well-meaning developers: stale screenshots. You shipped v2 with a redesign, but the store still shows v1's UI. That's technically a 2.3 issue, and while it usually slips through review, it converts badly anyway — users notice when the app doesn't match its pictures, and it shows up in reviews.
"Show the app in use" — how stylized is too stylized?
The modern norm — bold background, big caption, app UI inside a device frame occupying half the canvas — is completely fine and used by Apple's own Design Award winners. The line is crossed when a reviewer can't identify actual product UI in the image.
Note this cuts against one popular growth-hack: pure text "meme" screenshots with no UI at all. They occasionally slip through review; they're also the most commonly cited screenshot rejection. Not worth the re-review cycle at launch.
If you've been rejected: the recovery playbook
- Read the rejection notice carefully — it names the guideline and usually the offending screenshot's position.
- Fix all frames, not just the named one. Reviewers spot-check; the next reviewer may flag the sibling you left alone.
- Screenshot metadata can be updated without a new binary — if only screenshots were rejected, you typically just replace the images in App Store Connect and reply to the review conversation.
- Reply politely in Resolution Center stating what you changed. Combative replies extend queues; factual ones shorten them.
- If you believe the rejection is wrong, you can appeal — but for screenshots, replacing the image is almost always faster than winning the argument.
Avoiding the whole cycle
The cheapest time to catch a 2.3.3 problem is before submission. When you produce screenshots — by hand or with AI — make sure the pipeline starts from real screens of your real app. That's also how Screenshot Roast's redesign mode works: it restyles your actual uploaded UI with captions and composition rather than inventing fictional screens, which keeps the output on the right side of the guideline — polished and honest. The examples gallery shows the pattern.