Submission Guide
Seven Patterns That Get App Store Screenshots Rejected
A practical breakdown of the most common screenshot-related rejection reasons during App Store review and how to avoid each one.
A large share of App Store rejections originate not in code but in metadata — screenshots, descriptions, and app names. Screenshots are the first asset a reviewer sees, which makes them a frequent rejection trigger. This guide walks through seven recurring rejection patterns and how to neutralise each one before submission.
1. Showing UI that does not match the shipped build
The most common reason. If the screenshot uses concept UI, beta-only screens, or features promised for a future release, Apple flags it as misleading.
How to avoid it: only use screens from the build you are actually submitting. Adding copy and background is fine, but altering the app UI itself is not.
2. Pricing or purchase claims out of date
Wording like "Free" or "First month free" embedded in a screenshot will fail review if the current build requires payment from day one.
How to avoid it: keep pricing claims out of screenshots when possible. Putting them in the app description means changes only have to be made in one place.
3. Comparative or superlative claims
"Best", "#1", "the only", "number one" — all of these are routinely flagged. Even with supporting evidence, reviewers cannot verify the claim quickly and tend to err on the side of rejection.
How to avoid it: replace "#1" with "1M downloads" and "best" with "5-star average across 1,200 reviews". Same emotional impact, near-zero rejection risk.
4. Other companies' trademarks
Comparison tables that include competitor logos, or demo data that uses recognisable brand names, get rejected to pre-empt rights disputes.
How to avoid it: use fictional companies and user names in demo data. If real branding is necessary, document permissions in the review notes so the reviewer can verify them.
5. Visible ads or external links inside the screenshot
Even if the live app includes an ad SDK, capturing screenshots with ad banners visible is rejected. Apple treats screenshots as a vehicle for the app's own value, and ads dilute that value.
How to avoid it: disable ads temporarily during capture, or capture moments where no ad is being served.
6. Wrong device frame
Android frames around iPhone screenshots, or wrong-aspect frames for iPad, all get flagged. Reviewers want to see at a glance which device the app is built for.
How to avoid it: if you use device frames, use the exact device family. The safest choice is no frame at all — clean fullscreen captures.
7. First screenshot looks like an ad
When the first screenshot consists of large copy on a background image with no actual app UI, reviewers reject it. Apple explicitly requires the first frame to feature the actual app screen.
How to avoid it: always include real app UI in the first frame. Copy and background are fine, but the app screen itself cannot disappear.
Six of these seven rejection patterns reduce to one principle: screenshots must reflect the actual shipped app. Fact-based descriptions are always lower risk than promotional language and tend to convert better as well. Running through this list once before submission dramatically lowers the cost of resubmission cycles.