App Store screenshot guidelines: why screenshots get rejected

Two entirely different failure modes wear the same word. One is caught by a file checker at upload, the other by a reviewer, and the fix for each has nothing to do with the other.

Published: 29 August 2026 · Last reviewed: 1 November 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 also invisible: a PNG whose every pixel is opaque can still carry the channel, and Simulator screenshots do, in every case we checked. On macOS you can check without installing anything:

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

You want the exact dimensions of an accepted slot and hasAlpha: no. Run it over the whole folder before you upload anything. The sizes, and the one-line conversion to JPEG, are in App Store screenshot resolution and in the App Store screenshot sizes guide; the screenshot size calculator maps a device to its slot.

Editorial failures

These come back from App Review with a guideline number attached. We re-read the numbers below in Apple's App Store Review Guidelines on 1 November 2026; they shift between revisions, so check the current text before you rely on one. The three rows in the table above (2.3, 2.3.3, 2.3.10) are not repeated here:

The one that catches most first submissions

Showing the app in use, which is guideline 2.3.3. A beautiful title card as the first screenshot, or a login screen, breaks it 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 in guideline 3.1.5, and screenshots can surface them:

• Virtual currency storage is restricted to developers enrolled as an organization, 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.

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 device size, 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. A composed wallet screen is a prop, never proof of a balance, so keep it away from any caption that implies a return.

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 or an alpha channel) or editorially in review.

What is a common editorial rejection?

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

Can an App Store screenshot have transparency?

No. Apple's rule is that images can't include alpha channels or transparencies. A PNG can carry an alpha channel even when every pixel is opaque, and Simulator screenshots do, so check with sips and convert to JPEG if hasAlpha says yes.

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

Both are allowed: Apple lists .jpeg, .jpg and .png. The format is not what usually fails; the pixel size and the alpha channel are more likely to.

What are the App Store screenshot requirements?

Files must be .jpeg, .jpg or .png, with at least one and up to ten screenshots per device size, at an exact accepted pixel size and with no alpha channel. Apple requires the 6.3-inch iPhone class (Dynamic Island, medium display) and, if the app supports iPadOS, the 13-inch iPad class. Every screenshot must also follow the App Store Review Guidelines.

Can I use a mockup in App Store screenshots?

What counts is that the screen exists in your build and shows the app in use: guideline 2.3 asks that screenshots accurately reflect the app's core experience, and 2.3.3 wants the app in use rather than title art. A mockup of a feature the build lacks, or of another brand's app, risks rejection, and 5.2.1 bars protected third-party material without permission. For wallet apps specifically, see App Store screenshots for a crypto wallet app.

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.