App store screenshots that explain the app in five seconds

Most people who find your app never open its product page. They see it as one row in a list of search results: icon, name, subtitle, rating and a strip of screenshots. On the App Store, depending on orientation, that strip is the first one to three screenshots, unless you have an app preview. The decision to tap or keep scrolling happens there, in a second or two, and the screenshots take up most of the row.

So I plan screenshot sets backwards. Before anyone opens a design file, I want to know what the first three say on their own, at the size of a search result, to someone who has never heard of the app. Everything after the third one is a bonus. This guide covers how I get there: what each store shows, how to order the set, how to write captions, and the details that trip teams up (languages, dark mode, panoramic sets, and sizes).

What the stores show, at the time of writing

Apple's product page guidance allows up to 10 screenshots per product page and says the first one to three appear in search results when no app preview is available. App previews always come before screenshots, autoplay with muted audio, and can be up to 30 seconds long. App Review Guideline 2.3.3 asks that screenshots show the app in use, not merely title art, a login page or a splash screen. Guideline 2.3.7 adds that screenshots shouldn't include prices.

Google Play's preview asset rules are more detailed. You can add up to 8 screenshots per device type and need at least two to publish. Screenshots may appear in search and on the home page, not only on your listing. Google asks you to prioritize real UI in the first three, keep taglines to no more than 20 percent of the image, and avoid words like "Best", "#1", "Top", "New", "Discount", "Sale" or "Million Downloads". Calls to action such as "Download now" are out, device imagery is discouraged, and each screenshot should get alt text.

Put those together and the brief writes itself. The first three images must make sense alone, must show the real app, and must say something specific without bragging.

The five-second check

My test is crude and cheap. Export the first three screenshots, put them side by side at roughly the size they appear in search results on a phone, and show them to someone outside the team for five seconds. Then take them away and ask two questions: what does this app do, and who is it for?

If the answer is vague ("something with money?"), the set fails, no matter how polished it looks at full size. This is not a statistically meaningful test, and I don't treat it as one. It is a filter that catches the obvious problems before you spend an experiment slot on them, and it costs a coffee.

Order the first three like a sentence

I give each of the first three screenshots a single job.

1. The outcome. Show the screen people will use most, in a filled-in state, with a caption that names the job the app does. For a budgeting app, that is the month's overview with real-looking numbers, not the empty start screen.
2. The core task in motion. Show the one action that delivers the outcome: adding an expense, starting a workout, booking a slot. If the task takes several steps, pick the step where the value is visible.
3. The reason to pick this app. Show what makes it different from the alternative the user has now, whether that is a rival app, a spreadsheet or a paper notebook.

Screenshots four onward can cover secondary features, widgets, sync, dark mode and privacy settings. They matter for the people who open the product page and swipe, and those people are already interested. The first three have to earn that interest.

Writing captions that survive a thumbnail

Captions are where most sets lose the five-second check. The usual faults are captions that describe the company instead of the user, captions that list features, and captions that make claims the screen doesn't support. My working rules: one idea per screenshot, a verb near the start, the words your users actually say, and a type size that can still be read at search-result size.

Those user words matter twice. The terms you chose for your App Store keyword field are a good source, because they are the words people searched before they found you. Contrast matters too: thin light-gray type on a pastel background disappears at thumbnail size, and the contrast advice in our accessibility checklist applies to captions as much as to the app itself.

Here is how that plays out for an imaginary bill-splitting app:

None of the stronger captions is clever. They are short, they describe what the screen beneath them shows, and each one could be checked by someone who installs the app.

Show the real screen, at its best

Use real UI, captured from the build you are shipping. Fill it with plausible sample data: names that look like names, amounts that add up, a calendar with a believable week in it. Empty states are honest but they explain nothing, and screens full of placeholder text look unfinished. Google Play also asks for a tidy status bar with no notifications or carrier names, which is good practice on both stores.

I stopped putting device frames around screenshots a while ago. Google discourages device imagery because it dates quickly, and on both stores a frame shrinks the actual UI, which is the part people came to see. A full-bleed screenshot with a caption band at the top usually reads better at small sizes. That is a preference, not a rule, so test it if your team disagrees.

Languages, dark mode and panoramic sets

Localize the captions along with the app

Captions are text, and text needs translating. Google Play says taglines and overlays should be localized even when in-game UI doesn't need to be, and Apple lets you upload a separate set for each localization. Plan for length: a caption that fits in English may run long in German or Portuguese, so leave room in the template. Build the set from a design file where captions are text layers, not flattened images, so each language is an export rather than a redesign. If your app supports right-to-left languages, capture those screenshots from the app running in that language, not from mirrored English screens.

Show dark mode once, in the right place

Apple suggests that if your app supports Dark Mode, you include at least one screenshot that shows it. I put it after the first three unless dark is the app's default look. A single dark screenshot among light ones reads as a feature; a set that alternates between the two looks like two different apps.

Panoramas need to work in pieces

A panoramic set, where one background or illustration runs across several screenshots, can look striking on a product page. Google Play explicitly allows stylized sets that break the UI across several images, but asks you to prioritize real UI in the first three as much as possible. The risk is the search result, where only the first images appear. If screenshot one only makes sense once you swipe to screenshot two, the search result shows half a thought. Design the panorama so every frame stands alone, with the continuous element in the background.

Check sizes before you export

Required sizes change with new devices, so check them at the source before every new set. At the time of writing, Apple's screenshot specifications list two accepted portrait sizes for the 6.9-inch iPhone display, 1290 x 2796 and 1320 x 2868 pixels. The 6.5-inch set is required only if you don't provide 6.9-inch screenshots, and smaller iPhones get scaled versions. Apps that run on iPad also need 13-inch iPad screenshots, at 2064 x 2752 or 2048 x 2732 pixels in portrait.

Google Play accepts JPEG or 24-bit PNG without alpha, with each side between 320 and 3,840 pixels and the long side no more than twice the short one. To be eligible for the recommendation formats that use screenshots, an app needs at least four screenshots at a minimum of 1080 pixels, in 9:16 portrait (at least 1080 x 1920) or 16:9 landscape (at least 1920 x 1080). Our icon and screenshot size reference keeps these in one table with a preview, but the store pages are the final word.

Before your next redesign, take a screenshot of your own app's search result on a phone, crop it to the single row, and put it next to the rows of your two closest competitors. If you can't tell within five seconds which one solves the problem better, start by redrawing screenshot one.