Design

App Store Screenshot Best Practices: What Actually Moves Installs (2026)

Your first two screenshots decide most installs. The design rules, per-store requirements, and testing loop that turn screenshot slots into conversion.

By ReachFrontJuly 12, 20269 min read

Discuss this article with AI

Open this post in your assistant of choice with a ready-made prompt - it will read the article so you can dive in and ask questions.

People decide whether to install your app in a few seconds, and they spend most of those seconds on your screenshots. Not your description, which most never expand. Not your feature list. The pictures.

That makes screenshots the highest-leverage design work an indie developer does all year, and also the most commonly fumbled: raw UI dumps, unreadable captions, the login screen first. This guide is the set of practices that consistently move conversion, plus the per-store rules so nothing bounces in review.

Think in search results, not product pages

Here's the mental shift that changes how you design: most people first meet your screenshots as thumbnails on a search results page, sitting directly beside your competitors. On the App Store, your first two to three portrait screenshots show right in search results. The install often happens from there, without your product page ever being opened.

So the real canvas isn't "my beautiful product page": it's a small tile in a row of small tiles, competing against the two apps above and below you. Search your own target keyword, screenshot the results, and look at where you'd tap. That's the bar.

Two direct consequences:

  • Portrait beats landscape for anything that isn't a landscape game. Portrait gets two to three screenshots into search results; landscape gets one.
  • Your first screenshot is your ad. Not an overview. Not a welcome screen. Your single strongest benefit, readable at thumbnail size.

The practices that move conversion

Caption first, UI second

The pattern used by almost every top-charting app: a short benefit line in large type at the top, the real interface below it. The caption does the persuading; the UI does the proving. Write all your captions before opening a design tool, in order of importance. If the caption sequence doesn't sell the app as plain text, rearrange until it does.

Good captions are outcomes: "Fall asleep in 15 minutes", "Split any bill in seconds", "Your first workout is ready". Feature names ("Sleep sounds library") are what you write when you haven't decided what matters.

Lead with the money screenshot

Screenshot one gets several times the attention of screenshot three, and everything after five is nearly private. Order ruthlessly: biggest benefit, second benefit, social proof, then supporting features. If you have a rating worth bragging about, awards, or a press quote, give social proof its own early screenshot: it converts skeptics that benefit claims can't.

Pass the thumbnail test

Shrink every screenshot to roughly a third of its size, the scale it occupies in search results. Can you read the caption in under a second? Can you tell what the screen does? If not: bigger type, fewer words, more contrast between caption and background. Dark text on busy UI fails this constantly; a solid or gently graded background behind the caption fixes it.

Show real UI, staged honestly

Populate the app with realistic, flattering data: a habit tracker mid-streak, a budget with normal-looking numbers, names that aren't "Test User 3". That's expected and fine. Faking is not: both stores require screenshots to represent the actual app, and Apple rejects sets showing features, content, or hardware you don't ship. The line is simple: stage the truth, don't manufacture it.

Let Apple read your captions

Apple's systems read the text inside screenshots, which means your captions can carry relevance signals for search, not just persuasion. Write captions with your natural keywords where they fit ("habit tracker with streaks" rather than "Consistency, reimagined"), and you get a small ranking assist for free. Never caption-stuff: it reads as spam to humans first.

Localize the set, not just the words

A translated listing with English screenshots tells users the app isn't really for them. For your top non-English markets, translate captions at minimum, and show localized UI where you have it. Screenshot localization is repetitive production work, which is exactly why most indies skip it and why it still works as an edge.

Test one change at a time

Apple's Product Page Optimization and Google Play's store listing experiments both A/B test screenshots against live traffic. Start with your first screenshot, change one variable per test, and let it run to significance. A conversion lift from screenshot testing compounds forever, because both stores feed conversion rate back into ranking: a listing that converts better gradually ranks better too.

Per-store rules worth knowing

  • App Store: up to 10 screenshots per device size. Design once at the 6.9-inch iPhone size (1320×2868) and the 13-inch iPad size (2064×2752) and let smaller displays scale down. First three portrait screenshots appear in search results.
  • Google Play: 2 to 8 screenshots per form factor, JPEG or 24-bit PNG, 320 to 3,840 pixels per side, aspect ratios between 16:9 and 9:16, plus the 1024×500 feature graphic (required if you want your promo video shown).
  • Every current dimension, device by device, lives in our app store screenshot sizes reference: bookmark it and stop re-Googling the numbers each release.

Templates and tooling

You don't need a design degree for any of this: you need a caption sequence and a tool that handles device frames, type, and per-store export sizes. ReachFront's screenshot generator does exactly that, including localizing your caption text across languages in one pass, which removes the main excuse for shipping English-only sets. Figma templates work too if you'd rather stay manual; the practices above matter more than the tool.

Once the set is live, run your listing through the free ASO score checker: it grades screenshots alongside your metadata and tells you which fix moves the needle first.

Frequently asked questions

How many screenshots should I use?

Fill every slot: up to 10 per device size on the App Store and up to 8 per form factor on Google Play. But design like only the first two matter, because for most visitors they're the only ones seen. Each additional screenshot is read by fewer people, so front-load your strongest benefit.

Do screenshots affect app store ranking?

Indirectly but meaningfully. Screenshots drive conversion rate, and both stores feed conversion back into ranking: a listing that converts a higher share of its impressions rises. On iOS, Apple also reads the text inside your screenshots, so on-image captions contribute relevance signals too.

Should app screenshots be portrait or landscape?

Portrait, unless you're a game that's genuinely played in landscape. Portrait screenshots show two to three abreast in App Store search results while landscape shows only one, so portrait sets get more visual real estate exactly where the install decision happens.

What size should app store screenshots be?

For the App Store, design at 1320×2868 for the required 6.9-inch iPhone slot and 2064×2752 for the 13-inch iPad slot; smaller sizes scale down from those. Google Play accepts JPEG or 24-bit PNG between 320 and 3,840 pixels per side, in ratios from 16:9 to 9:16, plus a 1024×500 feature graphic. The full current table for every device is in our screenshot sizes reference.

Can I use device frames and marketing text in screenshots?

Yes, both stores allow styled screenshots with device frames, captions, and backgrounds, and most top charts apps use them. What you can't do is mislead: the UI shown must be what the app actually looks like, and Apple rejects screenshots showing features or devices you don't support.

Next steps

Get the exact sizes right, design caption-first, and put the set live. Then treat it like the rest of your listing: the ASO guide covers how screenshots fit the bigger ranking picture, and the launch checklist makes sure they're done two weeks before you need them, not two hours after.