Screenshot rejections,
and how to stop collecting them.
Screenshots get rejected at two different gates, and knowing which gate you hit tells you the fix. The first is a validator that checks pixels and formats the moment you upload. The second is a human at App Review comparing what your screenshots promise against what your app does. Both are predictable once you know what they check.
Gate 1: the upload validator
App Store Connect checks screenshots mechanically before review ever starts. These rejections arrive instantly and the error messages are literal. The complete list of what it enforces:
- Exact dimensions. Every screenshot must match a supported size for its device class, to the pixel. 1290×2796 works; 1290×2795 does not. The size guide has the full table.
- No letterboxing. A smaller screenshot padded to the right dimensions has the right pixel count and still fails, the validator isn't fooled by borders, and reviewers reject what slips through. Render at the target size instead.
- Format. PNG or JPEG only. HEIC, which is what iPhones capture by default, fails. Convert before upload.
- Color space. sRGB or Display P3. Screenshots exported from design tools in CMYK or exotic profiles get refused or color-shifted.
- Count. Up to 10 per device size per locale. The eleventh doesn't upload.
Gate 1 failures cost minutes. If your pipeline renders at exact store sizes in PNG, which is what the screenshot editor's export does, you will simply never see them. If you already have images and want to know which slots take them, run them through the spec checker first.
Gate 2: what the human reviewer checks
Apple's App Review works from guideline 2.3, "Accurate Metadata". The screenshot-relevant parts compress to one sentence: screenshots must show the app being the app. The recurring rejections:
Not showing the app in use
A screenshot set that's all splash screens, logos, or concept art gets rejected, reviewers want the actual product on screen. Games are the sharp end of this rule: promotional artwork in place of real gameplay is one of the most common 2.3 rejections there is. Marketing framing around a real screenshot is fine; marketing instead of a real screenshot is not.
Features the app doesn't have
Showing UI that doesn't exist in the submitted build, a planned feature, a mockup of v2, an AI-generated fantasy screen, is the fastest route to rejection, and repeat offenses put your account at risk. The screenshot set must be reproducible on a device running the build you submitted.
Mentioning the other platform
A screenshot, caption, or award badge that references Android, Google Play, or "also on..." violates 2.3.10. It sounds obvious; it ships constantly via reused marketing assets. Google is looser in the other direction, but cross-store references are a bad idea everywhere.
Pricing and claims that can drift
A "$4.99" in a screenshot becomes false the day you change the price, and stale prices in screenshots are a rejection. Same for "editor's choice", star ratings, and award badges: claims must be true, current, and yours. If you show ratings, show your real ones and plan to update.
Other people's stuff
Screenshots containing third-party content you don't have rights to, recognizable characters, celebrity photos, another company's trademarks, album art, draw rejections under the intellectual-property guidelines. This includes the content inside your app's UI in the screenshot: a media app should demo with content it can license, not this week's box office.
Device frames are allowed and Apple provides official product bezels for exactly this. Two rules: use current-generation hardware imagery, and don't distort or recolor Apple's device art beyond what their marketing guidelines permit. Generic frames, like the ones Mockstack draws, sidestep the question entirely.
The Play Store's version of all this
Google's review is mostly automated and its screenshot rules live in the "metadata policy". Different emphases, same spirit:
- Graphic assets must reflect the app. Same accuracy principle, enforced by sweeps rather than a person, which means violations can be flagged months after approval, not just at submission.
- No performance or ranking claims. "Best", "#1", "top app of 2026" in screenshots or captions are explicitly called out in Play's metadata policy. Apple mostly tolerates these; Google does not.
- Content ratings apply to screenshots. A screenshot showing violence or suggestive content stricter than your rating allows can trip a policy flag even when the in-game content is rated correctly.
- Sales-y clutter is policed. Bursting "SALE 90% OFF" badges and emoji spam in graphics are flagged as misleading or low-quality metadata.
When the rejection arrives anyway
Screenshot rejections are the cheapest kind to fix. On the App Store, the notice lands in the Resolution Center naming the guideline; on Play, the Policy status page names the policy. Three things worth knowing:
- You usually don't need a new build. Metadata, including screenshots, can be corrected and resubmitted on its own, and re-reviews of metadata-only fixes are typically fast.
- Fix the set, not the shot. If one screenshot drew a 2.3 flag, reviewers often re-check the rest with fresh eyes. Sweep the whole set for the same class of problem before resubmitting.
- Disagree politely, once. If you believe the reviewer misread, the "concept art" is a real in-app screen, say, reply in the Resolution Center with a device video reproducing it. It works more often than resubmission roulette.
The pre-upload checklist
- Every screenshot reproducible on a device running the submitted build
- Exact store dimensions, PNG, sRGB or P3, no letterboxing
- No prices, ratings, or awards you aren't prepared to keep current
- No other platform's name anywhere in the set
- No third-party characters, people, or trademarks without rights
- Demo content is clean at your content rating, on both stores
- Games: real gameplay in the first three shots, not key art
Run the list before every submission, it's two minutes against a review cycle. The captions on those screenshots deserve the same care: that's the copywriting guide.