Why App Store screenshots get rejected, and how to tell which kind

A rejected screenshot can mean a bad file or a bad claim. Work out which one you have first, because only then does the fix make sense.

Published: 29 August 2026 · Last reviewed: 1 November 2026

First, find out which rejection you got

Ask two questions. Did the complaint come back within seconds of dropping the file into App Store Connect? Or did it arrive days afterwards, from a person, quoting a guideline number? The first is a file problem and is about bytes. The second is a review problem and is about what the picture says. They share the word “rejected” and nothing else, so do not mix their fixes.

Upload failures: the asset is wrong, the app is fine

No reviewer sees these files, and none of them needs a new build. There are three:

• Wrong pixel size. Export at one of the exact sizes accepted for the slot. The list sits in App Store screenshot resolution.
• An alpha channel. Apple writes that “Images can’t include alpha channels or transparencies.” Flatten the image onto an opaque background, or export JPEG. Simulator PNGs carry the channel.
• The wrong file type. Apple lists .jpeg, .jpg and .png.

Alpha is the sneaky one because you cannot see it. A PNG can hold the channel with every pixel fully opaque, and in every case we checked, Simulator screenshots do. Ask macOS directly:

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

The result you want is an accepted slot size and hasAlpha: no. Run it across the whole folder before uploading. For the size lists and the one-line JPEG conversion, go to App Store screenshot resolution or the App Store screenshot sizes guide; the screenshot size calculator turns a device into its slot.

Review rejections, grouped by what the image shows

These arrive from App Review with a guideline number. We re-read the numbers in Apple's App Store Review Guidelines on 1 November 2026, but they move between revisions, so check the live text before citing one.

The screen is not the app doing something

Guideline 2.3.3 wants the app in use, not merely the title art, login page or splash screen. This trips up more first submissions than anything else, because the most polished image in the set is often the title card, and it is exactly the one that breaks the rule. The opening screenshot has to show the product at work. That is also why a team with an empty database ends up needing a populated screen before it can submit at all.

The screen promises more than the build delivers

• 2.3: screenshots should accurately reflect the app's core experience. Show only what the submitted build does.
• 2.3.1: misleading marketing, meaning content or services the app does not offer, or a false price.
• 2.3.7: no prices, terms or descriptions that are not specific to the metadata type.
• 2.1: app completeness. Scrub placeholder text and other temporary content before you submit.

The screen shows something that is not yours to show

• 2.3.10: remove names, icons and imagery of other mobile platforms or alternative app marketplaces, unless there is specific, approved interactive functionality.
• 5.2.1: no protected third-party material, trademarks included, without permission.

The screen shows the wrong audience

• 2.3.8: metadata, screenshots included, must suit a 4+ rating even if the app itself is rated higher.

Crypto apps add their own tripwires

Guideline 3.1.5 covers wallets and exchanges, and a screenshot can expose a problem that the metadata would not:

• Storing virtual currency is limited to developers enrolled as an organization, not individuals. A screenshot of custody makes the category obvious.
• Mining on the device is not allowed; processing has to happen off device. Do not show a mining dashboard you cannot ship.
• Token offerings and exchange features come with eligibility requirements tied to who the developer is.
• A large green percentage, a yield figure or a projection reads as a promise of returns and attracts scrutiny you do not want on a first submission.

Apple has revised this area repeatedly, so check each point against the current guidelines before you produce the assets.

Pre-submission pass

1. PNG or JPEG only (no HEIC, no WebP), exact pixel size, RGB, no alpha channel. Verified with a command, not assumed.
2. Between one and ten per device size, with the required 6.3-inch set first.
3. Screenshot one shows the app doing its job, not a login or splash.
4. Nothing pictured that the submitted build cannot do.
5. No logos or characters you lack rights to, and no other-platform devices, frames or store badges.
6. No placeholder strings in any image.
7. Every frame fit for a 4+ audience.
8. No price, offer or performance number that is untrue of the app.

When you have nothing to photograph yet

Two checklist items, showing the app in use and leaving out placeholders, presuppose content. With an empty database that is a content problem before it becomes a review problem, and shipping screenshots before you have users weighs three ways of solving it. For a wallet screen, Flexdger Wallet opens in the browser on your phone and you take the screenshot there, at the phone's native resolution. On an iPhone 14 Pro that is 1179 × 2556, a size on Apple's list, so the size question disappears and the sips check covers 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.

Whatever route you choose, keep the depicted state inside what the build really does. That one constraint keeps a populated demo screen within guideline 2.3. It also separates a screenshot that passes review from one that passes and then lets down everyone who installs the app expecting what they saw.