Skip to content
All articles

How to resize App Store screenshots for every iPhone and iPad size

The pixel sizes App Store Connect actually accepts in 2026, what to do about simulator black bars and device borders, and a four-step workflow that stops you resizing by hand.

6 min read

Somewhere between the last release and this one, every app team discovers screenshot resizing the unkind way: a checklist of device sizes, an evening of re-exporting the same design a dozen times, and a review queue that still bounces one file for a dimension it never mentioned. This guide lays out the sizes App Store Connect actually accepts, the couple of rules that cause most rejections, and a four-step workflow that turns the whole job into one capture plus a resize pass.

What sizes does App Store Connect accept?

The good news: you do not need to babysit every device. App Store Connect accepts a single largest-size iPhone screenshot (1290 × 2796 for the 6.9-inch iPhone) and scales it down for the rest of the line, and it does the same for iPad with a 2048 × 2732 shot. Submit the big ones and the smaller devices are covered.

The catch is direction: scaling works down, never up. A 750 × 1334 iPhone 4.7-inch export looks soft when a store page expects 1290 × 2796. So the workflow is capture large, resize down, and keep one canonical large set per device family.

DeviceAccepted screenshot sizeNotes
iPhone 6.9″1290 × 2796Largest iPhone size; submit this and Apple scales the rest
iPhone 6.7″1206 × 2622Also accepts the older 1284 × 2778 for Plus-class artwork
iPhone 6.1″1179 × 2556Current standard-resolution size
iPhone 5.8″ / 5.5″ / 4.7″1125 × 2436 · 1242 × 2208 · 750 × 1334Legacy sizes, still accepted, rarely generated new
iPad Pro 12.9″2048 × 2732Largest iPad size; submit this for the whole iPad line
iPad Pro 11″1668 × 2388Optional per-device size
iPad 10.9″ · mini 8.3″1620 × 2160 · 1488 × 2266Optional per-device sizes

Google Play is a different job: screenshots belong to a device class — phone, 7-inch tablet or 10-inch tablet — and each class is validated separately with a 320px short-side floor. A phone screenshot is not a valid substitute for a tablet one, which is why a screenshot's class is part of the record, not just its filename.

iPhone (portrait) and iPad (portrait) have different aspect ratios. Stretching an iPhone capture to iPad dimensions fakes a layout that device never actually rendered, and store review teams do catch it. Capture each device family once; only then scale.

The rules that cause most rejections

Most rejected screenshots fail on one of three things, and none of them is hard to fix:

  • Simulator chrome. A raw simulator capture includes the device frame, notch or letterboxed black bars. Crop to the app content before resizing — the black bars are what your screenshot's own preview shows at the wrong size.
  • Upscaling. Resizing up manufactures pixels and soft edges. Every store scales down; none of them make your small file sharp. Capture at or above the largest target and resize down.
  • Wrong aspect ratio. iPhone and iPad screens are not the same proportion. Scale to exact dimensions, never to a “good enough” approximation, and resize axis-to-axis rather than stretching one side.

A four-step workflow that stops the busywork

The teams that never dread screenshot day run a pipeline like this:

  1. Capture once, largest first. Grab the sharpest frame at the largest screen in each design — portrait and landscape where the app supports both.
  2. Trim the chrome. Crop out the device frame and any letterboxing, then export at or above the largest target you will need.
  3. Resize down to exact pixel targets. Produce each device size at its exact dimensions from the same master — not new crops, not approximations.
  4. Label and version the set. A screenshot is only useful if you know which slot it fills and which release it belongs to. That metadata is what turns disk clutter into a submittable set.

That is exactly the shape of the tooling here. In Releaseyour.App you upload the clean capture once, label the device slot it fills (phone, 7-inch tablet, 10-inch tablet or iPhone Duo), and the upload rules check the store requirements from the file's own header — a wrong dimension is caught before submission, not in the review queue. Our app store screenshot resizer page walks through every size and rule in one table.

What resizing can and cannot fix

Be plain about the boundary. Resizing handles scale, crop and exact dimensions — the plumbing of getting a file to pass validation. It cannot manufacture detail in a low-resolution capture, and it cannot turn a phone layout into an iPad layout. Stretch an iPhone UI to iPad proportions and you have a distorted mock of your app, not a tablet screenshot. Keep one capture per device family, then let the resize pass handle every size in it.

Make it a one-time setup

The first time you do this properly it takes an hour. Every release after that is a single capture, a resize pass, and the same labeled, versioned set you shipped last time — with the diff showing exactly what changed. If you want the tooling to hold that workflow together, start free — one app, one 1024px icon, and the sizes take care of themselves.

Next: alternatives to Fastlane Snapshot, or see what the platform costs.

Stop resizing screenshots by hand

Releaseyour.App turns one master capture into the sizes every device needs, generates every icon from a single 1024px square, and keeps the whole set versioned per release.