Your build passed review, your code is fine — and the rejection email is about your screenshots. It's one of the most frustrating ways to lose days on a release, because screenshot rejections are almost always avoidable and almost never explained clearly.
Screenshots fail at two different gates, and the fix depends on which one caught you:
- App Store Connect refuses the upload — a technical validation failure, before review ever starts.
- App Review rejects the submission — a human reviewer flags your metadata, usually citing a guideline number like 2.3.3.
This guide covers both, rejection by rejection, with the guideline references and the fastest path back to "In Review."
Gate 1: App Store Connect Won't Accept the File #
These aren't review rejections — the upload simply fails or the slot stays red. Three causes cover nearly all cases:
Wrong pixel dimensions #
Every device slot accepts exact sizes only. A 1290 × 2796 image in a slot expecting 1320 × 2868 fails silently or with a vague error. This is the most common blocker on submission night — check your files against the complete screenshot size reference, or drop them into our free screenshot validator, which tells you instantly which slot (if any) each image fits.
Wrong format or color profile #
Screenshots must be PNG or high-quality JPEG, RGB (Display P3 and sRGB are both fine), no alpha transparency in JPEGs, no CMYK exports from design tools.
Wrong count #
Each device size takes 1–10 screenshots per locale. Zero in a required slot blocks submission entirely — a classic surprise when you add watchOS or visionOS support and discover those platforms need their own sets.
Fix: regenerate at the exact required sizes. If you're exporting by hand from a design tool, this whole gate disappears with a screenshot generator that exports every slot's exact dimensions from one design.
Gate 2: App Review Rejections, by Guideline #
Guideline 2.3.3 — screenshots don't show the app in use #
The big one. Apple's rule: screenshots must show the app in use — not just the title art, the login page, or the splash screen.
Typical triggers:
- A screenshot set that's mostly logo, tagline, and marketing artwork with little visible UI
- Login/onboarding screens as your primary screenshots
- Concept mockups of features that look nothing like the shipped app
- Screenshots of a different platform's UI (the web app, the Android version)
Fix: rebuild the set around real screens. The good news: the layout that passes review — actual UI in a device frame with a short caption — is also the layout that converts best. Caption overlays and device frames are explicitly allowed; fabricated UI is what gets flagged.
Guideline 2.3.1 — showing features that don't exist #
If a screenshot demonstrates a feature the reviewer can't find in the submitted build, expect a rejection (and, for repeat offenses, worse). This often happens innocently: marketing screenshots made from a beta build with features that got cut.
Fix: audit each screenshot against the build you're actually submitting. Update captions that promise anything the current version doesn't do.
Guideline 2.3.8 — metadata isn't suitable for all audiences #
Screenshots and previews must be appropriate for a 4+ audience regardless of your app's age rating, because they're visible to anyone browsing. Violence, adult themes, or profanity that's fine inside a 17+ app is not fine on its product page.
Fix: choose tamer screens or crop/blur the problem content. Games with mature themes usually pass with atmosphere shots rather than explicit gameplay moments.
Guideline 2.3.10 — references to other platforms #
Screenshots showing Android device frames, Google Play badges, or "also on Android!" captions get rejected. This bites teams that reuse one marketing image set across both stores.
Fix: keep per-store assets separate. If you maintain both listings, a tool that manages App Store and Google Play sets side by side makes it hard to mix them up.
Guideline 5.2 / 2.3.7 — someone else's intellectual property #
Third-party logos, celebrity photos, competitor app names, trademarked characters, or another developer's product shots in your screenshots invite both a rejection and, potentially, a dispute.
Fix: show only content you have rights to. Replace real third-party content visible in your UI (album art, videos, brand feeds) with licensed or generic stand-ins before capturing.
Placeholder and low-effort content #
"Lorem ipsum", "Test test", empty states with no data, or obviously broken layouts read as an unfinished app. Reviewers judge the whole submission's care level partly from the screenshots.
Fix: capture with realistic demo data — full lists, plausible names, believable numbers. (Realistic, not real: never ship actual user data in a screenshot.)
Stale claims: prices, promotions, rankings #
"50% off this week", "#1 Productivity App", or a price printed in a caption becomes inaccurate the moment things change — and reviewers know it. Time-limited claims are explicitly discouraged for previews and risky in screenshots.
Fix: keep captions about what the app does. Put promotions in promotional text (which you can edit any time without review).
Getting Back to Approved, Fast #
A screenshot rejection doesn't require a new build:
- Read the Resolution Center message carefully — it names the guideline and usually attaches the offending screenshot.
- Replace the flagged images in App Store Connect on the same version. Media and metadata edits on a rejected version don't need a new binary.
- Reply in Resolution Center noting what you changed, and resubmit. Metadata-only re-reviews are typically fast.
- If you believe the rejection is wrong, you can appeal — but for screenshots, replacing the asset is almost always faster than arguing.
One process note that surprises people: outside of a rejection, screenshots can only be changed by submitting a new app version. If your set violates a guideline that reviewers start enforcing harder, it can block an otherwise trivial bug-fix release — one more reason to get the set right once.
The Pre-Submission Checklist #
Run this before every submission with new screenshots:
- Exact pixel dimensions for every slot — validate them here
- Every screenshot shows real, current app UI (2.3.3)
- Nothing shown that the build can't do (2.3.1)
- Content suitable for 4+ (2.3.8)
- No Android/other-platform frames, badges, or mentions (2.3.10)
- No third-party trademarks, logos, or people without rights (5.2)
- Realistic demo data, no placeholders
- No prices, discounts, or ranking claims baked into images
- All required device sizes covered, including Watch/Vision Pro if you ship there
- For preview videos, check the separate video spec
The official texts live in Apple's App Review Guidelines, section 2.3 and the screenshot specifications.
Make the Whole Category of Rejection Impossible #
Half of this list — dimensions, coverage, per-locale consistency — is mechanical, and mechanical problems are what tooling is for. Screenshot Studio captures your real UI in current device frames (2.3.3-friendly by construction), exports every required size exactly (no dimension rejections), keeps localized sets in sync, and uploads to App Store Connect with every file in the right slot.
The judgment calls — what to show, what to claim — stay yours. The rejections that come from file mechanics don't have to.
Download Screenshot Studio for free and submit your next update without holding your breath.