Will my screenshot be accepted? Ready, scaled or padded
Three outcomes, and you can work out which one you are getting with a calculator.
- Ready: the image is already an accepted size. It uploads untouched.
- Scale: the shape is right, the size is wrong. A proportional resize fixes it and you lose a sliver off one edge.
- Pad: the shape is wrong. The image has to be shrunk to fit and the leftover space filled.
There is no fourth outcome where the image gets stretched to fit, and there should not be.
Is it ready?
On the App Store, ready means an exact match against one of the accepted sizes for that display class, in either orientation, since both iPhone classes and the iPad class accept landscape.
| Class | Ready at |
|---|---|
| iPhone 6.9"/6.7" | 1320 × 2868, 1290 × 2796 (or those swapped) |
| iPhone 6.5" | 1284 × 2778, 1242 × 2688 (or swapped) |
| iPad 12.9"/13" | 2048 × 2732, 2064 × 2752 (or swapped) |
On Play, ready is a range, so far more images qualify. A phone, 7" or 10" tablet screenshot is ready if all three hold:
- shortest side ≥ 320 px
- longest side ≤ 3840 px
- longest ÷ shortest ≤ 2
A 1440 × 2560 Android capture is 1.78:1, ready. A 1290 × 2796 iPhone capture is 2.17:1: not ready, despite being a perfectly ordinary screenshot. Tall phone screenshots fail Play's aspect limit, not its size limits.
The Play feature graphic is the exception: exactly 1024 × 500, landscape only, no range at all.
Scale or pad: the 3% rule
If it is not ready, compare the aspect ratio of your image to the aspect ratio of the target:
difference = |source_aspect − target_aspect| ÷ target_aspect
Within 3%, it scales. Over 3%, it pads.
Three per cent is deliberately tight. It is roughly "this is the same phone shape, a different generation", enough to cover every modern tall-screen capture, not enough to quietly crop a tablet screenshot into a phone slot.
Worked examples against iPhone 6.9" (target 1320 × 2868, aspect 0.4603)
| Source | Aspect | Difference | Verdict |
|---|---|---|---|
| 1290 × 2796 | 0.4614 | , | Ready (accepted size) |
| 1179 × 2556 | 0.4613 | 0.22% | Scale |
| 1170 × 2532 | 0.4621 | 0.40% | Scale |
| 1440 × 3120 | 0.4615 | 0.28% | Scale |
| 1242 × 2208 | 0.5625 | 22.2% | Pad |
| 750 × 1334 | 0.5622 | 22.1% | Pad |
Every current tall-screen phone lands in the scale bucket, and older 16:9 phones land in pad. That split is the whole reason the tolerance exists.
Against iPad 12.9" (target 2048 × 2732, aspect 0.7496)
| Source | Aspect | Difference | Verdict |
|---|---|---|---|
| 1536 × 2048 | 0.7500 | 0.05% | Scale |
| 1668 × 2388 | 0.6985 | 6.8% | Pad |
| 1640 × 2360 | 0.6949 | 7.3% | Pad |
An old 4:3 iPad screenshot upsizes almost perfectly. An 11" iPad screenshot does not. It is a genuinely different shape, and 6.8% is over twice the tolerance.
Against a Play phone slot (target 1080 × 1920, aspect 0.5625)
| Source | In range? | Verdict |
|---|---|---|
| 1080 × 1920 | Yes | Ready |
| 1440 × 2560 | Yes (1.78:1) | Ready |
| 2048 × 2732 | Yes (1.33:1) | Ready |
| 1290 × 2796 | No (2.17:1) | Pad, 18.0% off |
| 1080 × 2400 | No (2.22:1) | Pad, 20.0% off |
This is the trap in reusing iOS screenshots on Play. They are not almost right, they are 18 to 20% off, so they arrive padded with bars top and bottom rather than resized.
What each verdict actually does to the pixels
Ready: nothing. The file is re-encoded and its alpha channel flattened, so a transparent PNG stops being transparent. Dimensions unchanged.
Scale: proportional resize to the target, then a centred crop of whatever overhangs. At 0.2% off you lose about three pixels total; at the 3% edge you lose about 3% of one dimension, split between both edges. Keep headline text out of the outer 3% of the canvas and this never shows.
Pad: the whole image is scaled to fit inside the target, and the leftover strips are filled. Filling with the image's own dominant colour blends; filling with white announces itself as a letterbox on a dark screenshot.
Why distortion is never on the menu
A non-proportional resize, 1242 × 2208 squashed to fit 1320 × 2868, is the one option that keeps every pixel and needs no cropping. It is still wrong.
Text renders visibly wrong first. Then icons go oval, and the whole set reads as sloppy next to competitors. Worse, a screenshot that shows an interface the app cannot actually produce is inaccurate metadata, and inaccurate screenshots sit squarely under App Store Review Guideline 2.3. A padded screenshot with honest bars is a cosmetic compromise; a stretched one is a rejection risk that also looks bad.
If the difference is over 3%, the right answer is usually not a transformation at all. It is a fresh capture. The iOS Simulator will give you any device size Apple accepts, and Android emulators the same. A capture at the exact target size beats every resize.
Fast triage
- Does the image exactly match an accepted size for that slot? → ship it.
- Is it a Play slot, and is the image 320 to 3840 on both sides with aspect ≤ 2:1? → ship it.
- Divide the two aspect ratios. Under 3% apart? → proportional resize, centred crop, check your edges.
- Over 3%? → re-capture if you can, pad if you cannot.
- Never stretch.
AppSubmit runs exactly this check against every slot before anything reaches a store, and shows you which of the three verdicts each screenshot landed on, but the arithmetic above is the entire rule, and one spreadsheet column does the same job.