App Store Screenshots That Convert: Sizes, Device Frames, and Simulator Capture

App Store screenshots are the single biggest conversion lever for an app product page - more than the icon, more than the title, more than the description. Yet most apps ship with rushed screenshots: raw simulator captures with no framing, no captions, no narrative arc. This guide covers the screenshot requirements for 2026, the framing options, the Simulator capture commands, and the rejection patterns to avoid.

Required sizes and what you actually need to upload

As of 2026, the App Store requires the following screenshot sizes for iPhone apps. You can upload up to 10 screenshots per size:

• 6.9-inch display (iPhone 16 Pro Max, 15 Pro Max): 1320 x 2868 px portrait, 2868 x 1320 px landscape
• 6.5-inch display (iPhone 11 Pro Max, XS Max): 1242 x 2688 px portrait
• 5.5-inch display (iPhone 8 Plus, 7 Plus): 1242 x 2208 px portrait - still required for some submission types

For iPad apps:

• 13-inch display (iPad Pro M4): 2064 x 2752 px or 2752 x 2064 px
• 12.9-inch display (iPad Pro 12.9"): 2048 x 2732 px or 2732 x 2048 px

Strategic uploads. Apple uses screenshot fallback: if you upload only 6.9" screenshots, older devices viewing the App Store will see those scaled down. Practical recommendation for 2026: upload 6.9" iPhone (required), 12.9" iPad (if you ship iPad), and skip the smaller iPhone sizes unless you have a specific reason. Saves you 30 minutes per locale per submission.

Localization. Each App Store locale can have its own screenshots. For a 10-locale app, that's potentially 100 screenshots per size to manage. Most apps localize 1-2 hero screenshots and let the rest be English. Apps targeting one specific country (e.g. CSCS for UK) should localize everything.

Capture techniques: Simulator, framing tools, automation

Simulator screencapture (basic). Boot the right Simulator (iPhone 16 Pro Max for 6.9"), navigate to the screen you want, then run xcrun simctl io booted screenshot screenshot1.png. This produces a raw screenshot at the correct device size. No frame, no marketing text. Acceptable for utility apps; suboptimal for consumer apps.

Device framing. Tools like Fastlane Frameit, AppLaunchpad, ScreenshotPro and Rotato take the raw screenshot and add a device frame plus marketing copy. The good ones do it programmatically from a config file so all 10 locales can be regenerated in one command. Fastlane Frameit + a YAML config is the dev-friendly choice; AppLaunchpad is the designer-friendly cloud tool.

Automated capture with SCREENSHOT_MODE. For apps with onboarding, paywall, or login flows that get in the way of screenshots, bake a SCREENSHOT_MODE flag into your debug build. In your App's init, check UserDefaults.standard.bool(forKey: "SCREENSHOT_MODE") wrapped in #if DEBUG. When true, skip onboarding, pretend the user has Premium, use sample data.

Then activate it on the Simulator: xcrun simctl spawn booted defaults write <bundleID> SCREENSHOT_MODE -bool true. This pattern is in production use across 12 of our apps and reduces screenshot capture from a 45-minute manual task per locale to a 5-minute scripted run.

The full automation pipeline: launch each Simulator at the right device, set SCREENSHOT_MODE, navigate to each target screen via deep link, capture, repeat. Tools like Fastlane Snapshot wrap this in a single ruby file. Combined with Frameit for the framing pass, screenshot regeneration for a 10-locale app becomes a 2-minute script.

Quick comparison

Common pitfalls and how to avoid them

Across every domain this article touches, the same shape of mistake recurs. Practitioners new to the field overweight the most visible piece of the system — the screenshot, the paywall, the exam question, the headline price — and underweight the underlying constraint that actually determines outcomes.

The five most common failure modes:

1. Optimising for the demo, not the durability. A working demo in a controlled environment proves nothing about reliability under real conditions. In iOS development, an in-app purchase flow that works in the Xcode Simulator says nothing about how it behaves in App Store sandbox with network latency and Ask to Buy approvals. In an exam, a 100% score on an untimed quiz tells you nothing about whether you can do 49/50 in 45 minutes with no second guesses. Build for the hardest realistic case from the start.
2. Skipping the first-principles documentation. Every system has a canonical specification. App Review Guidelines for iOS, the official EU regulations for tax deductibility, the CITB question bank for CSCS, the OMIE market rules for Spanish electricity. Reading them takes a few hours but saves weeks of wrong-direction work. Secondary sources (blogs, tutorials, this article included) are useful as orientation but never authoritative.
3. Ignoring the rate limit. Every external system has rate limits — explicit (APNs silent push throttling, RevenueCat API quotas, exam retake fees) or implicit (App Review patience, customer attention spans, your own working memory). Plan around them. A workflow that requires more rate-limited operations than the system allows will fail in production, not on day one but during the first stress event.
4. Underweighting localisation and regional variation. What is true for Germany is not always true for Italy. What is true for English-speaking users is not always true for Japanese ones. What is true for the UK CSCS test is not always true for the Irish equivalent. Always check the local rule before applying a general one.
5. Treating the documentation as static. Apple updates App Review Guidelines. The Bundeslaender change Schonzeiten. OMIE adjusts market clearing algorithms. Set up a periodic review (quarterly is enough for most things) and re-read the canonical sources. Workflows that worked perfectly a year ago can be silently broken today.

None of these are dramatic. The dramatic mistakes (catastrophic bugs, audit findings, exam failures) are the visible tip of a longer-running iceberg of small misses. Catching the small misses is what separates routine outcomes from problematic ones.

Key takeaways

• 6.9-inch — iPhone 16/15 Pro Max. Required.
• 12.9-inch — iPad Pro 12.9". If shipping iPad.
• Frame tool — Fastlane Frameit. YAML config.
• SCREENSHOT_MODE — Bypass onboarding. Debug-only.

The pattern that runs through every section above: start with the constraint, not the wishlist. In an exam, the constraint is the question bank and the pass mark. In an electricity market, it is the auction clearing rule. In a tax workflow, it is the receipt-retention requirement. In a code architecture, it is the platform's design decision (StoreKit's transaction lifecycle, App Review's guideline, APNs's authentication model). Get the constraint right and the rest follows.

The opposite failure mode — designing for an aesthetic ideal, then trying to retro-fit the constraint — is the most common cause of wasted work in every domain covered here. A beautiful paywall that hangs in sandbox is rejected at App Review. A polished freelancer expense report that lacks receipts is disallowed by the tax office. A study plan that ignores the actual question distribution leaves the candidate stuck below the pass mark.

The practical recommendation: read the official rules of whatever system you are operating in, extract the binding constraints, and treat them as inputs to the design — not afterthoughts. Every section of this article is the application of that principle to a specific domain.

FAQ

Do I need to upload screenshots for every iPhone size?
No. Upload 6.9" iPhone screenshots and Apple will scale them down for smaller displays. Older 5.5" Plus sizes are mostly unnecessary unless you target very old devices.

Can I use Photoshop instead of a framing tool?
Yes, but it's the slow path. Designers who hand-craft each screenshot in Photoshop work great for a 5-screenshot single-locale launch. For 10 locales and weekly iterations, automated tooling pays back in days.

What's the most common screenshot rejection reason?
Screenshots showing UI not present in the actual app - a feature you removed, a paywall that no longer exists, or marketing copy that promises features the app doesn't deliver. Apple's Guideline 2.3.7.

Should I include caption text in screenshots?
Yes. Screenshots with caption text convert significantly better than raw UI captures. Use a clear two-line headline per screenshot, summarising what the screen does. Localise the captions per market.

Further reading and references

The references below cover the official sources for the rules cited in this article. Where applicable, they include the canonical documentation, regulatory text, or vendor-provided guides. For each one, prefer the official source over secondary commentary — secondary sources go stale fast and frequently misquote the binding rule.

• Official documentation of the system in question (linked from each app or service's own help centre).
• Apple Developer Documentation for any iOS/macOS reference — the WWDC session videos and the corresponding Human Interface Guidelines pages are the authoritative source.
• For EU regulatory questions (taxation, data protection, energy market structure), consult the relevant national authority — most publish their guidance in English.
• For Spain and Italy energy market data, OMIE and GME both publish full historical price series in CSV format from their public websites — no API key required.
• For UK CSCS prep, the CITB publishes the official question bank book each year — buy a current copy if you want the authoritative source.

If you find a contradiction between this article and an official source, the official source wins. Article rules of thumb are summaries — they have edge cases, exceptions, and regional variations that the source documents specify exactly.