App Store Screenshot Dimensions and Requirements (2026)

You finished the build. App Store Connect wants screenshots before it will let you submit, and the PNG you exported from Figma an hour ago comes back with a line about an unaccepted size. The error names a number. It does not name a fix.

Every guide on this query publishes the same table of app store screenshot dimensions, copied from the same source, and then stops. The table is not the hard part. The hard part is producing a file that lands on one of those numbers exactly, because App Store Connect does not round, does not crop, and does not care that your export was one pixel off.

This is the current specification, followed by how to originate a correct file rather than repair a wrong one. Every number below comes from Apple's screenshot specifications page in the App Store Connect Help, read on 15 August 2026.

The short answer

An iPhone app needs screenshots at 1320 x 2868 pixels. An iPad app needs 2064 x 2752. Those two sizes are the only required ones — App Store Connect scales every smaller device class down from them automatically. Files must be PNG or JPEG with no alpha channel, and each size class accepts one to ten images.

The only two sizes you have to upload

Apple lists fourteen accepted iPhone and iPad sizes, which reads like fourteen exports. It is two.

App Store Connect fills an empty size class by scaling down from the next larger one, and that chain runs the whole way from the top. Provide the 6.9-inch iPhone size and the 6.5-inch, 6.3-inch, 6.1-inch, 5.5-inch, 4.7-inch, 4-inch and 3.5-inch classes all resolve from it. Provide the 13-inch iPad size and the 12.9-inch, 11-inch, 10.5-inch and 9.7-inch classes resolve from that.

Two source files cover the entire iPhone and iPad matrix. Everything past those two is an optimisation, not a requirement.

There is one substitution rule worth knowing. If you do not provide 6.9-inch screenshots, the 6.5-inch size becomes required instead — Apple will scale a 6.9-inch image down to fill 6.5-inch, but it will not scale a smaller image up to fill a larger class. Always originate at the top of the chain.

Two things do not carry over. Apple Watch sits outside the scaling chain and needs its own upload at its own size. And screenshots attach to a localisation rather than to the app, so five languages means five sets, even when the images are identical.

Every accepted size, and the ones Apple fills in for you

iPhone

• 6.9-inch — 1320 x 2868 portrait, 2868 x 1320 landscape. Required if your app runs on iPhone. iPhone 17 Pro Max, 16 Pro Max, 15 Pro Max.
• 6.5-inch — 1284 x 2778. Required only when you have not supplied 6.9-inch. iPhone 14 Plus, 13 Pro Max, 12 Pro Max, XS Max, XR.
• 6.3-inch — 1206 x 2622. Optional; scales from 6.5-inch. iPhone 17 Pro, 16 Pro, 15 Pro, 14 Pro.
• 6.1-inch — 1170 x 2532. Optional; scales from 6.5-inch. iPhone 17e, 14, 13, 13 Pro, X, XS.
• 5.5-inch — 1242 x 2208. Optional; scales from 6.1-inch. iPhone 8 Plus and the Plus generation before it.
• 4.7-inch — 750 x 1334. Optional; scales from 5.5-inch. iPhone 8, 7, SE 2nd and 3rd generation.
• 4-inch — 640 x 1136, and 3.5-inch — 640 x 960. Optional; both scale down the chain. Relevant only if you still support that hardware.

iPad

• 13-inch — 2064 x 2752 portrait, 2752 x 2064 landscape. Required for iPad apps. iPad Pro M5 and M4, iPad Air M4, M3 and M2.
• 12.9-inch — 2048 x 2732. Optional; scales from 13-inch. The 2nd-generation iPad Pro.
• 11-inch — 1668 x 2420. Optional; scales from 13-inch.
• 10.5-inch — 1668 x 2224, and 9.7-inch — 1536 x 2048. Optional, further down the chain.

Mac, Apple TV, Vision Pro and Apple Watch

• Mac — 1280 x 800, 1440 x 900, 2560 x 1600 or 2880 x 1800. Any of the four, all 16:10. Required for Mac apps.
• Apple TV — 1920 x 1080 or 3840 x 2160. Required for tvOS apps.
• Apple Vision Pro — 3840 x 2160. Required for visionOS apps.
• Apple Watch — 422 x 514 (Ultra 3), 410 x 502 (Ultra 2 and Ultra), 416 x 496 (Series 11 and 10), 396 x 484 (Series 9 through 7), 368 x 448 (Series 6 through 4 and SE), 312 x 390 (Series 3). Pick one size and use it across every localisation; Apple requires consistency here specifically.

The file rules that fail silently

The dimensions produce a loud error. These produce a confusing one, or none at all.

No alpha channel. Apple's specification says screenshots may not contain alpha channels or transparency. This is the most common silent failure for design-tool exports, because Figma, Sketch and most PNG exporters include an alpha channel by default even when nothing in the canvas is transparent. The image looks correct everywhere except the upload.

PNG or JPEG only. The accepted extensions are .png, .jpg and .jpeg. Not HEIC, which is what an iPhone hardware screenshot produces unless you changed the setting.

One to ten per size class. Ten is the ceiling per device size per localisation. The first two or three carry almost all of the decision, since those are what appear in search results without a tap.

There is no DPI requirement. Several pages ranking for this query state that screenshots must be 72 DPI. That figure is not in Apple's current specification. DPI is metadata describing intended print size; it has no effect on a pixel-dimension check. If your file is 1320 x 2868 it is accepted at any DPI value, and changing the DPI field will not fix a rejection caused by something else.

Produce the pixels, do not resize them

Here is the part no page-one result covers. Almost every wrong-dimension rejection starts the same way: someone exported at a convenient size, discovered it was wrong, and scaled the image to fix it. Upscaling a 1170-wide export to 1320 gives you a technically valid file that looks soft next to every competitor on the page.

You never have to do that, because the required sizes are not arbitrary. They are the native pixel dimensions of real devices, and the Simulator on your Mac reproduces them exactly.

The arithmetic

A screenshot's pixel size is the device's logical size in points multiplied by its scale factor. iPhone 16 Pro Max is 440 x 956 points at @3x, so 440 x 3 = 1320 and 956 x 3 = 2868 — the 6.9-inch requirement, exactly. iPad Pro 13-inch is 1032 x 1376 points at @2x, so 2064 x 2752 — the iPad requirement, exactly.

That means capturing from an iPhone 16 Pro Max or 17 Pro Max Simulator, or an iPad Pro 13-inch Simulator, gives you an upload-ready file with zero resampling.

Capturing it

# Boot the device class that matches the required size, then capture.
xcrun simctl boot "iPhone 16 Pro Max"
xcrun simctl io booted screenshot ~/Desktop/shot-01.png

# Confirm before you upload.
sips -g pixelWidth -g pixelHeight ~/Desktop/shot-01.png

simctl io ... screenshot writes a PNG with no alpha channel at the device's native size, which clears both of the rules above in one step. Swap the device name for "iPad Pro 13-inch (M4)" to produce the iPad set from the same script.

The status bar

Apple's own marketing screenshots show 9:41, full signal and a full battery. Your Simulator shows the real time and whatever the battery state happens to be, and that inconsistency across a set of five screenshots is visible even to someone not looking for it.

xcrun simctl status_bar booted override \
  --time "9:41" \
  --dataNetwork 5g \
  --cellularBars 4 \
  --wifiBars 3 \
  --batteryState charged \
  --batteryLevel 100

Run that once before your first capture and it holds for the whole session. xcrun simctl status_bar booted clear puts it back.

If your app needs to be in a particular state for each shot — a populated list, a specific sheet open, a mid-flow screen — this is also where a scripted approach starts paying for itself. Driving the app in the Simulator rather than tapping through it by hand is how Reely captures footage. The same discipline applies to stills: put the app in a known state, then capture. The fifth screenshot in a set stays reproducible after a UI change.

What correct dimensions will not do for you

Dimensions are a gate, not a strategy. A pixel-exact 1320 x 2868 screenshot of an empty state converts worse than a slightly imperfect one of your app doing something. Getting the numbers right removes a rejection; it does not earn a download.

Two limits worth naming plainly.

Screenshots are stills, and stills are the weaker half of a listing. A screenshot cannot show a gesture, a transition, or how fast something is. That is what the app preview slot is for, and the specification for that video is a separate set of numbers with a separate set of rejection reasons — the blog covers those alongside this.

Reely is the wrong tool for this specific job. Reely produces video from a running iOS feature; it does not lay out a screenshot set with marketing captions on a coloured background. If what you need this afternoon is ten framed stills with headlines, a screenshot-layout tool is the right answer and this article's simctl procedure is still the right way to source the raw captures for it.

How to decide which screens to shoot

Work in this order. The first three do most of the work, because search results show the first two or three images without a tap.

1. Which screen shows the thing your app is for? Not the login, not the onboarding, not the settings. The screen someone spends time in. That is screenshot one.
2. What state should it be in? Populated, never empty. Real-looking content, no Lorem ipsum, no test accounts named "asdf".
3. What is the second-strongest reason to download? That is screenshot two. If you cannot name it, you have one screenshot and a set of filler.
4. Does the flow need to be understood in order? If yes, keep the sequence. If no, rank by strength and ignore the app's navigation order entirely.
5. Is the text legible at listing size? Screenshots render small in search results. Open your export, scale it to roughly a thumbnail, and see whether anything survives.

Frequently asked questions

Do I need to upload every screenshot size?

No. For an iPhone-and-iPad app you need two: 1320 x 2868 for the 6.9-inch iPhone class and 2064 x 2752 for the 13-inch iPad class. App Store Connect scales those down to fill every smaller class automatically. Apple Watch is the exception and needs its own upload, because it sits outside the scaling chain.

Why were my screenshots rejected for the wrong dimensions?

Almost always because the export was made at a device's point size rather than its pixel size, or at the wrong scale factor. A 440 x 956 export is the logical size of an iPhone 16 Pro Max; the required file is that multiplied by three. Check the actual pixel dimensions with sips -g pixelWidth -g pixelHeight before uploading rather than trusting the export dialog.

Can I use a frame from a screen recording as a screenshot?

Only if the recording was captured at native resolution and the extracted frame lands exactly on an accepted size. A recording from a physical iPhone usually does, but any resize during export breaks it. Capturing a still directly with xcrun simctl io booted screenshot avoids the question entirely and takes less time than extracting a frame.

Do App Store screenshots need to be 72 DPI?

No. Apple's current screenshot specification does not mention DPI at all. The requirement is pixel dimensions, and DPI is metadata about intended print size that has no bearing on that check. Pages repeating the 72 DPI figure are carrying forward an old convention. If an upload fails, the cause is the pixel size, the file format, or an alpha channel.

Where to start

Boot the Simulator device that matches the size you need, run the status bar override once, and capture with simctl io booted screenshot. That gets you correct pixels on the first try, which is the whole problem this page exists to solve.

Then look at the empty App Preview slot next to your screenshots. A listing with stills is valid; a listing with thirty seconds of the app actually moving is the one that answers the question a screenshot cannot. If that video is the part you have been putting off, Reely builds it from an iOS feature by driving the Simulator and composing the result — download it for Mac and see whether it fits how you work.