← App Store Screenshot & Icon Checker

Why store uploads get rejected for images

Four problems account for most of it. None of them is a design judgement — every one is a mechanical property of the file, which is why every one can be caught before you upload rather than after. You can check your own assets against all four with the browser tool or the CLI.

1. The app icon declares transparency

This is the expensive one, because of when it fires. The icon is validated at upload time — after the build, after the archive, often after a CI pipeline that took twenty minutes — and the message you get back is about an alpha channel rather than about anything you can see on screen.

What is an alpha channel, and why does an icon have one by accident?

An alpha channel is a fourth value stored alongside red, green and blue that says how opaque each pixel is. Most design tools export PNG with one whether or not any pixel is actually transparent — the channel is a property of the file format, not of the artwork. So an icon that looks completely solid can still declare transparency, and the store checks the declaration. Exporting from a template with rounded corners is the other common source: the corners really are transparent, because the designer masked them, and the store was going to mask them anyway.

There is a second route that catches people who have already learned the first. A PNG with no alpha channel at all can still be transparent, via a tRNS chunk that nominates particular colours as see-through. Palette PNGs — the kind an "optimise for web" export step produces — use this routinely. A checker that only looks at the colour type misses it.

The fix: flatten the icon onto an opaque background and re-export. Exporting as JPEG also removes it, since JPEG has no alpha channel in any baseline form. Do not draw the rounded corners yourself; submit a full square and let the store mask it.

2. The screenshot set disagrees with itself

Why does a screenshot set need to be internally consistent?

Each screenshot set belongs to one display class, and every image in it is shown at the same size in the same carousel. Mixed sizes in one set is not a stylistic problem, it is a set that cannot be uploaded. It happens when part of a set is regenerated — a new simulator, a redesigned screen, one screenshot replaced after a bug fix — and the rest is left alone. Nothing about the individual files looks wrong, which is why it survives a visual check and fails at upload.

This is the check worth having most, and the one a specification cannot help you with: it is answered by comparing the files with each other. It is also the check that stays correct forever, because there is no published table involved that could go out of date.

3. The file is not the format its name claims

Why doesn't renaming a HEIC to .png work?

A file's format is determined by its contents, not its name. HEIC files begin with an ISO base media ftyp box; PNG files begin with an eight-byte signature. Renaming changes neither. Every tool that actually reads the file — including the store's upload validator — sees HEIC. The fix is to re-export or convert, which on macOS can be done in Preview with File → Export and a format of PNG.

Screenshots taken on a physical iPhone and pulled through Photos are the usual source on the Apple side; a WebP saved from a browser is the usual one on the Android side. Both are easy to rename and impossible to fix by renaming.

4. A size is simply wrong

The fixed sizes are the ones worth being certain about: a 1024×1024 App Store icon, a 512×512 Play icon, a 1024×500 Play feature graphic. Those have been stable for the life of both stores and a mismatch is unambiguous.

Screenshot sizes are different, and it is worth being clear about why. Apple publishes a list of display classes and adds to it with each hardware generation; Google publishes bounds (a minimum and maximum side length, and a maximum aspect ratio) rather than a list. A tool that hard-codes Apple's list will eventually flag a perfectly good screenshot from a device it has not heard of. That is why this tool reports an unrecognised size as a notice that names its own table as the suspect, and reserves hard failures for the things it can be certain about.

What this does not cover

Does passing these checks mean my app will be approved?

No. These are upload-time asset validations: they decide whether the listing images can be attached at all. App review is a separate, later, human process that judges the app itself — its functionality, its privacy declarations, its content, and whether the screenshots honestly represent what the app does. Passing every check in this tool only means the images are well-formed enough to be uploaded.