Store Screenshots

Overview

The store carousel is the highest-leverage marketing surface an app has, and the part that gets shipped wrong is almost never the taste. Baseline testing on a doc-rich repo showed the creative work — narrative order, positioning, caption voice — comes out good unaided. What came out broken every time: dimensions that violate store rules, on-screen strings quoted from memory instead of from source, and features framed that are not in the shipping build.

This skill is about those three. Do not let it flatten the copy into a template; the copy should be specific to this product or it is worthless.

When to Use

• Building the Play Store or App Store listing screenshot set
• Writing the caption/headline that sits on each screenshot
• Producing the 1024×500 Play feature graphic
• Re-cutting the same set as 4:5 social slides

Not for: launch videos, in-app onboarding, or press kits.

Rule 1 — Frames 1–3 carry the entire pitch

Published ASO benchmarks all point the same way, even though their exact numbers disagree. Treat the numbers as direction, not fact — they come from vendors (StoreMaven, ASO tool blogs), not from Apple or Google:

If you quote any of these to a client or in a deck, cite the vendor study you took it from.

So: frame 1 = what it is and who it is for. Frame 2 = the differentiator. Frame 3 = the objection that arrives once someone believes frames 1–2. Frames 4–8 are depth, utility and breadth, in that order.

The common failure is writing the set as an even feature tour across 8 frames. That spends the two frames that matter on a table of contents.

One benefit per frame. A frame that needs "and" in its headline is two frames.

Caption word cap: 6 words for the headline, one line for the subline. If it does not survive Rule 6, cut words — never shrink the type.

Rule 2 — No quote without a citation

Every string that appears on a panel as product copy — a headline pulled from the UI, a feature name, a number, a label — must be grepped from source first, and you record file:line next to it in the plan.

This is not pedantry. In baseline testing an agent put the sentence "it is 3:40 am for rhea" on a panel and cited a line number. The real string was 'it is the middle of the night for ' at a different line. Invented UI copy on a store asset is a misrepresentation that ships.

Writing new marketing copy is fine and expected. Presenting invented text as the app's own words is the violation.

Rule 3 — Every framed feature must exist in the shipping build

For each frame, name the artifact that proves the feature ships: the widget provider, the Cloud Function, the release-flavour entry. A feature that works in debug, or whose backend needs an account you do not have yet, cannot be framed.

Check specifically for features gated on: a paid backend tier, a developer account you have not bought, a store-billing integration, or an API key. These are the ones that look done in the repo and are not live for a user.

If a feature is not verifiable, move it to the bench and use a replacement frame.

Rule 4 — Comp per store; never resize between them

Apple's tall portrait is not a legal Play size. Apple 6.9" is 1320×2868 (≈2.17:1). Play requires the longest side ≤ 2× the shortest. A 2.17:1 image fails that rule, so an Apple master cannot be resized into a Play asset — the caption block has to be re-composed for 9:16.

Full tables: references/store-specs.md. The traps, inline:

• Play: min side 320px; max side 3840px; longest ≤ 2× shortest
• Play: for high-visibility placements, use 9:16 portrait at ≥ 1080×1920 (or 16:9 landscape ≥ 1920×1080) — so in practice, build at 9:16
• Play: JPEG or 24-bit PNG with no alpha channel; ≤8MB each; up to 8 per device type, at least 2 in total to publish
• Play: the 1024×500 feature graphic is required, and its centre must stay clear because a play button overlays it once a promo video exists
• Apple: 6.9" master at 1320×2868 auto-scales to smaller iPhones; 1–10 per class
• Apple: 1290×2796 is the older 6.7" size, accepted but not the current master

Rule 5 — Nothing in the art that policy reads as a claim

Banned from the pixels, regardless of whether it is true:

• Price, "free", "free forever", trial lengths, discounts
• CTAs: "download now", "get it", "install"
• Rankings, superlatives, testimonials: "#1", "best", "as seen in"
• Security words you cannot back: "private", "secure", "encrypted" unless it is genuinely end-to-end and you can prove it
• Any content that raises the age rating: adult pack names, real-money stakes, gambling-shaped mechanics. Listing art is seen by everyone regardless of rating.

Put the free-tier promise in the long description, where it belongs, not baked into a PNG you cannot edit without a re-upload.

Rule 6 — Proof at thumbnail before export

Lay the full set out at 150px wide in a row and read it. If a headline is illegible there, cut words. Also check the strip has a colour beat — eight frames on the same ground read as one grey block in search results.

Check the frame edge survives against both a white and a dark store card. A light background with no boundary dissolves into Play's white listing card.

Rule 7 — One state, one clock, every frame

Render every frame from the same seeded/demo app state with a pinned clock. Same partner name, same counts, same balances, same dates. Numbers that drift between frames read as mockups and destroy the credibility the real UI bought you.

Red Flags — stop and fix

• A headline containing "and" → two frames
• A quoted UI string with no file:line beside it → grep it or cut it
• "We'll resize the Apple set for Play" → illegal aspect ratio
• A frame for a feature whose backend isn't live → bench it
• 8 frames of equal weight → frames 1–3 aren't doing their job
• Currency or names that only suit one market → build a locale variant
• Alpha channel in the export → Play rejects it

Rationalizations

Process

1. Read the product's own positioning docs first — plan, roadmap, design-system comments. A repo that argues its own positioning will out-write anything generic.
2. Inventory available screen renders and note each one's true pixel size; do not upscale a 1x render.
3. Draft the frame order against Rule 1, then write captions with citations (Rule 2).
4. Run the gates: Rule 3 (ships?), Rule 5 (policy?), locale variants.
5. Render source states at master resolution — references/render-pipeline.md.
6. Comp, proof at thumbnail (Rule 6), export per store (Rule 4).

Why it matters

Screenshots are usually the cheapest conversion work available, and unlike the icon they can be tested: Google Play has store listing experiments, and the App Store has product page optimization. Run one before arguing about taste.