There are two kinds of failure and they happen days apart. A validator error stops the upload immediately. A policy flag costs you a full review cycle. Here is both lists.
Verify against App Store Connect and Play Console before submitting
These fire the moment you drop the file in. None of them are judgement calls.
| Requirement | Detail | Store |
|---|---|---|
| Exact pixel dimensions | App Store Connect matches the declared slot exactly. A file one pixel off is rejected at upload. | Both |
| No alpha channel | PNGs must be flattened. This is the most common silent failure — the file looks correct locally. | Both |
| sRGB colour space | CMYK files and unusual embedded profiles are refused. Convert before exporting. | Apple |
| One orientation per family | A device family must be all portrait or all landscape. Mixing them is refused. | Apple |
| Minimum screenshot counts | Play will not publish with fewer than two phone screenshots, and wants a minimum of four each for tablet and Chromebook. Apple requires one 6.9" iPhone set, plus a 13" iPad set if the build supports iPad. | Both |
| Edge and ratio limits | 320 px minimum, 3840 px maximum, and no side more than twice the other. | |
| File size cap | 8 MB per screenshot on Play. Apple's practical ceiling is higher but large files slow uploads. | |
| Feature graphic present | A Play listing cannot publish without a 1024 × 500 banner. |
These pass every validator and are caught by a person, typically several days later.
Screenshots that show features not present in the build, or screens the reviewer cannot reach, are the single most common content rejection. If a feature is behind a flag, enable it for the review account and say so in the review notes.
Lorem text, "User Name", empty states dressed up as real data, and obviously fabricated numbers all read as an unfinished submission.
An App Store screenshot may not show an Android device shell, mention Google Play, or reference another store. The reverse applies on Play. If you generate both sets, use each store's own device shell.
Star ratings, award badges, press logos and "#1 in category" claims you cannot substantiate are policy problems. Real, current, attributable proof is fine and works well.
A "Free forever" headline over an app with a hard paywall on second launch will be rejected, and correctly. Match the headline to what a new user actually experiences.
Content in the screenshots has to sit within your declared age rating. A 4+ rating with a screenshot showing mature content fails on both stores.
Device frames showing hardware Apple no longer ships are flagged. This is the practical reason to stop reusing a mockup PSD from three years ago.
Ten lines. Run it before every submission, not just the first.
Correct pixel dimensions for every device family you declare.
Flattened RGB PNG or JPEG, with no transparency anywhere.
First two screenshots legible when scaled to roughly 150 px wide.
No placeholder, lorem, or fabricated content inside the framed screen.
Every feature shown is reachable in the build you submitted.
No competing platform, store, or device referenced anywhere in the set.
Every claim, price and rating verifiable and current.
Headlines localised for every storefront you publish to.
Portrait and landscape not mixed within a device family.
Feature graphic supplied for Google Play.
Separate the two cases. If it failed at upload, it is technical: wrong dimensions, an alpha channel, or an unsupported colour space. If it failed days later in review, it is content: a feature the reviewer could not reach, placeholder data, an unsupported claim, or a reference to another platform.
Yes. Metadata is reviewed alongside the binary, and misleading screenshots are grounds for rejection on their own. It is a common cause of a second review cycle on an otherwise finished app.
Yes, and they are expected — the store gallery is understood to be marketing material rather than raw captures. What is not allowed is text that misrepresents the app or references a competing platform.
The content principles are similar — do not mislead, do not reference the other platform, do not fake proof. The technical rules differ significantly: Apple validates exact pixel sizes, Play validates ratio and edge length and additionally requires a feature graphic.
Export at store dimensions instead of resizing by hand. Every file from the store export presets leaves at the exact target size, flattened to RGB with no alpha, which removes the three most common upload failures at once.