App Store screenshot sizes: every accepted pixel dimension
Apple accepts exact pixel dimensions, not ranges. A screenshot is either the right size or it is refused at upload. There is no "close enough" on the App Store side.
For a modern iPhone-and-iPad app, two sets do all the work:
- iPhone 6.9"/6.7":
1320 × 2868or1290 × 2796 - iPad 13"/12.9":
2064 × 2752or2048 × 2732
Everything else is either optional, legacy, or a different platform.
The sizes that matter today
These are the classes AppSubmit generates and pushes, with the App Store Connect API display type each set uploads into. Portrait is listed; landscape is the same pair swapped.
| Display class | Accepted sizes (portrait) | API display type |
|---|---|---|
| iPhone 6.9" / 6.7" | 1320 × 2868, 1290 × 2796 | APP_IPHONE_67 |
| iPhone 6.5" | 1284 × 2778, 1242 × 2688 | APP_IPHONE_65 |
| iPad 12.9" / 13" | 2048 × 2732, 2064 × 2752 | APP_IPAD_PRO_3GEN_129 |
Both sizes in a row are equally valid. You do not need one of each, pick one and be consistent across the set, because a set that mixes 1320 × 2868 and 1290 × 2796 will render at slightly different scales in the carousel.
The 6.9" enum trap
There is no APP_IPHONE_69 display type. Apple shipped the 6.9" devices and the 6.9" pixel sizes, but never added a matching screenshot set to the API, checked against the live API in July 2026 and still absent.
So 1320 × 2868 uploads into the APP_IPHONE_67 set, alongside 1290 × 2796. If you write your own uploader and create two sets for what you think are two device classes, the second one overwrites the first's contents. One set, both sizes.
Every other Apple display class
Apple still accepts sets for older and non-iPhone hardware. You almost certainly do not need most of these, but if App Store Connect is asking for one, this is the size it wants.
| Display class | Accepted sizes (portrait) |
|---|---|
| iPhone 5.5" (8 Plus) | 1242 × 2208 |
| iPhone 4.7" (8, SE 2/3) | 750 × 1334 |
| iPhone 4" (SE 1st gen) | 640 × 1096, 640 × 1136 |
| iPad Pro 11" (3rd gen) | 1668 × 2388, 1640 × 2360 |
| iPad 10.5" | 1668 × 2224 |
| iPad 9.7" | 1536 × 2048 |
| Apple Watch Ultra (49mm) | 410 × 502 |
| Apple Watch 45mm | 396 × 484 |
| Apple Watch 44mm | 368 × 448 |
| Apple Watch 42mm | 312 × 390 |
| Apple TV | 1920 × 1080, 3840 × 2160 (landscape) |
| Apple Vision Pro | 3840 × 2160 |
| Mac | 1280 × 800, 1440 × 900, 2560 × 1600, 2880 × 1800 |
The app icon is not a screenshot and does not live in a screenshot set: it is 1024 × 1024, PNG, no alpha channel, no rounded corners. Apple applies the mask itself.
Which sets you actually have to upload
You need at least one iPhone set to ship an iPhone app, and an iPad set if the binary declares iPad support. Apple scales your largest uploaded set down for devices that have no set of their own, which is why nobody renders 4.7" screenshots any more.
Practical rule: render 6.9"/6.7" for iPhone, 13"/12.9" for iPad, stop. Add 6.5" only if you want direct control over how the set looks on those devices rather than letting Apple resample.
Orientation
Both iPhone classes and the iPad class accept either orientation. The accepted pair is just swapped: a landscape iPhone 6.9" screenshot is 2868 × 1320, a landscape iPad 13" one is 2752 × 2064.
What you cannot do is mix orientations inside one set. A carousel with three portrait shots and two landscape ones lays out badly on every device, and reviewers see it exactly as shoppers do.
If your app is landscape-only, upload the whole set landscape. Apple has no separate landscape display type. It is the same set, rotated dimensions.
Format, count and file size
| Constraint | Value |
|---|---|
| Formats | PNG or JPEG |
| Colour | RGB, flattened, no alpha channel |
| Screenshots per display class, per language | Up to 10 |
| Minimum to publish | 1 per required class |
| Per-file byte cap | Not published alongside the dimension specs, we have not found an official number |
Transparency is the one that bites silently. A PNG with an alpha channel can upload and then render with a black or white box where you expected the background, so flatten before you export.
When your source image is the wrong size
Nearly every screenshot problem is the same problem: you captured on the device you own, and it is not one of the sizes above.
Three ways out, in order of quality:
- Re-capture at the target size. The iOS Simulator gives you any device you like, and a simulator capture at 1320 × 2868 is a genuine, sharp, exact-size screenshot.
- Scale, if the shape is close. A 1179 × 2556 capture from a 6.3" iPhone is within a fraction of a percent of the 6.9" aspect ratio, so a proportional resize with a centred crop loses a sliver of edge and nothing else.
- Scale and pad. A 1242 × 2208 capture is a different shape entirely, 22% off. Fit it inside the target and fill the remainder with a background colour.
What you never do is stretch. A distorted screenshot looks amateur, and misrepresenting what the app looks like is itself grounds for a metadata rejection under guideline 2.3, a resize that squashes the UI is a worse outcome than a padded one that does not.
AppSubmit renders every slot from one source and refuses to stretch, exact size passes through untouched, near-misses get a proportional resize, and anything further off gets padded with the image's own dominant colour. You can do the same by hand with the table above and any image editor; the rule that matters is proportional or nothing.