App Store Screenshots in 2026: Sizes, Specs & the Order That Converts
Your app store screenshots are the single most-tapped asset on your product page — most people decide to install (or scroll on) before they ever read a word of your description. This guide gives you the exact 2026 app store screenshot sizes for iPhone and iPad, the order that actually converts, and a pre-upload checklist you can run in two minutes. No fluff, just the specs and the playbook.
The 2026 App Store screenshot sizes (spec table)
Apple simplified its requirements over the last few cycles. Today you only need to upload two canonical sizes — the largest iPhone and the largest iPad — and App Store Connect auto-scales them down to every smaller device. You no longer have to maintain a separate file for every display class.
The current required portrait sizes look like this:
| Device | Display | Resolution (px) | Required? |
|---|---|---|---|
| iPhone (16/17 Pro Max class) | 6.9" | 1320 × 2868 | Required |
| iPad Pro (M4 class) | 13" | 2064 × 2752 | Required if your app supports iPad |
| iPhone (legacy) | 6.5" / 6.1" / smaller | Auto-scaled from 6.9" | Optional |
| iPad (legacy) | 12.9" / 11" / smaller | Auto-scaled from 13" | Optional |
A few rules that trip people up:
- Files must be PNG or JPEG, in the RGB color space, with no alpha channel (no transparency).
- Dimensions must be pixel-perfect — App Store Connect rejects anything off by even a pixel.
- You can upload up to 10 screenshots per localization, and a minimum of one (Apple recommends at least three).
- If your app runs on iPad, iPad screenshots are mandatory — you cannot skip them.
Tip: design at the 6.9" iPhone size first. Because everything scales down from it, getting your largest canvas right means every smaller device inherits clean, sharp artwork.
These dimensions change as Apple ships new hardware, so always confirm against the current Apple Developer screenshot specifications before a release. For a maintained cross-reference, MobileAction's screenshot guide tracks each generation.
How many screenshots should you use
The technical ceiling is 10, but more is not better. Aim for three to ten, and obsess over the first two or three — those are the only ones most users ever see.
Here is why. On the search results page and at the top of your product page, Apple shows a preview strip. Depending on orientation and device, users see roughly the first one to three screenshots without tapping or swiping. The overwhelming majority never swipe past the third frame. So your conversion story has to be told in those opening frames.
A practical distribution:
- Screenshots 1–3: carry the entire pitch. Assume the rest are never seen.
- Screenshots 4–6: depth for the people who do swipe — secondary features, breadth, reassurance.
- Screenshots 7–10: optional. Use them for edge cases, integrations, or a final call to action, not your core message.
If you only have the budget to perfect three frames, perfect the first three. Everything after that is a bonus.
The screenshot order that converts
Order is a lever you control for free, and it moves install rates more than most people expect. The structure that consistently performs: hook, core value, social proof, feature, CTA.
Screenshot 1 — the hook
Lead with your single strongest benefit, stated in plain language, paired with a clean hero shot of the app. This is your primary marketing image in search — it has to stop the scroll on its own. Use a short, benefit-driven caption (think "Track every keyword in one place," not "Dashboard"). Avoid burying the value behind a generic welcome screen.
Screenshot 2 — the core value
Show the one thing your app does better than the alternatives. If screenshot 1 made a promise, screenshot 2 proves it with the actual interface. This is where you convert skeptics, so make the value obvious at a glance.
Screenshot 3 — social proof
Ratings, review counts, awards, "as featured in," or a real user testimonial. Trust signals in the visible strip reduce the perceived risk of installing. Even a simple "Loved by 50,000+ marketers" overlay lifts conversion when it lands in those first three frames.
Screenshots 4–6 — feature depth
Now you can go wider: secondary features, breadth of coverage, integrations, and any "wow" moments that did not fit the opening. Keep one idea per frame and keep captions short.
Final screenshot — the CTA
Close with a directive: "Start free today" or "Try it in 30 seconds." A clear call to action at the end gives motivated swipers an obvious next step.
Tip: run an A/B test on screenshot 1 alone before testing anything else. Because it is the most-seen asset, a winning first frame compounds across every impression. Apple's Product Page Optimization lets you test variants natively.
Want to reverse-engineer what works in your category? See which screenshots your competitors use and analyze their ordering with Lite ASO — it is the fastest way to benchmark before you redesign.
Screenshot text now affects discovery
Here is the 2026 shift most teams have not adjusted to yet. At WWDC in June 2025, Apple introduced machine-learning-generated tags that feed App Store search and discovery. These tags are derived from your metadata, description, category — and the content of your screenshots, then human-reviewed for quality before they go live.
The practical implication: the text you put on your screenshots is no longer purely creative. Apple's models can read the words rendered on your images and use them as signals for relevance and tagging. That means your screenshot captions now do double duty — they sell to humans and they describe your app to Apple's ranking systems.
What to do about it:
- Put real, relevant keywords in your screenshot captions — the same terms you would target in your metadata. Vague taglines waste a discovery signal.
- Keep captions legible and high-contrast. If a human cannot read it cleanly, neither can the model.
- Do not keyword-stuff. Tags are human-reviewed, and a frame jammed with disconnected terms reads as spam to people and machines alike.
- Align screenshot language with your title, subtitle, and keyword field so every surface reinforces the same themes.
This dovetails with the rest of your metadata strategy. If you have not aligned your title and keyword field yet, start with our App Store optimization guide, then use a tool to find the terms worth featuring — our roundup of the best ASO tools of 2026 covers the options.
You can confirm the discovery change in Apple's own WWDC25 App Store guidance and the machine-learning tags overview from the ASO community.
Google Play screenshots: sizes & differences
If you ship on both stores, do not assume the Apple files drop straight into Google Play. The constraints are different, and Play has assets Apple does not — most notably the feature graphic.
| Asset | Spec | Required? |
|---|---|---|
| Phone screenshots | 320–3840 px per side, 16:9 to 9:16 (max 2:1 ratio) | Yes — minimum 2 |
| Phone screenshots (recommended) | 1080 × 1920 px portrait | Recommended |
| Screenshots per type | Up to 8 | — |
| Feature graphic | 1024 × 500 px | Yes — to be featured / shown in listings |
| File format | JPEG or 24-bit PNG, no alpha | Required |
| Max file size | 8 MB per image | — |
Key differences from Apple to keep straight:
- Minimum count is two on Google Play, versus one on the App Store — but the same conversion logic applies: nail the first frames.
- The feature graphic (1024 × 500) has no App Store equivalent. It headlines your listing and can appear in promotional spots, so treat it as a billboard, not a screenshot.
- No fixed device sizes. Play accepts a wide pixel range as long as you stay within the aspect-ratio bounds, which is why 1080 × 1920 is the safe industry default.
- No alpha channel on PNGs here either, and the per-file cap is 8 MB.
For the full Android playbook — listing structure, keyword placement, and store-specific ranking factors — see our Google Play ASO guide. Specs should be cross-checked against Google Play's screenshot requirements before each submission.
A pre-upload checklist
Run this before you hit submit on either store:
- Dimensions are pixel-perfect — 1320 × 2868 (iPhone 6.9"), 2064 × 2752 (iPad 13"), or your validated Play sizes.
- Format is PNG or JPEG, RGB, no alpha channel. Strip transparency before export.
- iPad screenshots are present if your app supports iPad (Apple requires them).
- Feature graphic (1024 × 500) is ready for Google Play.
- First three frames tell the whole story — hook, core value, social proof — and stand alone without the rest.
- Captions contain real keywords, are high-contrast, and are legible at thumbnail size.
- Caption language matches your title, subtitle, and keyword field for consistent discovery signals.
- A final CTA frame points motivated users to install or start a trial.
- Text is not cut off by device bezels, notches, or the dynamic island in your mockups.
- Localized variants exist for every market you target — you get up to 10 screenshots per localization on the App Store.
- File sizes are under 8 MB each (Google Play hard limit).
Get these right and your store listing does the heavy lifting that paid acquisition otherwise pays for. The fastest way to know whether your screenshots are pulling their weight is to benchmark against the apps already winning your keywords — see which screenshots your competitors use and analyze them with Lite ASO.
Start optimizing your app
Track keywords, monitor competitors, and generate optimized metadata with AI-powered insights. Free during beta.
Keep reading
All articlesApp Store Review Reply Examples That Protect Ratings and Build Trust
Use these app store review reply examples to handle bugs, billing issues, feature requests, and positive reviews without sounding robotic or defensive.
One MCP ASO Stack for ChatGPT, Claude, and Codex
Build one MCP ASO stack for ChatGPT, Claude, and Codex instead of maintaining disconnected AI workflows for rankings, metadata, and reviews.
AI Review Management for Apps: From Negative Reviews to Better Conversion
AI review management helps app teams triage faster, draft better replies, and connect store feedback to conversion and ASO decisions.