App Store screenshot guidelines: why screenshots get rejected

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: 29 August 2026 · Last reviewed: 12 October 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.

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:

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 PNG or JPEG (never HEIC or WebP), at the exact pixel size, in RGB, with no alpha channel, even an unused one: verified, not assumed.
2. One to ten screenshots per set, the required 6.3-inch set first.
3. First screenshot shows the app doing its job, not a splash or a login.
4. Nothing depicted that the submitted build cannot do.
5. No third-party logos or characters you do not have rights to.
6. No other-platform devices, frames or store badges.
7. No placeholder strings anywhere in the set.
8. Everything on screen suitable for a 4+ audience.
9. 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 opens on your phone and you screenshot it there, at the phone's native resolution (1179 × 2556 on an iPhone 14 Pro, a size on Apple's list), which takes the size question off this page. The sips check above settles the rest.

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.

Questions

Why do App Store screenshots get rejected?

For two separate reasons. Mechanically at upload (wrong pixel dimensions, an alpha channel, a non-RGB colour space) or editorially in review.

What is the most common editorial rejection?

An image that shows a splash or login screen rather than the app in use, or that shows something the build does not actually do.

Can an App Store screenshot have transparency?

No. Files must be RGB with no alpha channel and no transparency. An exported PNG that carries an alpha channel is refused even when its pixel size is correct.

Is JPEG allowed, or does it have to be PNG?

Both are allowed. The format is not what usually fails: the colour space, the alpha channel and the pixel size are.

Written by My Larp Wallet, a crypto wallet app simulator: a mockup that opens on your phone, never a real wallet. For your own app’s screenshots, shoot your build; where a wallet mockup fits, and where it does not.