Table of contents
- Quick nav
App Store Screenshot Compliance Checker: Size, Format & File-Size Preflight
You export a stack of portraits and push them into every console. The usual rework is off-by-a-few pixels, file size on the limit, or PNG with alpha. The multi-store scheduling narrative and how to read failure lists live in the existing seven-store compliance walkthrough. This article adds a preflight checklist plus verifiable rule highlights: open the checker, select stores, fix green/red—and state clearly what the tool does and does not verify.
For overseas readers: mainland China Android distribution often goes through OEM stores (Huawei, Xiaomi, OPPO, vivo, Honor) with their own asset rules alongside Apple and Google Play.
Tool: screenshot compliance check. It reads width/height, format, and bytes locally in the browser—no upload. Matches go green; mismatches go red with a reason. Shot count is not checked (store minimums differ; only each file you drop in is evaluated).
Preflight loop (about five minutes)
- Open /en/tools/screenshot-check and select the stores you will submit this week (multi-select: App Store, Google Play, Huawei, Xiaomi, OPPO, vivo, Honor).
- Drop exported files (batch OK). Landscape and portrait both count: if a rule is 1290×2796, both 1290×2796 and 2796×1290 pass size.
- Fix only red items: wrong pixels → re-export that slot in /en/preview; over size → run image compress first (common for OPPO “under 1MB”); alpha warning → flatten to opaque JPEG/PNG.
- Upload only when everything is green (or vivo size shows console wins and format is clean).
- Keep Feature Graphic separate from phone shots: Play’s banner accepts exactly 1024×500. Build it in /en/tools/feature-graphic, then recheck.
Spec highlights table (how the checker decides)
| Target | How the checker judges | How you fix |
|---|---|---|
| App Store phone slots | Exact pixel list; JPEG/JPG/PNG; no alpha | Re-export from size lookup; remove alpha |
| Google Play phone shots | Sides 320–3840, long side ≤ 2× short; recommended sizes also pass when exact | Fix composition if too tall/wide—do not stretch blindly |
| Google Play Feature Graphic | Only 1024×500 | Use the Feature Graphic maker or export at that size, then recheck |
| Huawei / Xiaomi / OPPO / Honor | Exact or narrow pixels + format; file-size caps parsed from notes (e.g. 5MB, 1MB) | OPPO “less than 1MB”: file must be strictly under (equal counts as over) |
| vivo | Size often “console wins” when official pages are not stable enough to pass/fail; format still checked as JPG/PNG | Follow the live console; keep common bitmap formats |
Notes: Huawei may apply different size caps for WEBP vs PNG/JPG; icon-only size notes are not used to fail screenshots. Spec data shares the same source and checked-at date as screenshot sizes; if the console disagrees, trust the console. China channel pixel summaries: China store screenshot sizes.
Decision contrast: preflight vs upload-first
| Approach | Typical cost |
|---|---|
| Upload first, fix after console errors | Repeat uploads across stores; hard to tell pixel vs size vs alpha; vivo messages stay vague |
| Local preflight to green, then upload | Fewer size/format/volume rejections; red reasons link straight to editor or compress |
| Read size tables only, skip the checker | Tables tell the target; they do not prove your file is that target |
The checker answers “can this file enter this slot?” Copy claims, “in-use” UI requirements, and misleading device frames still need separate review—those are outside the green/red pixel logic.
Alpha warnings and Play ranges
App Store and Play disallow screenshot alpha. When the checker detects an alpha channel in PNG, it warns; when it cannot detect, it says so—do not assume safety if you used background removal or an alpha export preset. Flatten on a brand fill in /en/preview, export, then recheck. Compress after flatten when you need OPPO-style size caps.
Play phone shots are not “1080×1920 only.” The checker uses the official range (320–3840, long ≤ 2× short). Recommended sizes pass when exact, but a very tall 1080×2400-class ratio can fail the aspect rule—crop or recompose instead of renaming. Feature Graphic never uses the range logic; it is exact 1024×500.
Wiring to sizes, compress, and Feature Graphic
- Which pixels a store accepts → /en/tools/screenshot-sizes or China sizes.
- Build at those pixels → /en/preview.
- File size on the line → /en/tools/compress, then drop back into the checker.
- Play Feature Graphic production → /en/tools/feature-graphic, then confirm 1024×500.
- Multi-store scheduling narrative → compliance walkthrough.
Printable preflight checklist
- Only this week’s stores selected (ignore unrelated red noise).
- Every file size-green, or vivo size is “console wins” and you already matched the console.
- No surprise alpha warnings; stores that forbid alpha are flattened.
- File size not red; “less than X” caps are strictly under.
- Feature Graphic is a separate file and a separate check—not mixed with phone portraits.
- You are not expecting the checker to validate shot count—count from each store’s docs.
Treat preflight as a release gate: tables set targets, the checker inspects the goods, editor/compress/Feature Graphic tools do rework. A local gate is cheaper than guessing pixels from a rejection email.
What “green” does not mean
Green means the file matches the recorded size/format/volume rules for the stores you selected. It does not approve marketing claims, prove the UI matches the binary, or pick the correct App Store Connect display-size slot for you. Passing 1320×2868 in the checker still requires uploading into the matching 6.9-inch (or current) slot in Connect.
Ready to design your store screenshots?
Try AppShotMaker and turn raw captures into store-ready screenshots in minutes.