App Store Screenshot Compliance Check: Matching Sizes Across Seven Stores Before You Upload

A set of portrait screenshots that passes in App Store Connect gets a "size does not meet requirements" error in the Huawei or Xiaomi console. This is very common. The seven stores (Apple, Google Play, Huawei, Xiaomi, OPPO, vivo and Honor) don't agree on pixels, aspect ratio, file format or size limits, while designs are usually exported for "one main device".

For overseas developers: in mainland China, Android apps are distributed mainly through phone makers' own app stores such as Huawei AppGallery, Xiaomi, OPPO, vivo and Honor, each with its own asset rules.

This article covers how to use this site's app store screenshot compliance check to match your files against the rules one by one before publishing, rather than copying yet another size table. For pixel summaries, see the screenshot size reference and China app store screenshot sizes.

First, understand what the tool checks

The compliance check reads images locally in your browser: width and height, aspect ratio, whether there's a transparency channel, extension/encoding, and whether the file size exceeds the limit. Images are not uploaded to a server. After you select the target stores (multiple allowed), the tool matches against each store's currently recorded specs; failures come with a reason, such as "pixels not in the accepted list", "PNG has alpha" or "exceeds file size limit".

It answers "can this file go into this slot in this console?". Whether copy is exaggerated, the interface shows the app in use, or the frame shows the wrong device still needs a separate review against the guidelines. For frames, see adding device frames to store screenshots without breaking the rules.

Recommended workflow: choose slots, export, then check

1. Decide which stores and device slots you're publishing to. If you're only publishing to Chinese Android stores, you don't need all of Apple's 6.9-inch tiers first; if you're going to the App Store, open Apple's screenshot specifications and confirm which sizes are currently required (the documentation changes as devices are released; go by the App Store Connect page and the spec page).
2. Lay out and export at target pixels in the screenshot editor at /preview. Each exported file should ideally serve one pixel size; forcing 1320×2868 down to 1290×2796 easily produces blurry half-pixel edges.
3. Open the compliance check, select the relevant stores and drag in your exported files. You can check several at once. Review the pass/fail list for each image and note the failing stores and reasons.
4. Fix only what failed. Wrong pixels: go back to the editor and re-export at that size. Too large: lower JPEG quality first or shrink unnecessary decoration. Apple explicitly requires that screenshots contain no alpha, so remove transparent backgrounds and fill with a solid color.
5. Run the check again, and only upload to the consoles once everything is green. Console recompression and local previews may still differ in color, but size and format rejections will drop a lot.

Common pitfalls when comparing all seven

Apple: the accepted list is "a set of exact pixel sizes", not "close enough". Common portrait sizes include 1320×2868, 1290×2796 and 1260×2736; go by the official spec. Formats are JPEG/JPG/PNG, without transparency. In App Store Connect, each display size slot is uploaded separately; passing the check only means the file matches a pixel size, it doesn't pick the right "6.9-inch / 6.3-inch" slot for you.

Google Play: phone screenshots typically need to fall within a 16:9-style portrait range, with limits on the minimum side and file size; there may also be extra slots for tablets, Chrome OS and so on. The Feature Graphic follows a separate 1024×500 rule; don't check it alongside phone screenshots. See the Google Play Feature Graphic guide. Official reference: Add preview assets to showcase your app.

Huawei / Xiaomi / OPPO / vivo / Honor: Chinese channels commonly use fixed pixel sizes or narrow ranges plus a file size limit, mostly portrait. If the same design passes on Xiaomi but errors on OPPO, it's usually off by a few dozen pixels or right at the size limit. Don't assume "one 1080×1920 image works for all Android"; some channels already require higher resolutions or specific ratios. Go by each developer platform's current documentation, and recheck by selecting that store in the compliance tool.

How to read the results

• All pass: you can upload. It's still worth previewing on a real device whether the first screenshot on the store page "gets the selling point across within three seconds".
• Size mismatch: go back to /preview and re-export with that store's template or a custom width and height; don't rely on the system's "scale to fill".
• Format / transparency: export as JPEG without alpha, or remove transparency from the PNG and add a brand-color background.
• Over size limit: first remove unnecessary layers and large noisy gradients, then lower quality; compliance comes before lossless perfectionism.
• Passes one store, fails another: keep the passing file, export a separate version for the failing store, and add a store suffix to the file name to avoid overwriting.

When you need to check manually, open the screenshot size reference next to the checker: the left confirms "what the target pixels are", the right confirms "whether my file has those numbers".

How it divides work with the editor and directory

The compliance check answers "can I submit this?", the editor answers "does it look good once submitted?". Doing both before submitting beats guessing from a rejection email "which pixel was actually wrong".

Scheduling when publishing to several stores at once

A common indie developer approach: first produce one visual master set (headline copy, main colors and interface assets fixed), then split exports per store. Build the master in /preview at the highest commonly used resolution (for Apple, start with 1320×2868), then step down to each Chinese Android channel's required size and rearrange the safe areas. After downsampling, text may look small, so enlarge headlines separately at the lower-resolution sizes rather than just scaling layers.

Suggested schedule:

1. Finalize the master and self-check the copy (no competitor names, no fake ratings).
2. Select "the stores you're submitting to this week" in the checker and export only the sizes those stores need.
3. Run the compliance check again before each store upload, so you don't forget to re-export an image after a revision.
4. If one channel rejects you, change only that channel's set; don't replace sets that already passed without reason, to avoid triggering unnecessary re-review.

If you maintain both iOS and Chinese Android, organize folders as store/device/number, and keep the checker's report (or your own table) in a CHECK.md in the same folder, so next time you change a seasonal theme you know which files must be re-exported.

Cases where you can still be rejected after passing

Size and format are only the entry bar. The issues below won't be flagged red by the checker, but can still cause problems in review or operational checks:

• The screenshot isn't "the app in use" but a pure marketing poster, splash screen, or web screenshot passed off as the client.
• It shows unreleased features or UI that doesn't match the binary.
• It contains misleading claims like "official" or "No. 1", or fake system notifications.
• The device frame implies a model that doesn't match the upload slot (see the frames article).
• Some Chinese channels have separate page requirements for "displaying contact details and qualifications". These are unrelated to screenshot slots but are often asked about together with screenshots on the submission checklist.

So the compliance check is the mechanical gate before review; whether the content is truthful still needs a look from your own product and marketing side.

Specs change. Go by Apple's screenshot specifications, Google Play's preview assets guidance and each Chinese developer platform's current documentation. This site's tool rules are updated along with the docs; before checking, you can confirm on the size reference page that the numbers are still what you remember.