Check App Store screenshots before you upload them

A folder check before upload finds every file problem in a screenshot set at once, offline, and can run in CI before anything reaches App Store Connect.

I built screenproof for this. Before publishing it, I ran it on screenshots from apps that were already live. The first two came back clean. The third, VaultSnap, came back with 16 findings, and those findings shaped how its rules work.

#1. Lay the folder out the way your upload tool reads it

screenproof reads a fastlane deliver screenshots tree: one folder per locale, images and app previews inside. Fix the layout first. An empty locale folder or a typo in a locale name (en_US where your tool expects en-US) is a finding on its own.

#2. Run the check

npx screenproof fastlane/screenshots

It needs Node 24 or later and has no runtime dependencies. It checks:

• exact pixel sizes against Apple's current specification table, with the nearest valid size suggested for every rejected image;
• PNG and JPEG headers, and PNG transparency (an alpha channel or a tRNS chunk);
• the device class each image belongs to, including the sizes Apple shares between iPad 12.9" and 13", and between Apple TV and Vision Pro;
• per-locale counts over the limit, Apple Watch size consistency, empty locale folders and stray files;
• app previews: container structure, H.264 or ProRes 422 HQ, the 500 MB ceiling and the 15 to 30 second duration window.

It exits non-zero when the check fails, so it can gate a CI job. Add --strict to fail on warnings as well.

#3. Read errors and warnings differently

An error breaks a rule Apple publishes for the files themselves. A warning is something worth cleaning up that the rules do not forbid. Decide which of the two blocks your release, and keep the distinction.

The live-app run showed why. My VaultSnap folder, live since March, produced two kinds of finding:

• Eight PNG screenshots with an alpha channel. Apple's specification says screenshots must not contain alpha channels or transparency, yet Apple had accepted these eight and was serving them on the store. So in July screenproof shipped transparency as a warning: calling it a guaranteed upload failure would have been false. Since screenproof 0.7.0 (September 12, 2026) it is an error by default, matching Apple's published rule. If you have your own evidence, you can set "screenshot-png-alpha": "warning" in a screenproof.json config.
• Eight HTML mockup files left beside the images after I built the screenshots. Apple never saw them, but they had no business in an upload folder. Stray files are warnings.

So flatten transparency before you upload, remove stray files, and do not read an accepted listing as proof that a rule does not apply.

#4. Check one image in the browser

For a single screenshot, or a whole listing pack with its text, the App Store Submission Pack Checker runs source-linked App Store Connect rules in your browser. Your images and text stay on your device.

#5. Check the text too

Screenshots are half of the listing. The other half is the metadata: field lengths per locale, the keyword budget, wasted separators and duplicates. metaproof lints a fastlane metadata folder the same way, offline and with zero dependencies.

#What a clean run does not prove

A clean folder means the files meet the published rules. It does not mean the screenshots are accurate, readable or allowed under App Review's content rules. A screenshot that shows UI your app does not have can still get an update rejected, and no file check can see that. Look at every image yourself before you submit.