App Store screenshot guidelines (2026): sizes, requirements, and what gets rejected

App Store screenshots get apps held up for two completely different reasons, and most guides only cover one of them. The first is technical: wrong size, wrong format, a missing required device — App Store Connect bounces the upload before a human ever sees it. The second is editorial: the screenshot uploads fine, then a reviewer looks at it and decides the screen isn’t showing the real app, and you get the polite “your screenshots don’t appear to show actual functionality” rejection at 2 AM the night before launch.

This post covers both: the current specifications, then a working developer’s read of Review Guideline §2.3.3 — which patterns reliably pass, and which ones get rejected.

App Store screenshot specifications (2026)

The big change to internalize first: you only need one iPhone size now. Apple scales a single 6.9-inch (or 6.5-inch) set down to every smaller iPhone automatically. The old ritual of exporting 6.7-inch, 6.5-inch, and 5.5-inch bundles is gone.

iPhone — required (pick one):

Provide one of those, and 6.3-inch, 6.1-inch, 5.5-inch, 4.7-inch, and 4-inch are all generated by scaling. You may still upload size-specific screenshots when you want pixel-perfect control on a given device — it’s just no longer required.

iPad — required if your app runs on iPad:

The 11-inch and smaller iPad sizes scale from the 13-inch set.

Mac — required if your app runs on Mac: a 16:10 image at 1280 × 800, 1440 × 900, 2560 × 1600, or 2880 × 1800.

Count, format, and order:

• 1 to 10 screenshots per localization, per display size.
• PNG or JPEG, RGB, flattened (no alpha/transparency), at the exact pixel dimensions above.
• Only the first two to three appear in App Store search results without tapping in — so front-load your strongest screenshots and treat the rest as depth.

Apple revises these as new hardware ships; the numbers above are current as of June 2026. Before any release, confirm against Apple’s official screenshot specifications. Now the half that the specs can’t protect you from.

What §2.3.3 actually says

Apple’s wording on §2.3.3 has been refined a few times since 2017, but the durable spirit is: a screenshot represents the app a user will receive. Not a future version. Not a concept. Not a marketing illustration of what you wish the app did. The actual app, in actual use.

The boundaries:

• What’s allowed: Overlaid feature copy on top of a screen capture. Colored background fields around the device. Gradient or photographic backgrounds. 3D device frames. Decorative typographic emphasis. Multiple screenshots in a sequence telling a story.
• What gets rejected: Fictional UI that isn’t in the app. Features that haven’t shipped yet. Pure marketing illustration with no real screen content. Screenshots whose UI was Photoshopped after capture to look prettier than the app actually does.

The rule, in plain language: the content inside the device screen must be the real app. Everything around the device frame is decorative styling and largely up to you.

The five rejection patterns I’ve seen most often

1. The “future-build” screenshot. The most common. A marketing team shipped a previous version’s UI in the screenshot bundle, or used a Figma concept that hasn’t been built yet. Reviewer downloads the app, can’t find the feature, rejects. Always re-render screenshots from the actual build you’re submitting.

2. The “concept-art” screenshot. Especially common in apps with rich graphics — games, drawing apps, AR apps. The screenshot is closer to a hero shot for a website than an in-app capture. Reviewer reads it as misleading. The fix is to find an in-app moment that genuinely looks like the hero shot and capture it.

3. The “deleted-feature” screenshot. Feature existed in version 2.4, was removed in 2.7, screenshots from 2.4 still uploaded for 2.7. Re-uploading old screenshots is one of the easier ways to inherit a rejection from your own past.

4. The “in-app-purchase price mismatch.” Screenshot shows “$0.99 — limited time,” App Store listing shows $4.99. Reviewer flags the inconsistency. Best practice: either show real IAP prices that match the listing, or don’t show prices in screenshots at all.

5. The “fictional metric” screenshot. Common in fitness, finance, and analytics apps. Screenshot shows “247,891 active users this month” or “+42% sleep score” but the demo data in the app shipping today shows different numbers. Reviewer treats this as misrepresentation.

App Preview videos: specs and the same content rule

App Preview videos have their own specifications, then inherit §2.3.3 on top.

• Up to 3 previews per localization, each 15 to 30 seconds.
• iPhone: 886 × 1920 portrait (886 covers 6.9-inch through 6.1-inch). iPad: 1200 × 1600.
• Formats: .mov, .m4v, or .mp4 — H.264 at roughly 10–12 Mbps or ProRes 422 (HQ), 30 fps, AAC audio.

Then the content rule, with teeth: the video must be actual app footage captured from a device — not a screen-recorded mockup, not an animated concept reel, not external camera footage of someone holding a phone. Apple checks this rigorously, especially for new apps.

How to make your screenshot pipeline §2.3.3-safe

1. Capture from a build, not a design tool. Use Simulator, Xcode UI tests, or manual capture from a TestFlight build to produce the raw screen content. If it didn’t come from a running build, it doesn’t belong inside the device frame.

2. Re-capture for every release. It’s tempting to reuse screenshots when only minor UI changes happened. Each time you do this you risk inheriting a rejection from a feature that quietly went away.

3. Strip IAP prices unless you’re certain. If the prices are dynamic, regional, or change with promotions, leave them out of screenshots entirely. Show feature value rather than price.

4. If you do show metrics, match the demo state of the shipping build. Use the same fixture data your TestFlight build uses. Don’t render “247K users” if the demo state shows “1.2K.”

5. Treat the device frame as cosmetics. Pick the visual style that fits your brand — 3D Metal render, flat outline, tilted angle, transparent background, no frame at all. Reviewers don’t care about the frame. They care about what’s on the screen inside it.

The reason a capture-first tool like Mockly is structurally compliant with §2.3.3 by default is that the workflow runs in the safe order: capture the real screen first, render the device frame around it second. The screen content is your actual app; the frame is just a render placed around it. The reverse — mock up a concept screen in Figma, drop it into a phone outline, export — is the workflow most likely to drift into rejection territory, because it encourages designing screens that aren’t in the app yet.

TL;DR

• One iPhone size now. 6.9-inch (1320 × 2868 / 1290 × 2796) or 6.5-inch (1242 × 2688); Apple scales it to smaller iPhones. iPad apps add 13-inch (2064 × 2752).
• 1–10 screenshots per localization, PNG or JPEG, flattened. First 2–3 show in search — front-load them.
• §2.3.3 is about the screen content, not the device frame. Overlay text, backgrounds, and 3D frames are fine.
• The screen must be the real shipping app. Concept art, future-build UI, deleted features, fake metrics, and mismatched IAP prices are the common rejection paths.
• App Previews: up to 3, 15–30 seconds, 886 × 1920 on iPhone — same “real footage only” rule.
• Capture-first workflows pass cleanly; design-first workflows risk drift.

For the surrounding workflow, the native screenshot tooling argument, shipping screenshots in 39 languages, and the rest of the indie iOS developer tools go deeper. The specs change with each new device; the §2.3.3 spirit has held for nearly a decade. The rejection emails keep arriving because most indie pipelines make compliance an afterthought instead of the default.