Cross-Platform App Screenshots: Resizing Breaks Play Store

No, you can't ship the same screenshot files to both stores, and the reason isn't resolution. Apple's 6.9-inch portrait canvas is 1320 x 2868 pixels [1]. Google Play caps the long side at twice the short side [2], which puts the ceiling at 2640. You're 228 pixels over before you've designed anything.

The export matrix further down sorts every cross-platform asset into three buckets: what reuses untouched, what has to be re-rendered, and what's genuinely net-new. That's the part the spec sheets leave you to work out.

TL;DR:

• The two stores validate on opposite philosophies. Apple publishes an allowlist of exact pixel pairs [1]. Google Play accepts a range, 320px to 3840px, with one constraint: "The maximum dimension of your screenshot can't be more than twice as long as the minimum dimension" [2].
• Every accepted iPhone portrait size fails that ceiling. They run between 2.17:1 and 2.18:1 against a hard 2.00:1 cap. The iPad 13-inch canvas (2064 x 2752) passes comfortably at 1.33:1.
• "Resize" is the wrong verb. Scaling preserves aspect ratio, and the ratio is what's failing. You re-render the design onto a different canvas, which means the layout re-flows.
• Frame counts don't match either. Apple takes "one to 10 screenshots" [1]. Google Play takes "up to 8 screenshots for each supported device type" [2]. Two frames get cut.

Table of contents

• Can you use the same screenshot files for both stores?
• Why does every iPhone size fail Google Play's ratio rule?
• What actually transfers between the two stores?
• How do you build one screenshot pipeline for both stores?
• Which two frames do you cut when Google Play caps you at eight?
• What belongs on a cross-platform export checklist?
• Ship both listings from one source set

Can you use the same screenshot files for both stores?

No. Apple validates against an allowlist: your file matches one of the exact pixel pairs it publishes per display size, or App Store Connect rejects it [1]. Google Play validates against a range plus a ratio ceiling [2]. Those are different kinds of rule, and a file that satisfies one can violate the other on a dimension the first rule never checked.

That difference is the whole problem, and it's why the usual advice stops one step short. Most guides tell you the sizes differ and to resize accordingly. The sizes do differ. But resizing is not the operation that fixes it, and reaching for it produces either a still-invalid file or a silently damaged design.

The stores also disagree on how many assets they want, what formats they take, and which assets exist at all. Google Play wants a landscape feature graphic that has no iOS equivalent. Apple wants a separate set per device family. The key differences between the two stores run deeper than screenshots, but screenshots are where the mismatch costs the most production time.

Why does every iPhone size fail Google Play's ratio rule?

Because the modern iPhone is taller than 2:1 and Google Play's cap is exactly 2:1. Apple's accepted portrait screenshot dimensions run from 1179 x 2556 up to 1320 x 2868 [1]. Divide the long side by the short side on any of them and you land between 2.17 and 2.18. The ceiling is 2.00 [2].

Here's the arithmetic on every accepted iPhone portrait size:

Seven accepted sizes, seven failures. There's no iPhone canvas you can carry across.

Now the part that matters for your workflow: scaling can't fix a ratio violation. Resizing 1320 x 2868 down to 1080 x 2347 preserves the 2.17:1 ratio exactly, so the smaller file is just as invalid as the larger one. The only operations that move you inside the ceiling are cropping (which eats content) or re-rendering onto a shorter canvas (which re-flows the layout).

Re-rendering at the same width is the cheap version. At 1320 wide, Google Play's tallest legal canvas is 1320 x 2640. That's 228 pixels of vertical space you no longer have, and in a text-top layout that band is almost exactly where the caption sits. The caption doesn't shrink by itself. Either the type size drops, the copy gets shorter, or the device frame slides up and loses its bottom crop.

The iPad side behaves differently. Apple's 13-inch canvas is 2064 x 2752 [1], a 1.33:1 ratio that clears Google's ceiling without any adjustment. If you're shipping a tablet listing, those frames are dimensionally portable in a way the phone frames never are. You can check any device's exact spec against the device dimensions reference before you commit a canvas.

What actually transfers between the two stores?

Three buckets, and only one of them is free. Sorting your assets this way before you start production is what keeps a cross-platform launch from turning into two full design passes. The buckets are reuse as-is, re-render the same design, and build something new.

Bucket 1: reuse as-is. The design system, not the files. Your palette, type scale, caption voice, icon treatment, and the order you tell the story in all carry across untouched. On the file side this bucket is nearly empty for phone frames and genuinely useful for tablet frames, since the iPad ratio already clears Google's rule.

Bucket 2: re-render the same design. Every phone frame. Same layout, same caption, same colors, rebuilt on a Play-legal canvas with the vertical budget re-fitted. This is the bulk of the work and the bucket people mislabel as "resizing." Google Play recommends staying near 16:9 or 9:16 for large-screen listings and asks for assets "between 1,080 and 7,680px" there [2], so a 9:16 phone canvas is the safe default across both surfaces.

Bucket 3: build something new. The feature graphic, at 1024px by 500px [2], is a landscape asset with no App Store counterpart, and it can't be cropped out of a portrait screenshot without losing the composition. The feature graphic versus screenshots breakdown covers what that asset has to do on its own. Budget it as a separate design, not an export.

One format note that catches people at upload: Google Play takes "JPEG or 24-bit PNG (no alpha)" [2], and Apple states that images "can't include alpha channels or transparencies" [1]. Both stores reject transparency, so flatten once in your source pipeline and the problem never reaches either console.

How do you build one screenshot pipeline for both stores?

Keep one source set and one design system, then export each store's canvas from that source rather than reshaping a finished file. The order matters: design at the constraint, not at the preference. Build the layout so it survives the shorter Play canvas first, and the taller App Store canvas becomes the easy export instead of the other way around.

In practice that's four steps:

1. Capture raw screens once, at native device resolution, from a simulator or a real device. These are inputs, not deliverables, and they feed both stores.
2. Build the design once, with the caption block sized against the 2:1 budget rather than the iPhone's 2.17:1. A caption that fits 1320 x 2640 always fits 1320 x 2868. The reverse fails.
3. Export per store from the same design, swapping the device frame and canvas rather than editing the composition. Android frames need Android hardware: a Samsung Galaxy S25 Ultra mockup in a Play listing reads as native, while an iPhone frame there reads as a port.
4. Add the Play-only assets last, since the feature graphic is a separate composition and batching it with the phone frames tends to produce a squashed screenshot instead of a banner.

Designing at the tighter constraint is the single habit that removes most of the rework. It's also the step that's hardest to retrofit, because a caption written for the taller canvas has already spent the pixels. If you're iterating in a screenshot builder rather than a static design file, the practical version is to set the Play canvas first, get the composition reading well there, then let the App Store export inherit it with room to spare.

Which two frames do you cut when Google Play caps you at eight?

Apple accepts "one to 10 screenshots" [1] and Google Play accepts "up to 8 screenshots for each supported device type" [2], so a full App Store set loses two frames on the way across. Cut from the back, never from the front, and check what each store shows before a tap.

Apple's own guidance is specific about the front of the set: "Depending on the orientation of your screenshots, the first one to three images will appear in search results when no app preview is available, so make sure these highlight the essence of your app" [3]. That makes frames 1 through 3 load-bearing on both platforms and frames 9 and 10 the cheapest to lose, since almost nobody scrolls that far.

The one case where cutting from the back is wrong: if your last frame carries social proof, pricing clarity, or a trust signal that the rest of the set doesn't, promote it into the eight and drop a mid-set feature frame instead. The first three frames playbook covers why the front of the set carries most of the conversion weight, and the same logic decides the tail.

Google Play also asks for "a minimum of 4 screenshots" on Chromebook and tablet listings [2], and requires "a minimum of two screenshots across different device types to publish your store listing" [2]. Those floors are easy to trip on a phone-only launch.

What belongs on a cross-platform export checklist?

Six checks, run once per release, catch nearly every rejection and every silently broken layout. Each maps to a rule one store enforces and the other doesn't, which is exactly where cross-platform sets tend to fail.

• Ratio check. Every Play-bound file at 2:1 or wider on the short side. Confirm by dividing, not by eyeballing.
• Exact-size check. Every App Store file matching a published pixel pair for its display size [1]. Close isn't accepted.
• Alpha check. No transparency in any file, for either store [1][2].
• Count check. 10 max on the App Store, 8 max per device type on Google Play, 2 minimum across device types to publish [1][2].
• Caption fit. Read the caption at the Play canvas height, not the iPhone one. If it only fits the taller frame, it doesn't fit.
• Frame realism. Android hardware in the Play listing, Apple hardware in the App Store listing.

For the full Play-side dimension tables across every device class, the Google Play screenshot sizes guide has the per-device breakdown this checklist assumes.

Ship both listings from one source set

The cross-platform screenshot problem isn't that the sizes differ. It's that the two stores disagree about what kind of rule a size even is, so the file that satisfies Apple's allowlist violates Google's ratio ceiling by roughly 200 pixels every single time. Resizing moves the file along the axis that's already failing.

Design against the tighter canvas, keep one source set, and export per store instead of reshaping finished art. That turns a second store listing into an export step rather than a second design project. When the two listings share a design system, the screenshot builder handles the canvas swap and the device frame swap in the same pass, and the store-by-store differences guide covers the policy and review gaps you'll hit after the assets are done.