You are at the final step before submitting, App Store Connect wants screenshots, and the size list looks longer than it needs to be. For a developer or a no-code founder pushing a first release, the practical question is simple: which sizes are actually required in 2026, and at what exact pixel dimensions.
Short answer
You need two screenshot sets, not eight. Per Apple's screenshot specifications, an app that runs on iPhone must provide the 6.9-inch size at 1260 x 2736 pixels in portrait, and an app that runs on iPad must provide the 13-inch size at 2064 x 2752 pixels. You upload 1 to 10 images per size, as PNG or JPEG, at the exact dimensions. Every smaller iPhone and iPad size is generated by scaling, so a single set per device class is enough.
What you should know
- Two required sizes: a 6.9-inch iPhone set and a 13-inch iPad set cover the App Store in 2026.
- One to ten images per size: Apple accepts a minimum of one and a maximum of ten screenshots per device class.
- PNG or JPEG, no alpha: screenshots use the RGB color space with no transparency, and an alpha channel is a common silent rejection.
- Exact pixels, no tolerance: the dimensions are exact, and an off-by-one image is rejected at upload.
- Smaller sizes scale automatically: if you skip a smaller size, Apple uses a scaled version of the next size up.
Which screenshot sizes does the App Store require, and at what pixel dimensions?
The short answer is that two sizes are required and the rest are optional. Apple's screenshot specifications list one required iPhone size and one required iPad size, with smaller classes filled in by scaling. The table shows the sizes you actually upload.
| Device class | Apple display size | Portrait (pixels) | Landscape (pixels) | When it is required |
|---|---|---|---|---|
| iPhone | 6.9 inch | 1260 x 2736 | 2736 x 1260 | Required if the app runs on iPhone |
| iPhone | 6.5 inch | 1284 x 2778 | 2778 x 1284 | Accepted when no 6.9-inch set is provided |
| iPad | 13 inch | 2064 x 2752 | 2752 x 2064 | Required if the app runs on iPad |
The 6.9-inch class covers devices such as the iPhone 17 Pro Max and iPhone 16 Pro Max. The 13-inch class covers the recent iPad Pro and iPad Air models. If your app is iPhone-only you can skip the iPad set entirely, and the reverse holds for an iPad-only app.
Do I need a separate set for every iPhone and iPad model?
No. Apple scales a larger screenshot down to fill smaller device sizes when you do not upload a dedicated set. A 6.9-inch iPhone screenshot is reused for the 6.5-inch, 6.3-inch, and 6.1-inch classes, and a 13-inch iPad screenshot is reused for the 12.9-inch and 11-inch classes. The practical result is that one good iPhone set and one good iPad set are enough for a clean submission. The limit is cosmetic: a scaled image can look slightly soft on a smaller device, so apps that treat screenshots as a primary marketing surface sometimes still upload tailored sets for the most common sizes.
What file format and constraints does Apple enforce?
Apple enforces format and color rules that reject a screenshot before a human sees it. The file must be PNG or JPEG, in the RGB color space, with no alpha channel or transparency. The pixel dimensions must match the specification exactly, with no off-by-one tolerance, which is why a frame exported at the wrong scale gets bounced at upload. You can upload between one and ten images per size, and the first image is the one most likely to appear in search results, so order matters. App previews, the short video clips, follow a separate specification and are not required.
How do no-code and cross-platform builds handle screenshots?
No-code and cross-platform tools do not produce marketing screenshots for you. FlutterFlow, Expo, and similar stacks build the binary, but the screenshots are captured separately, usually from the iOS Simulator, a physical device, or a screenshot tool that renders your frames at the exact required dimensions. The reliable method is to capture on a 6.9-inch iPhone simulator and a 13-inch iPad simulator, since those produce the two required sizes natively. Resizing a screenshot from a smaller device up to 1260 x 2736 tends to blur text, so capture at the target size rather than scaling up.
What to watch out for
The fastest rejections here are mechanical. An alpha channel, a wrong color profile, or an off-by-one dimension all bounce at upload, and the message is not always specific about which one failed. A second common issue is content: under App Store Review Guideline 2.3, screenshots must accurately show the app in use, so a mockup that hides the real interface can draw a metadata rejection even when the pixels are correct. Screenshots are a metadata requirement, separate from what App Review checks inside the binary, so a wrong size is a fast fix and not a security problem. For the binary side, where a leftover permission or a hardcoded key is the kind of issue that forces a new build, a pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS before you upload.
What to take away
- Provide two sets: a 6.9-inch iPhone set at 1260 x 2736 and, if you support iPad, a 13-inch set at 2064 x 2752, per Apple's screenshot specifications.
- Upload 1 to 10 images per size as PNG or JPEG, RGB, with no alpha channel, at the exact pixel dimensions.
- Skip the smaller sizes; Apple scales a larger screenshot down to fill them, so one set per device class is enough.
- Capture screenshots at the target size rather than scaling up, and keep the binary itself clean with a pre-submission scan such as PTKD.com so a clean metadata pass is not undone by a binary rejection.
