Boolean Build

Store screenshots get rejected for geometry — the 2:1 trap and the accepted sizes

Screenshots are the last asset you produce before a release and the first thing that fails on upload. In my experience none of those failures are artistic — they’re arithmetic, and the arithmetic is checkable in a second.

Google Play: the 2:1 ceiling

Play’s screenshot rules are short and enforceable:

The 2:1 rule is the one that bites, because phones are taller than 2:1. A raw capture from a modern device is already outside the limit:

iPhone 6.5"  1242 × 2688  →  2688 / 1242 = 2.16:1   ✗ over 2:1
iPhone 6.9"  1320 × 2868  →  2868 / 1320 = 2.17:1   ✗ over 2:1
Android 20:9 1080 × 2400  →  2400 / 1080 = 2.22:1   ✗ over 2:1
iPhone 5.5"  1242 × 2208  →  2208 / 1242 = 1.78:1   ✓ (16:9, still passes)

That last line is the shape of the fix: anything 16:9 or 4:3 is safely inside the limit, so design the screenshot at a compliant canvas instead of shipping the device capture.

Three ways out

  1. Design on a 16:9 canvas (1080×1920 is the usual choice) and place the device mock-up inside it. This is what most polished listings do, and it’s compliant by construction.
  2. Pad, don’t stretch. Letterbox the native capture onto a 2:1 background. Stretching changes the content; padding doesn’t.
  3. Crop the status bar and nav bar. It buys a little height, but a 20:9 device only becomes 2.05:1 — not enough on its own. Don’t rely on it.

App Store: it’s about native sizes, not ratios

Apple doesn’t enforce an aspect ratio; it accepts a fixed set of device sizes and scales the rest. Upload a size that isn’t native and you either get an upload error or a listing that looks soft when scaled up. The native iPhone portrait sizes:

6.9"   1290 × 2796  ·  1320 × 2868  ·  1260 × 2736
6.7"   1284 × 2778
6.5"   1242 × 2688
6.1"   1170 × 2532
5.5"   1242 × 2208

Landscape is the transpose of each. Supply your largest set (6.9") and let Connect scale down — but don’t go the other way, because upscaling is what makes a listing look cheap. Two more things Apple is picky about: alpha channels (flatten to RGB before exporting — a transparent PNG is a classic “invalid image” error) and the count (Apple wants 3–10; more than ten and the extra ones are ignored).

If you also ship an iPad or Android tablet build, the same image-check exercise applies to each size class — which is exactly the sort of thing that turns into an afternoon of uploading, failing, and re-exporting.

Check it in one command

Both rule sets can be verified from a folder of files before you open the console:

npx @njweber/screenshot-check ./screenshots          # Google Play rules
npx @njweber/screenshot-check ./screenshots --ios    # App Store rules

The hard limits (Play’s 320–3840px and 2:1) exit non-zero; the judgement calls (native iPhone sizes, alpha, counts above the minimum) are warnings, because failing a build for advice would be worse than useless. That split is deliberate — a check that cries wolf is a check you delete.

Gate it, don’t review it

Every screenshot failure costs a full submission round trip, and none of them are ambiguous. So put the check in front of the upload step — locally, and in the release workflow:

- run: npx @njweber/screenshot-check ./store/screenshots
- run: npx @njweber/screenshot-check ./store/screenshots --ios
- run: ./scripts/upload-to-store.sh   # never reached if the geometry is wrong

Same principle as every other check in the release pipeline: if a human has to remember it, it eventually doesn’t happen. The geometry rules are the cheapest possible thing to automate — they have no false positives, just arithmetic. If you’re already gating icons and the Android manifest, screenshots are the last third-party-visible asset left.

The full pre-flight — icons, screenshots, 16 KB alignment, manifests, .ipa and privacy strings — is packaged in the Expo Production Starter.