Direct answer
Screenshot size planning is a coverage problem before it is a design problem: decide which device classes the listing must serve, produce masters at the largest required resolution per class, and derive the rest β instead of exporting every size by hand every time copy changes. For the App Store, the practical anchors are the large iPhone size (6.9-inch class, 1320 Γ 2868 portrait) and, if the app runs on iPad, the 13-inch iPad Pro class (2064 Γ 2752); Apple can scale these down for smaller devices in the same class. Google Play accepts more flexible dimensions (minimum 320 px, maximum 3840 px, and neither side more than twice the other) but rewards consistent framing. Because Apple adjusts accepted sizes as hardware ships, verify the current list in App Store Connect before finalizing masters. The expensive mistake is not a wrong pixel count β upload validation catches that β it is discovering at submission time that a locale, device class, or store was never planned for.
Coverage matrix before pixels
| Surface | Anchor size to master | Derived coverage |
|---|---|---|
| iPhone | 6.9-inch class, 1320 Γ 2868 portrait | Smaller iPhone classes scale from the master |
| iPad (if supported) | 13-inch class, 2064 Γ 2752 | Smaller iPad classes scale from the master |
| Google Play phone | 1080 Γ 1920 or taller within limits | Tablet and Chromebook variants as needed |
| Per locale | Same masters, localized text layers | Every locale the listing ships in |
Multiply device classes by locales by stores: a bilingual iPhone + iPad app on both stores is already dozens of final images from just a handful of masters. That multiplication is why masters and derivation matter.
Recommended flow
1. List required device classes from actual support
If the app does not ship an iPad build, iPad screenshots are not optional polish β they are simply not part of the matrix. Coverage starts from the binary, not ambition.
2. Design masters at the largest size per class
Text set for the large-phone canvas stays readable when scaled down. The reverse β upscaling a small master β produces soft text that fails visual QA.
3. Keep text as a separate layer from the product frame
Localization changes the text, not the product shot. Separating layers means a locale swap is a text pass, not a redesign, and overflow checks can focus on the layer that actually changes.
4. Verify current store requirements before export
Apple updates accepted sizes as new devices ship, and Play policies evolve. A five-minute check in App Store Connect and the Play Console before final export is cheaper than a rejected batch.
5. Validate the full matrix before submission day
Every cell β device class Γ locale Γ store β should have its images named, sized, and reviewed before the submission window opens. Missing cells found on submission day become launch delays.
Common failure modes
Masters designed at the smallest size
Scaling up softens text and edges. Always design at the largest size in the class and scale down.
Localized screenshots as an afterthought
When text is baked into flattened images, every locale becomes a redesign. Teams then quietly ship English screenshots in non-English storefronts, weakening conversion precisely where the listing is least established.
The matrix lives in someone's head
If coverage exists only as a designer's memory, staff changes and rush releases surface the gaps. The matrix should be a written artifact reviewed at each release.
Screenshot size checklist
- Device classes derived from what the binary actually supports.
- Masters designed at the largest size per class, portrait and landscape as needed.
- Text layers separate from product frames for locale swaps.
- Current size requirements verified in App Store Connect and Play Console.
- Full matrix (class Γ locale Γ store) validated before submission day.
- Exported files named so a reviewer can audit coverage at a glance.
Operating rule
If you cannot produce the coverage matrix as a table β every device class, every locale, every store, with a status per cell β screenshot production is running on hope.
Why this matters in App Store Helper
App Store Helper treats screenshot sets as structured project assets: the screenshot recipe defines message and sequence once, and per-locale variants stay linked to it rather than scattering across design files. Coverage gaps show up as visible empty slots during review, not as surprises on submission day.