The App Store screenshot optimization playbook
The whole practice in one place — what each panel is for, how to write captions people actually read, what to test and in what order, and the compliance lines you cannot cross. The hub for everything else we have written on this.

This is the hub. Everything below links out to the detailed version; read this end to end once and you have the whole practice.
The one-line summary: your first screenshot is doing most of the work, most teams design as though all eight matter equally, and almost nobody tests.
1. Understand the asymmetry
On both stores, the first one or two screenshots appear in search results and above the fold. Everything after that needs a deliberate swipe most visitors never make.
Design as though panels one and two are the listing and the rest are for people already interested. In search specifically, your first panel renders at roughly a quarter of the size you designed it — the constraint that should shape it more than any other.
More on the surfaces in Apple's creative assets.
2. Decide what panel one promises
One question, answered before any design happens: what outcome does this app give someone, in the words they would use?
Not your logo. Not a welcome screen. Not your cleverest feature.
The test costs nothing: show panel one to someone unfamiliar with the app for two seconds, then ask what it does. If they cannot answer, no amount of work on panels four through eight will rescue it.
3. Order the rest
- The promise. The outcome, plainly.
- The proof. Real UI doing the thing, so the promise is credible.
- The differentiator. Why you rather than the obvious alternative.
- Depth. Secondary features for people already interested.
- The nudge. Whatever removes the last hesitation — privacy, offline, no account needed.
Three strong panels beat eight weak ones. Ten on the App Store and eight on Play are ceilings, not targets.
4. Write captions people read
- Name outcomes, not features. "Never lose a receipt again" beats both "OCR scanning" and "Save time".
- Use their words. The phrase a user would type, not your internal feature name.
- Short enough to scan. At thumbnail size, a sentence is too long.
- Keep the size consistent across the set. One headline wrapping to three lines while another sits on one is the clearest amateur tell in the category, and it is entirely avoidable.
5. Make it not look templated
The default output of every tool and every blank canvas is a device centred on a gradient with a headline above it, repeated. It is clean, competent and interchangeable with a large fraction of the store.
Four things separate a set that looks designed:
- Vary the composition across panels — tilt, crop into the screen, run a device off the edge, let two panels share a background.
- Render or design the set together so lighting and palette match by construction rather than by copying hex values.
- Keep caption sizes uniform.
- Never redraw the UI. Style around the screen; reproduce the screen exactly.
Why we build art directions rather than templates.
6. Stay on the right side of the rules
Also: no other platform's device frame, no pricing you cannot honour everywhere, and nothing showing functionality the submitted build lacks. The full list is in common rejections.
7. Get the technical pass right
Exact pixel dimensions per display class, consistent within each class, no alpha channel. The sizes come from the registry, and if you are already staring at an error, the fix takes two minutes.
Shipping Android too? Play caps aspect ratio at 2:1 and requires a 1024 × 500 feature graphic that most listings waste.
8. Then test, properly

Apple's Product Page Optimization and Google's Store Listing Experiments both run variants against your live listing with real traffic.
The discipline that makes the results mean anything — one variable, a stopping rule set in advance, enough traffic to see the effect — matters more than the tooling.
Test the first screenshot first. Largest sample, largest effect.
9. Then match the page to the traffic
Once the default page is good, a Custom Product Page lets a campaign land on a page whose first panel echoes the ad that earned the tap. Message match is the entire principle.
10. Then localize
People install what they can read. Translated captions are one of the few changes with a clean mechanism rather than a persuasion argument — and the hard part is that translated text is a different length and sometimes a different direction. See localizing screenshots.
The short version
Seed real data before capturing. Decide what panel one promises before designing. Vary the composition. Keep captions uniform and outcome-led. Never invent a number. Hit exact pixel sizes. Then test the first screenshot against real traffic, because your opinion about your own listing is the least reliable input available.
Start with a free review if you want a second pair of eyes on where yours currently stands.
Keep reading
Are your App Store screenshots costing you installs?
A diagnostic you can run in ten minutes, on your own listing, without any tools. Six specific failures that leak installs from traffic you already earned — and which ones are worth fixing first.
Read ASOA/B testing your screenshots without fooling yourself
Both stores will happily show you a winner that is noise. What a screenshot test can and cannot tell you, how long to actually run it, and the four ways these tests go wrong.
Read ASOCustom Product Pages: matching the listing to the ad that earned the tap
A CPP is a second product page with its own URL, and the reason to build one is message match. When it is worth the maintenance, how many you actually need, and the mistake that makes them worthless.
Read