Pulled from Google Trends on 20 August 2026: for the seed "app store screenshots", the top related query is "app store screenshots sizes" at a relative value of 100. It is the whole question people bring to the topic, and the answer that circulates is usually a table of eight or ten dimensions with an implied instruction to produce all of them.
You do not need all of them. Apple's own screenshot specifications mark exactly two display sizes as required, and every other size in the list falls back to a scaled version of something you already uploaded.
The two that are required
| Device | Display size | Accepted portrait sizes | Status |
|---|---|---|---|
| iPhone | 6.9" | 1320 × 2868, 1290 × 2796, 1260 × 2736 | Required if the app runs on iPhone |
| iPad | 13" | 2064 × 2752, 2048 × 2732 | Required if the app runs on iPad |
That is the floor. Apple accepts more than one pixel size per display class — the 6.9" class takes three — so you can produce whichever of them your design tools emit most cleanly.
The 6.5" iPhone class carries a conditional requirement worth knowing: Apple requires it "if app runs on iPhone and screenshots for 6.9" display aren't provided". Upload the 6.9" set and that obligation disappears.
What happens to every other size
This is the part the size tables leave out. Each remaining display size, in both Apple's iPhone and iPad lists, carries the same kind of note: if you do not provide screenshots at an accepted size, Apple uses a scaled version from a specific larger class.
The chain is not "everything scales from the largest". It is a series of hops, and each hop is stated on Apple's page:
- iPhone — 6.3" and 6.1" both fall back to 6.5". 5.5" falls back to 6.1". 4.7" falls back to 5.5". 4" falls back to 4.7". 3.5" falls back to 4".
- iPad — 12.9" and 11" both fall back to 13". 10.5" falls back to 12.9". 9.7" falls back to 10.5".
So the practical answer to "which sizes do I need" is: one iPhone set at 6.9", one iPad set at 13" if you ship for iPad, and then look at whether any hop in that chain produces something you would be embarrassed by. Usually it does not, because these are proportional scales of the same artwork.
The case for uploading more than the minimum is not compliance. It is that a scaled 6.9" screenshot on a 4.7" phone renders your caption type smaller than you drew it, and captions are the part of a screenshot that has to survive being small.
The count, and where it actually matters
Apple accepts 1 to 10 screenshots per display size.
Ten is a ceiling, not a target. What matters is the first two or three, because those are what appear in the search result before anyone taps through to the product page — Apple states that "Your app's rating and up to three screenshots or app previews may display in search results depending on the platform and image orientation."
Two consequences follow from that one sentence. Screenshots four through ten are seen only by people who already opened your product page, which is a much smaller and much warmer audience. And whether you get one wide screenshot or three narrow ones in the search result depends on orientation, which is a design decision with a distribution consequence attached.
One thing the pixel table cannot tell you
Every number above is a specification. None of it says anything about what should be in the frame, and that is the part that decides installs.
Appstro's screenshot teardown exists for that half: it puts your screenshots beside the first screenshot of the ten apps ranking for a term you care about, at the size a person actually sees them. No model looks at the images — an automated verdict on creative it cannot see would be confident and worthless. It is a comparison surface, because the useful question is "does mine read faster than theirs", and only you can answer it.
Two findings from building it are worth carrying into your own work:
An empty screenshot list in Apple's API is a gap in the response, not in the listing. Apple will not publish a listing without screenshots, yet 11 of 33 sampled search results came back with empty arrays. Anything computing an average over those without excluding them is inventing a shortfall.
You cannot infer device or orientation from a screenshot URL. Apple's thumbnailer normalises every screenshot to the same dimensions — 392 × 696 for every app sampled. A tool claiming to tell you which device a competitor's screenshot targets is reading something that is not there.
What this cannot tell you
- Not what converts. Apple publishes pixel dimensions, not conversion data. The only place a screenshot change is measurable is a product page test, with the multiple-comparison problem that implies.
- Not how your set will look on every device. The fallback chain tells you what Apple substitutes; it does not tell you whether your caption is still legible after the substitution. Look at it.
- Not whether screenshots affect ranking. They are not among the four text-relevance inputs Apple names, and Apple documents no separate creative factor.
- Not a competitor's device targeting. See the thumbnailer note above.
The work
Produce one 6.9" iPhone set and, if you ship for iPad, one 13" set. Get the first three right and treat the rest as the product page's problem rather than the search result's. Then put yours next to the row you are competing in with the screenshot teardown, and check the caption still reads when it is thumbnail-sized.