iPhone App Store Screenshot Sizes 2026: 1 Required Set

The only iPhone screenshot size App Store Connect requires in 2026 is the 6.9-inch set. Apple accepts three portrait resolutions for it: 1260x2736, 1290x2796, and 1320x2868 [1]. Upload one of those and Apple renders scaled-down versions on every smaller iPhone automatically. The 6.5-inch set is required only if you skip the 6.9-inch one [1].

TL;DR:

• Required: one 6.9-inch set. Accepted portrait sizes are 1260x2736, 1290x2796, or 1320x2868. Any single one passes upload [1].
• Best pick: 1320x2868 is the native resolution of the iPhone 16 Pro Max, 17 Pro Max, and iPhone Air. It renders sharpest on current flagship hardware, since Apple scales down cleanly but scaling up softens detail.
• Conditional: the 6.5-inch set (1284x2778) is required only when you don't provide a 6.9-inch set [1].
• Optional: every smaller class (6.3-inch and down) is optional. Apple auto-scales your 6.9-inch set to all of them [1].
• Formats: .jpg, .jpeg, .png. One to ten screenshots per device type [1].

Want the screenshots themselves, not just the numbers? The iPhone 16 Pro Max mockup generator renders sets at an accepted 6.9-inch size. For the iPad, Apple Watch, and Android dimensions too, the App Store screenshot sizes 2026 essential guide lists every one in a single table.

Table of Contents

• What iPhone screenshot sizes does Apple require in 2026?
• What are the exact 6.9-inch screenshot dimensions?
• Do you need a separate screenshot set for every iPhone?
• When is the 6.5-inch set actually required?
• How does Apple's automatic scaling work for iPhone?
• What file formats and limits does App Store Connect require?
• What causes iPhone screenshot rejections?
• Takeaways

What iPhone screenshot sizes does Apple require in 2026?

Apple requires exactly one iPhone screenshot set: the 6.9-inch display [1]. Every other iPhone size is either a conditional fallback or fully optional. If your app runs on iPhone and you upload a 6.9-inch set, you have met the requirement. Apple covers the rest by scaling.

Here is the full picture from Apple's screenshot specifications reference [1], sorted by what actually matters at submission time.

The practical reading: design one 6.9-inch set, upload it, done. The 6.5-inch row is a safety net for developers who never produce a 6.9-inch asset, and the rest of the table is legacy hardware Apple keeps listed for the small number of apps still targeting it.

What are the exact 6.9-inch screenshot dimensions?

The 6.9-inch class accepts three portrait resolutions, and all three pass upload: 1260x2736, 1290x2796, and 1320x2868 (landscape is the same numbers reversed) [1]. This trips people up, because most guides quote a single "correct" number and the numbers disagree across sources. They are all correct. Apple folded several large-display iPhone generations into one submission bucket, so the bucket accepts each generation's native resolution.

Which one should you pick? Use 1320x2868. That is the native pixel resolution of the iPhone 16 Pro Max, iPhone 17 Pro Max, and iPhone Air, the devices most likely to view your listing on a large screen [1]. A 1320x2868 source renders 1:1 on those panels. The smaller accepted sizes (1260x2736 and 1290x2796) still pass review, but the device upscales them slightly to fill a 1320-wide screen, and upscaling a raster always softens fine detail like thin captions or UI lines.

Three things follow from this:

• All three pass. None gets rejected for being "wrong." If your existing tool outputs 1260x2736, your screenshots are valid App Store assets. You don't have to rebuild the set.
• Bigger is the safer default. Apple scales down far more cleanly than up. A 1320x2868 source looks correct on every iPhone; a 1260x2736 source has to stretch on the newest flagships.
• Pixel-exact still applies. Whichever of the three you choose, the file has to match it exactly. A 1320x2867 file fails the same way a 1024x768 file fails. There is no rounding and no aspect-ratio tolerance.

Do you need a separate screenshot set for every iPhone?

No. You need one set. As of mid-2026, Apple generates the smaller-device versions for you from your largest provided set [1]. The "make a set for the 6.9-inch, then another for the 6.5-inch, then the 6.1-inch" workflow that older tutorials describe is wasted effort for almost every app.

This matters because the manual-every-size approach is where indie devs lose an afternoon. Eight display classes, two orientations each, multiplied by however many localizations you ship: that is hundreds of files to render, name, and keep in sync every time a headline changes. Apple's scaling collapses all of it to a single source set per language.

The one case where you'd deliberately upload more than the 6.9-inch set is when a smaller device needs different content, not just a different size. If your iPhone SE layout hides a feature your Pro Max layout shows, and you want the SE screenshot to advertise that difference, you can upload a dedicated 4.7-inch or 6.1-inch set. That is a product decision, not a requirement. The vast majority of apps ship one 6.9-inch set and let Apple handle the rest.

When is the 6.5-inch set actually required?

The 6.5-inch set (1284x2778) becomes required only when you don't provide a 6.9-inch set [1]. Apple's spec states it directly: the 6.5-inch screenshots are "required if app runs on iPhone and screenshots for 6.9" display aren't provided" [1]. Provide the 6.9-inch set and the 6.5-inch requirement disappears.

So there is never a situation where you must upload both. The two requirements are a fallback chain, not a checklist. Think of it as: Apple wants at least one large-iPhone set, prefers the 6.9-inch one, and will accept a 6.5-inch one if that's all you have.

For any app built or refreshed in 2026, the 6.9-inch set is the obvious choice. It covers the newest hardware natively and satisfies the requirement on its own. The 6.5-inch fallback mostly exists for older projects whose asset pipelines were set up before the 6.9-inch class was added in late 2024, and which haven't been updated since.

How does Apple's automatic scaling work for iPhone?

Apple treats your 6.9-inch set as the source of truth and renders scaled-down versions of it on every smaller iPhone in your app's compatibility list. From the specification: "If screenshots with the accepted sizes aren't provided, scaled screenshots for 6.9" displays are used" [1]. You upload once; the App Store does the per-device rendering at display time.

Two consequences are worth designing around:

• Quality is locked at upload. Scaling from 1320x2868 down to a 6.1-inch iPhone's 1170x2532 is a clean reduction. Scaling down to a 4.7-inch iPhone SE's 750x1334 is far more aggressive. If your headline copy or UI text is already small in the source, it can become unreadable on the smallest device in your support range. Design for the smallest target, render at the largest spec.
• You can't tune per device automatically. The scaled output is mechanical, not smart. Apple won't reflow your layout or bump font sizes for the iPhone SE. Either you accept the downscaled version, or you upload a bespoke smaller-device set as described above.

The mechanics here mirror how Apple handles iPad, where one 13-inch set scales across every tablet. If you want the full per-device scale-ratio breakdown and the compound-resize problem on legacy hardware, the iPad screenshot scaling deep dive walks through the same engine applied to tablets.

What file formats and limits does App Store Connect require?

App Store Connect accepts .jpeg, .jpg, and .png, and allows one to ten screenshots per device type [1]. That is the entire documented format constraint. PNG and JPEG both pass. There is no published hard file-size cap in the public spec, though uploads beyond roughly 8 MB get rejected in practice, and a 1320x2868 PNG with reasonable artwork lands well under that.

A few constraints aren't in the spec text but cause silent upload failures:

• No alpha channel. PNGs with transparency are rejected. Flatten against a solid background before exporting.
• sRGB color space. Display P3 files sometimes upload but render with shifted colors in the gallery. Stick to sRGB unless you've tested the full pipeline.
• No animation. Animated PNGs are rejected. Looping app previews are a separate spec entirely.
• Exact pixel dimensions. Covered above, and it's the single most common rejection cause.

One more thing the count limit implies: the first three portrait screenshots appear directly in App Store search results, and the median user sees roughly the first two to three before deciding. Order your upload so the strongest frames come first. The device dimensions tool lists the source spec for every class if you need to confirm a number mid-build.

What causes iPhone screenshot rejections?

iPhone screenshots fail for two separate reasons: upload-time rejections (App Store Connect refuses the file) and review-time rejections (a human reviewer flags the listing). Keep them separate, because the fixes are different.

Upload-time rejections happen when:

• Pixel dimensions don't match any accepted size for the class exactly (most common cause).
• The file format isn't .jpeg, .jpg, or .png.
• The file contains transparency or a non-sRGB color space.

Review-time rejections are about content. Apple's App Store Review Guideline 2.3.3 is the rule most iPhone sets run into: "Screenshots should show the app in use, and not merely the title art, login page, or splash screen" [2]. Guideline 2.3 adds that screenshots must "accurately reflect the app's core experience" [2]. A set of five marketing frames with no real app UI draws a flag. The practical industry rule is that at least 60 percent of the set should show actual in-app screens. For the full rejection-cause breakdown across every device, see the App Store screenshot rejections compliance guide.

Takeaways

For almost every iPhone app shipping in 2026:

• Upload one 6.9-inch set. That satisfies the requirement. Apple scales it to every smaller iPhone [1].
• Pick 1320x2868 when you can. It's the native resolution of the newest Pro Max devices and renders sharpest. 1260x2736 and 1290x2796 also pass, so existing assets stay valid [1].
• Skip the smaller sizes unless a specific device needs different content. The 6.5-inch set is a fallback, not a second requirement [1].
• Stick to sRGB, flatten alpha, match the pixels exactly. Anything else is a silent upload failure.
• Guideline 2.3.3 caps how marketing-heavy the set can be. Plan for at least 60 percent real in-app UI [2].

The sizing math is the easy part. The hard part is figuring out what the set should actually say, and you usually don't know until you see a few versions side by side. That's the loop the iPhone 16 Pro Max mockup generator is built for: describe your app, see a first draft at an accepted 6.9-inch size, then refine the hook and layout by chatting until it clicks. The dimension question stops mattering because every export already lands on spec. For sizing across iPad and Android too, the iPad Pro 13-inch vs 12.9-inch specs post covers the tablet side, and the App Store screenshot best practices guide covers the layer above sizing.