Why app screenshots get rejected by the App Store

Two entirely different failure modes wear the same word. One is caught by a file checker in seconds, the other by a reviewer days later — and only one of them costs you a release.

Published: 27 August 2026

Two failure modes that share a word

"Rejected" covers two things that have nothing in common. The first is a file check inside App Store Connect: it happens in seconds, before any human is involved, and it is always about the bytes. The second is a review decision: it happens days later, involves a person, and is always about what the image claims. Treat them separately, because the fixes have nothing to do with each other.

Mechanical failures

These never reach a reviewer. They also never require a new build — the binary is fine, only the asset is wrong.

Symptom	Cause	Fix
Upload refused, wrong size	Dimensions off by any amount	Export at the exact pixel size for the slot
Upload refused, transparency	Alpha channel in the PNG	Flatten onto an opaque background, or export JPEG
Upload refused, colour	CMYK or an exotic profile	Export RGB
Format not accepted	HEIC, WebP, TIFF, PDF	PNG or JPEG only
Aspect ratio complaint	Padded or cropped to a near-miss	Rebuild at the target size, do not pad

The alpha channel is far and away the most common. It is also invisible: a PNG whose every pixel is opaque still carries the channel and still fails. On macOS you can check without installing anything:

sips -g pixelWidth -g pixelHeight -g space -g hasAlpha shot.png

You want the exact dimensions, space: RGB, and hasAlpha: no. Run it over the whole folder before you upload anything.

Editorial failures

These come back from App Review with a guideline number attached. Guideline numbering does shift between revisions of the App Store Review Guidelines, so read the current text rather than a cached number — including the ones below. The substance, though, has been stable for years:

Area	What it means for a screenshot
Accurate metadata (2.3)	Screenshots must show the app in use — not title art, not a login screen, not a splash screen
Undisclosed features (2.3.1)	Nothing on screen that the submitted build does not do
Age rating (2.3.8)	Metadata, screenshots included, must suit a 4+ rating even for a higher-rated app
Other platforms (2.3.10)	No Android frames, no other-store badges, no rival platform imagery
App completeness (2.1)	Placeholder text, lorem ipsum or obvious test data in a screenshot reads as unfinished
Intellectual property (5.2.1)	Third-party logos, brands and characters you have no right to use
Purchases (3.1)	Prices or offers depicted that do not match what the app actually sells

The one that catches most first submissions

Showing the app in use. A beautiful title card as the first screenshot, or a login screen, is a rejection even though it is the most designed asset in the set. The first image has to show the product doing its job — which is precisely why teams with an empty database end up needing a populated screen before they can submit at all.

Crypto-specific traps

Wallet and exchange apps have extra rules, and screenshots are frequently what surfaces them:

• Virtual currency storage is restricted to developers enrolled as an organisation, not individuals — a screenshot that shows custody makes the app's category obvious.
• On-device mining is not permitted; processing must happen off device, so do not depict a mining dashboard you cannot ship.
• Token offerings and exchange functionality carry their own eligibility requirements tied to who the developer is.
• Anything that reads as a promise of returns — a large green percentage, a yield figure, a projection — invites scrutiny you do not want on a first submission.

Verify each of these against the current guidelines before you build the assets: this is an area Apple has revised repeatedly.

What a metadata rejection costs

Less than people fear, and that is worth knowing before you panic. A rejection that concerns only metadata is resolved by replacing the metadata: no new build, no new binary, no re-uploading the app. You fix the screenshot, resubmit for review, and wait for another review pass. It costs a review cycle, not a release engineering cycle.

What it does cost is calendar time next to a launch date, which is why the check below is worth ten minutes. It also costs more the second time: a set that comes back twice for related reasons reads as carelessness, and the third pass tends to attract attention on parts of the listing nobody had questioned.

If the resolution genuinely turns on a judgement call rather than a fact — whether a depicted feature counts as shipped, whether an image is age-suitable — there is a review-resolution channel for arguing it in App Store Connect. Use it for disagreements, not for the mechanical failures above, which are simply true.

A pass before you submit

1. Every file at the exact pixel size, RGB, no alpha — verified, not assumed.
2. First screenshot shows the app doing its job, not a splash or a login.
3. Nothing depicted that the submitted build cannot do.
4. No third-party logos or characters you do not have rights to.
5. No other-platform devices, frames or store badges.
6. No placeholder strings anywhere in the set.
7. Everything on screen suitable for a 4+ audience.
8. No price, offer or performance figure that is not true of the app.

Where the demo data comes from

Two of those items — showing the app in use, and no placeholder strings — assume you have something to show. If your database is empty, that is a content problem before it is a review problem, and it is worth solving deliberately: see shipping screenshots before you have users for the three routes and their trade-offs. For a wallet screen specifically, My Larp Wallet renders one at 1179 × 2556 with no alpha channel, which removes the mechanical half of this page before it starts.

Whichever route you pick, the depicted state has to stay inside what the build actually does. That single constraint is what keeps a populated demo screen on the right side of guideline 2.3 — and it is also the difference between a screenshot that survives review and one that survives review but then disappoints every person who installs the app expecting what they saw.