Store asset review
App-store screenshots: source integrity, localization, and manual review
A screenshot validator can check a selected file’s dimensions, format, and some local consistency rules. It cannot prove that the screen represents the shipped app, that claims are accurate, or that a store will approve the presentation.
On this page
Use the store’s own current specification as the source of truth
Storefront screenshot slots, device classes, localization options, metadata policies, and review standards change. A validator should point back to the relevant official documentation and identify which checks are machine-readable versus manual. A remembered pixel size is not an enduring rule.
Capture or export from the appropriate build and keep the source images. A technically matching canvas cannot make an outdated feature, unavailable language, prototype screen, or misleading claim acceptable.
Worked example: matching pixels, mismatching product story
A set of six images can all match a selected device canvas and file format while one contains text in a language the app does not currently support. The validator can report the canvas; a human must compare the screenshot, localized metadata, and shipped build.
Likewise, a screenshot can show a feature behind a test account, a future roadmap screen, or a manually composited label. Source integrity means keeping a clear relationship between the submitted asset and what users can actually obtain.
| Layer | Machine-checkable example | Manual review example |
|---|---|---|
| File | Pixel canvas, format, and byte facts. | Legibility at actual storefront scale. |
| Product | Optional source naming or batch consistency. | Screen reflects current user experience. |
| Localization | Selected language files are present. | Translated copy is accurate and appropriate. |
| Store decision | None beyond disclosed technical checks. | Policy, rights, metadata, and final reviewer judgment. |
Keep localization review separate from translation automation
Text baked into a screenshot needs the same product review as text in a store listing. It can be clipped, culturally confusing, stale, or inconsistent with the app even when the words are grammatically correct. Check each locale at its actual visual scale.
Do not use a validator to claim a localization is approved. It can support a checklist; product owners, translators, and the storefront’s reviewer make different kinds of decisions.
A technical result should lead to a manual checklist
After the local file check, review source build, device context, visible account data, claims, pricing references, language, rights, accessibility, and current official policy. Record uncertainties and correct them before upload rather than hoping the store feedback will teach the rule.
The store controls final publication. A transparent validator helps prevent obvious file mistakes without disguising that boundary.
Primary workflow evidence
Reproducible check behind this guide
Select the device family and compare each local image's decoded pixels, bytes and format with the active rule set.
Expected review: The synthetic fixture matches the selected width and height; format and byte checks must also pass. For a real submission, review genuine UI content, localization, and the current destination rules.
Boundary: The validator cannot certify store review, device authenticity, localization quality, rights or future Apple requirements.
Tested 2026-09-01. Deterministic release regression; cross-browser compatibility is not asserted.Use a local tool