App Store screenshots that earn the download

Your screenshots sit above the description, so for many visitors they are the whole pitch: the first one has to show the app doing its job with a caption in plain words.

Keywords get someone to your store page. Screenshots decide whether they download. This is the part indie developers postpone, because it feels like design work rather than product work, and it is the part where an afternoon of work shows up fastest on your store page.

The screenshots are the pitch

Assume nobody reads your description. Most visitors will not: it sits below the screenshots, and part of it is behind a “more” tap, so a lot of people decide before they ever reach a sentence you wrote. The screenshots are read instead, and they are also what shows up in search results, where your app is being compared against the others on the screen at a glance.

So treat the set as the pitch rather than as documentation. Every question a visitor has in those few seconds is “what is this, and is it for me?”, and the screenshots are the only place you get to answer.

Show the app doing its job

The first screenshot carries almost the whole story, because it is the one every visitor sees first and the one many never scroll past.

Put the app doing the thing it is for, with real content in it. A budgeting app should show a month with actual numbers, not an empty state with a plus button. A journal should show a written entry, not the blank composer. Empty screens are honest, but they show the app before the value arrives, which is exactly the wrong moment to freeze.

Three first screenshots that waste the slot:

Then order the rest deliberately. Screenshot one is the main job. Two and three are the next most convincing things it does. Anything that needs a paragraph of explanation goes last, or not at all.

Captions that say the benefit

A bare device image leaves the visitor to work out what they are looking at. A short line of text above it does that job for them, which is why almost every store page you admire has one.

Write the caption as the outcome, in the words a person would use. “See where the money went” beats “Advanced categorization engine”. “Know your rank before your coffee” beats “Daily keyword tracking with historical charts”. Feature names describe the machinery; benefits describe the visitor’s life with the app in it.

Keep each caption to a handful of words, large enough to read on a phone at the size search results show, and let one caption make one point. Two claims stacked in one caption means neither gets read. And keep the whole set in one voice and one visual treatment, so it reads as a single pitch rather than as a row of separate attempts.

Sizes without the spreadsheet

The tedious part. Apple asks for screenshots at exact pixel sizes: a set built for the largest iPhone display it currently lists, and an iPad set if your app runs on iPad, with a Mac size of its own for Mac apps. The definitive list is the one App Store Connect shows next to the upload slots, and it changes when Apple ships new hardware, so trust that list rather than a blog post from two years ago.

The reason this eats a day is that people build the set once per size. Export at one size, discover the caption no longer fits at another, rebuild. The way out is to lay the design out once, as content rather than as pixels, and switch the export size instead of rebuilding: the same background, captions and device frames re-render at each size Apple asks for.

That is also the moment to think about languages if you ship in more than one. Captions are the only text in a screenshot, so a set that keeps the design and swaps the captions per language is a translation job of a few dozen words rather than a redesign.

ASOblick has a screenshot studio for this, and the whole thing is in the free version: every preset, every export size, no watermark in the corner and no time limit counting down. You lay out the set once, pick the size, and export what App Store Connect asks for.

Get notified at launch