Playbook

The App Store screenshot playbook

Six frames, the captions that carry them, the store requirements that gate them, and how to turn the same set into install ads and a preview video.

20 min read, then keep it open while you build the galleryFor Mobile apps, SaaS + startupsUpdated 2026-09-16

What is inside

  • The six-frame gallery narrative, frame by frame, with what belongs in each and what never does
  • Current App Store and Google Play requirement classes: device sizes, count limits and where the two stores differ
  • 20 screenshot caption formulas with the mechanism behind each
  • 12 prompts for generating the background plates behind your real screen captures
  • An 18-point QA pass and a category-to-angle table covering 15 app categories

Your gallery is an ad, and frame one is the whole ad

A store listing is not documentation. Nobody scrolls your gallery to learn what the app does; they scan it to decide whether to spend thirty seconds installing something. In search results and on most listing layouts, the first frame is what appears, sometimes alone, and it appears small.

That produces the one rule everything else follows from: frame one has to work on its own, at thumbnail size, with no context, for someone who has never heard of you. If frame one is a raw screen capture of your interface, it reads as a grey rectangle with unreadable text. If it is one large caption plus one legible crop of the app doing its job, it reads as a promise.

The frames after it are not a feature tour. They are an argument, in order, aimed at the specific hesitation a person has at that moment in the scroll. That is why the order below is a sequence of decisions and not a list of features.

Two practical constraints to hold in your head while you read: the stores require exact pixel dimensions and specific formats, and Apple expects screenshots to show the app in use rather than a marketing fantasy. Both are covered further down, and both are cheaper to respect from the first frame than to retrofit the night before submission.

The six-frame narrative

Six is the working default. Three is the minimum that functions, Google Play caps at eight per device type and Apple at ten per localisation per device class, and past about eight the marginal frame rarely earns its production cost. Each frame below answers one question the viewer is asking, in the order they ask it. One idea per frame: two features in one screenshot reads as neither.

  1. 1

    Frame 1: The hook

    Answers 'what is this and why should I care'. One caption of at most two lines stating the single outcome the app delivers, plus one legible crop of the screen where that outcome appears. Not the home screen, not the dashboard, not the login: the screen that shows the result. Crop into the interface hard enough that its own type stays readable at gallery thumbnail size, which usually means showing one panel rather than one whole screen. This frame sets the visual system for the other five: background treatment, caption position, caption weight, how the device is framed, how much margin sits around everything. Build it first, approve it alone, then treat it as the template. Building all six in parallel from cold produces six galleries, not one.

  2. 2

    Frame 2: The core value, shown

    Answers 'what does using it actually look like'. Frame 1 made a claim, frame 2 shows the claim being true. Use the primary workflow screen with realistic content in it: a real-looking list, a real-looking chart, plausible names and numbers. The caption here names the job, not the feature. 'Every subscription in one place' rather than 'Subscription management view'. This is the frame where empty states and placeholder data do the most damage, because the viewer is specifically looking for evidence that the app has substance.

  3. 3

    Frame 3: Proof of the main action

    Answers 'how hard is this going to be'. Show the single most important action being performed, and show that it is short. A one-tap capture, a swipe that files something, a scan that resolves. If the action takes two steps, show the two steps in one frame as a small sequence rather than splitting it across two frames. The caption states the effort, not the capability: 'Log a meal in one photo' does more work than 'Photo-based food logging'. Frames 1 to 3 are the ones visible without scrolling on most layouts, so if the argument is not carried by these three, nothing later rescues it.

  4. 4

    Frame 4: The differentiator

    Answers 'why this one and not the three above it in search'. Name the thing your nearest alternatives do not do, and show it. This is usually a specific capability, a constraint you respect that others do not, or a fundamentally different model of the same job. Resist the temptation to make this frame about your brand values. The viewer is comparing apps, not choosing a worldview. If you genuinely have verifiable proof to show here, such as a rating your store already displays or an award you actually hold, this is the frame for it. Never fabricate a rating, a review, a user count or a press quote: invented proof in a store listing is both a policy problem and the fastest way to lose the install after it happens.

  5. 5

    Frame 5: The objection killer

    Answers 'what is going to annoy me about this'. Every category has one dominant hesitation, and it is almost always known to you from support tickets and reviews. Privacy and where the data goes. Whether it works offline. Whether it syncs to the device they actually use. Whether the free tier is real. Whether it will nag them. Pick the one objection that kills the most installs and answer it plainly in a caption, with a screen that supports the answer. This is the least glamorous frame and often the highest leverage one, because it is the only frame addressing the reason people who liked frames 1 to 4 still did not install.

  6. 6

    Frame 6: The call to install

    Answers 'fine, what now'. A closing frame that restates the outcome in the shortest possible form and shows the app at its most appealing, often the single most visually pleasing screen you have. Keep the caption short and imperative in the reader's language, and do not put a fake install button in the image: the real one is already on the page and a drawn one reads as a broken control. If you have a free tier, a trial or a no-account-needed first run, this is where to say so in a single line, because the last remaining friction at this point is commitment, not comprehension.

9 more sections

Read the rest free.

A free Advibly account unlocks the full document and the download. No card needed, and you get 2 credits to try it on your own product.

What you unlock

  • The six-frame gallery narrative, frame by frame, with what belongs in each and what never does
  • Current App Store and Google Play requirement classes: device sizes, count limits and where the two stores differ
  • 20 screenshot caption formulas with the mechanism behind each
  • 12 prompts for generating the background plates behind your real screen captures
  • An 18-point QA pass and a category-to-angle table covering 15 app categories

Free to start. See what a paid plan adds

Start from your store listing

Advibly onboarding accepts an App Store or Play Store URL and pulls your existing listing screenshots into the brand's assets, so you have your current gallery as reference material from the first minute. New accounts get 2 free starter credits, enough to produce and judge a style plate before paying anything.

Start with your app listing

Questions about this one

Six is the working default. Three is the minimum that functions as an argument, Google Play accepts up to eight per device type and Apple up to ten per localisation per device class. Past about eight, the extra frame rarely earns its production cost, because most viewers never scroll far enough to see it.
The first one, by a wide margin. On most store layouts the first frame is what appears in search results and the first three are what appear without scrolling. Build frame 1 alone, test it on someone who has never seen the app, and only produce the rest once it works on its own at thumbnail size.
They are the requirement classes in current use and a safe basis for production planning, but store specifications change. Confirm the accepted sizes and counts in App Store Connect and Google Play Console before submitting, and keep everything important inside the centre 80 percent of the frame so a spec change costs you a re-export rather than a redesign.
Not as the app interface. Apple requires screenshots to show the app in use and app previews to be captured from the app itself, and Google Play rejects listings whose graphics misrepresent the app. The safe pattern is to generate the plate around the screen, meaning the background, caption and device presentation, and composite your real screen capture into it. Invented interfaces are fine for pitch decks and pre-launch pages, not for a submission.
Usually not different designs, just different exports. One 9:16 master set covers both once conformed: Google Play phone screenshots at 1080 x 1920 are exactly 9:16 and need only scaling, while Apple's iPhone sizes need a small pad or crop. You will need a separate 3:4 set if you ship an iPad build, and a 1024 x 500 feature graphic for Play, which has no Apple equivalent.
Approve one frame as the style plate, then build every other frame from it by reference, changing only the screen content and the caption. Lock the background treatment, caption position and weight, device framing and margins in that first frame. Generating all six in parallel from separate prompts reliably produces six different galleries.