Why was your App Store screenshot rejected?
Published
Short answer
Two different systems reject App Store screenshots, and they fail for opposite reasons. App Store Connect refuses the upload itself — before any person looks at it — when a file has the wrong pixel dimensions, carries an alpha channel, uses an unsupported format, or the set has the wrong count1 (source 1); these checks are automatic and instant. App Review rejects the listing afterward, once a human has looked at what the screenshot shows: content that misrepresents the app, features that do not exist, another platform’s device frame, or placeholder and debug material2 (source 2). The fix depends entirely on which one happened to you.
Key points
- Two entirely different systems reject a screenshot: App Store Connect’s automated upload check, and a human App Reviewer looking at the listing afterward. Which one hit you determines the fix.
- Upload-time failures are mechanical and Apple lists them precisely: wrong pixel dimensions, an alpha channel or transparency, an unsupported file format, or the wrong screenshot count for a localisation1 (source 1).
- Content-level rejections cite a specific guideline number in the rejection message. Guideline 2.3.3 requires a screenshot to show the app in use, not title art, a login page, or a splash screen4 (source 4).
- Screenshots carrying another platform’s device frame or store branding violate Guideline 2.3.10, which asks metadata to stay focused on the Apple platform the app actually runs on6 (source 6).
- This page cannot tell you the exact line a reviewer flagged in your case — only the rejection message and the Resolution Center note in App Store Connect do that. Where causes below are ordered by likelihood, that order is judgement about what is commonly seen, not a measured rejection rate; Apple does not publish one.
The two failure types, and how to tell them apart
The two failures look nothing alike once you know what to check. A file-level failure happens the moment you try to attach the image in App Store Connect: the upload never completes, or the thumbnail shows an inline error naming the file. No human has seen the content yet — the check is purely mechanical.
A content-level rejection happens later. The screenshot uploaded fine, the whole submission went to App Review, and the rejection arrives afterward as an email or a Resolution Center message that names a specific guideline, usually somewhere in the 2.3 range, which covers accurate metadata2 (source 2).
- Failed instantly, no guideline number: treat it as a file-level cause, below.
- Failed after a full review, message cites “Guideline 2.3.x”: treat it as a content-level cause, below.
Diagnose by symptom
If the rejection message is vague, match what you actually saw against the table below. The ordering is a judgement call about what shows up most often, not a measured frequency — Apple does not publish rejection statistics.
| Symptom | Likely cause | Fix |
|---|---|---|
| Upload rejected instantly, error names the file | Pixel dimensions do not match an accepted size exactly1 (source 1) | Re-export at an accepted size; see the accepted size table. |
| PNG upload rejected with no dimension error | File carries an alpha channel or transparency1 (source 1) | Flatten onto an opaque background and confirm the export has no alpha channel. |
| Upload rejected, file type unrecognised | Format is not .png, .jpg, or .jpeg1 (source 1) | Convert to one of the three accepted formats. |
| Submission blocked at the localisation step | Fewer than one or more than ten screenshots supplied for that localisation1 (source 1) | Trim or pad the set to between one and ten images. |
| Rejected after full review, message cites Guideline 2.3.3 | A screenshot shows title art, a login page, or a splash screen instead of the app in use4 (source 4) | Replace it with a capture of a real screen mid-task. |
| Rejected after full review, message cites Guideline 2.3.10 | A screenshot shows another platform’s device frame or store badging6 (source 6) | Reshoot inside an Apple device frame and drop non-Apple iconography. |
| Rejected after full review, message cites Guideline 2.1 or mentions placeholder content | A screenshot shows lorem ipsum, a debug watermark, or an unfinished screen7 (source 7) | Replace with production content and re-shoot after removing debug overlays. |
File-level causes, and the exact fix for each
These four causes cover every automated upload rejection. Each has one specific fix — there is no partial credit and no automatic correction on Apple’s side.
- Wrong dimensions: App Store Connect checks the pixel dimensions against its accepted list and refuses anything that does not match exactly1 (source 1). There is no tolerance and no resize step — the exact pixel count decides pass or fail. See the accepted size table for every accepted value.
- Alpha channel: a PNG exported with a transparent or semi-transparent background is not accepted1 (source 1). Flatten the image onto an opaque background and confirm the export carries no alpha channel before re-uploading.
- Wrong format: only
.png,.jpg, and.jpegare accepted1 (source 1). A file straight off a device in another format needs converting first. - Wrong count: each localisation needs between one and ten screenshots1 (source 1). A batch process that drops zero images for an untranslated locale, or carries over an eleventh leftover file, fails the whole set for that language.
Content-level causes App Review actually flags
App Review Guidelines section 2.3 sets the standard for the whole listing: screenshots must accurately reflect the app’s core experience2 (source 2). The specific ways screenshots fail that standard are narrower than the standard itself.
- Misrepresenting the app: a screenshot showing a feature that is not in the shipped build falls under Apple’s rule against “marketing your app in a misleading way”3 (source 3). Repeated instances are treated as grounds for removal from the Developer Program3 (source 3).
- Screenshots that are not the app in use: title art, a login screen, or a splash screen in place of a real screen fails Guideline 2.3.3, which requires screenshots to “show the app in use”4 (source 4), not merely branding.
- Other platforms’ devices or icons: a screenshot built in an Android frame, or one carrying store badges from another marketplace, breaks Guideline 2.3.10, which says not to “include names, icons, or imagery of other mobile platforms”6 (source 6) in the app or its metadata.
- Placeholder or debug content: lorem ipsum text, a visible debug watermark, or a build banner reading “beta” signals an unfinished submission. Guideline 2.1 requires “placeholder text, empty websites, and other temporary content” to be scrubbed before submission7 (source 7), and Guideline 2.2 is explicit that “demos, betas, and trial versions” do not belong on the App Store8 (source 8).
- Pricing or promotional text baked into the image: a caption calling out a discount or a subscription price is metadata Apple does not want there. Guideline 2.3.7 says screenshots “should not include prices, terms, or descriptions that are not specific to the metadata type”5 (source 5).
What to do after a rejection
The two rejection types resume differently, so start by confirming which one happened before touching anything.
- For a file-level failure, fix the file and re-upload. No review queue is involved, so a corrected file attaches immediately.
- For a content-level rejection, read the specific guideline number in the message first; it names the exact screenshot and the exact rule.
- Replace only the flagged screenshot, not the whole set, unless more than one carries the same problem.
- Resubmit through the same version in App Store Connect. Screenshots do not require a new build or a version bump.
- If the reasoning looks wrong to you — a legitimate, shipped feature read as non-existent, for instance — reply in the Resolution Center with a clarifying note rather than resubmitting blind.
Avoiding the whole class next time
Most file-level rejections disappear once screenshots are produced at an accepted size with no transparency from the start, rather than caught after an upload fails. Shotluma exports at 1290 × 2796 and 1242 × 2688 with no alpha channel, which removes the wrong-dimensions and alpha-channel failure classes for the sizes it covers. It does not export iPad sizes, and it has no bearing on content-level rejections — those depend on what a screenshot shows, not how it is encoded.
For content-level causes, the only reliable check is a second read of the finished set immediately before submitting, against the specific rules above rather than a general impression of quality.
- Every screenshot is a capture of a real, shipped screen — no title art, no login page, no splash screen.
- No debug watermark, lorem ipsum, or “beta” label is visible anywhere in the set.
- No device frame, icon, or badge from a non-Apple platform appears.
- No overlay text states a price, discount, or term that lives outside the app itself.
Frequently asked questions
Can screenshots include text captions or callouts?
Yes. Guideline 2.3.3 allows “text and image overlays” specifically to demonstrate input mechanisms, such as an animated touch point4 (source 4). The line to watch is pricing or promotional text, which Guideline 2.3.7 rules out separately.
Does one content rejection hurt my developer account standing?
No, not on its own. Apple’s guidelines reserve account-level consequences for “egregious or repeated” dishonesty, not a single rejected screenshot3 (source 3). Fix the screenshot and resubmit.
Can I appeal a content-level rejection I think is wrong?
Yes. Reply in the Resolution Center attached to the submission with your reasoning before resubmitting a guess. A reviewer can misread a legitimate feature as non-existent, and a clarifying note is the direct way to correct that.
Do the content rules apply to optional, non-required screenshot sizes too?
Yes. Guideline 2.3 covers screenshots and previews as a category, with no carve-out for sizes beyond the required set2 (source 2). An optional 6.1-inch set showing placeholder content is exposed to the same rejection as a required 6.9-inch set.
My screenshot was rejected with no specific reason given — where do I start?
Start with the two checks that are fastest to rule out: pixel dimensions and an alpha channel1 (source 1). That order is a practical starting point, not a measured ranking — Apple does not publish which mechanical cause is most common, so re-verify the exact pixel size against your export before assuming anything more complicated is wrong.
Sources
- 1Screenshot specifications — App Store Connect Help — Apple Developer, iPhone and iPad display size tables; accepted formats and screenshot count. Read .
- 2App Review Guidelines — Apple Developer, Section 2.3, Accurate Metadata, introductory paragraph. Read .
- 3App Review Guidelines — Apple Developer, Guideline 2.3.1(a)–(b). Read .
- 4App Review Guidelines — Apple Developer, Guideline 2.3.3. Read .
- 5App Review Guidelines — Apple Developer, Guideline 2.3.7. Read .
- 6App Review Guidelines — Apple Developer, Guideline 2.3.10. Read .
- 7App Review Guidelines — Apple Developer, Guideline 2.1(a), App Completeness. Read .
- 8App Review Guidelines — Apple Developer, Guideline 2.2, Beta Testing. Read .