← App Store Screenshot & Icon Checker
Most people check store assets by opening the spec page in one window and the asset folder in another. That genuinely works for the thing it is good at — dimensions — and misses four things it structurally cannot see. This page is about which is which, including where the manual approach is the better one.
| Problem | Spec sheet + file browser | This tool |
|---|---|---|
| Wrong pixel dimensions | Yes — this is what it is good at | Yes |
| Icon declares an alpha channel | No — not shown in Get Info or Properties | Yes, from the PNG colour type |
Icon transparent via a tRNS chunk | No | Yes |
HEIC or WebP renamed to .png | No — the name is what it reports | Yes, from magic bytes |
| Screenshot set disagreeing with itself | In principle, by comparing every file by eye, every release | Yes, automatically |
| Interlaced or 16-bit PNG | No | Yes |
| Whether the artwork is any good | Yes — you are looking at it | No. It never decodes a pixel |
| Whether a screenshot honestly shows the app | Yes | No |
The last two rows are the honest limit of any mechanical checker, and they are not small. Nothing here judges whether your screenshots are worth looking at or whether they represent the app fairly — which is what app review will actually be assessing.
You can, and for dimensions alone it works. What a file browser will not tell you is whether
a PNG declares an alpha channel — macOS Get Info and Windows Properties both show the pixel
size and the file size, neither shows the colour type — and that is the property behind the
most common upload rejection. It also will not tell you that a file named .png
is really a HEIC, because it reports what the name implies. And comparing ten files'
dimensions against each other by eye, on every release, is exactly the kind of task a person
does correctly nine times and then does not.
Because an alpha channel is invisible when every pixel in it is opaque. An icon can look completely solid against the editor's white canvas, export with a full alpha channel, and be rejected — the store reads the declaration in the file header, not the appearance of the pixels. The only way to see it by eye is to know where your editor hides the channel list, and to remember to look there during every release.
For generating assets, very possibly — resizing one screenshot into every display class, adding device frames and captions, and uploading the result is real work that dedicated tools do well, and this tool does none of it. This is a checker, not a generator. It reads assets you already have and tells you what would be refused. The two are complementary: a generator's output is exactly the kind of thing worth checking, since a bug in a resize pipeline produces a whole set of consistently wrong files.
Because the failure it prevents is a release-day failure, and release day is the worst time to be reading a spec sheet. A checked-in screenshot set drifts the same way any other checked-in artefact does — someone regenerates part of it, someone adds a locale, someone's export preset changes. Running the CLI on every pull request that touches the asset directory turns that drift into a failed build, at the point where it costs a minute instead of a release cycle.