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

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

Below are the current specifications first, then a working developer’s read of Review Guideline §2.3.3: which patterns reliably pass and which get rejected.

App Store screenshot specifications (2026)

The biggest change: 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, so you no longer export separate 6.7-inch, 6.5-inch, and 5.5-inch bundles.

iPhone, required (pick one):

Provide one of those, and the 6.3-inch, 6.1-inch, 5.5-inch, 4.7-inch, and 4-inch versions are generated by scaling. You may still upload size-specific screenshots when you want pixel-perfect control on a given device; it just isn’t required anymore.

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 put your strongest screenshots first and treat the rest as extra detail.

Apple revises these as new hardware ships; the numbers above are current as of June 2026. Before any release, check them against Apple’s official screenshot specifications. The specs can’t protect you from the other half, which is content.

What §2.3.3 actually says

Apple has reworded §2.3.3 a few times since 2017, but the intent has stayed the same: a screenshot represents the app a user will receive. That means the actual app in actual use, and excludes a future version, a concept, or a marketing illustration of what you wish the app did.

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 does.

In plain language: the content inside the device screen must be the real app. Everything around the device frame is decorative styling and mostly up to you.

The five rejection patterns I’ve seen most often

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

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

3. The “deleted-feature” screenshot. A feature existed in version 2.4 and was removed in 2.7, but the 2.4 screenshots are still uploaded for 2.7. Re-uploading old screenshots is an easy way to inherit a rejection from your own past.

4. The “in-app-purchase price mismatch.” The screenshot says “$0.99, limited time” and the App Store listing says $4.99. The reviewer flags the inconsistency. Either show real IAP prices that match the listing, or leave prices out of screenshots altogether.

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

App Preview videos: specs and the same content rule

App Preview videos have their own specifications, and §2.3.3 applies to them as well.

• 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 to 12 Mbps or ProRes 422 (HQ), 30 fps, AAC audio.

The content rule is enforced strictly here. The video must be actual app footage captured from a device. A screen-recorded mockup, an animated concept reel, or camera footage of someone holding a phone will not pass. Apple checks this closely, 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. Reusing screenshots after minor UI changes is tempting, and each time you do it you risk a rejection over a feature that disappeared without anyone noticing.

3. Strip IAP prices unless you’re certain. If the prices are dynamic, regional, or change with promotions, leave them out of screenshots entirely and show what the features do.

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 whatever visual style fits your brand: a 3D device, a flat outline, tilted angle, transparent background, or no frame at all. Reviewers don’t care about the frame, only about what’s on the screen inside it.

A capture-first tool like Mockly keeps you in the safe order: capture the real screen first, render the device frame around it second. The screen of each 3D device shows a capture you took from your app, and your text and background sit around it. Whether a set passes review still depends on what those captures show, and no tool can guarantee approval. The reverse workflow (mock up a concept screen in Figma, drop it into a phone outline, export) is the one most likely to drift into rejection territory, because it invites you to design screens the app doesn’t have 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 to 10 screenshots per localization, PNG or JPEG, flattened. The first 2 or 3 show in search, so put the best ones first.
• §2.3.3 covers the screen content and ignores 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 to 30 seconds, 886 × 1920 on iPhone, with the same “real footage only” rule.
• Capture-first workflows pass cleanly; design-first workflows tend to drift.

For the surrounding workflow, see the native screenshot tooling argument, shipping screenshots in every App Store language, and the rest of the indie iOS developer tools. The specs change with each new device, while the intent of §2.3.3 has held for nearly a decade. The rejection emails keep arriving because most indie pipelines treat compliance as an afterthought.