How Do I Make the Best App Screenshots for the Store?

The average visit to an app's product page lasts no more than 10 seconds, and according to SplitMetrics, roughly half of that time is spent looking at screenshots. That means a potential user has formed an opinion about your app before they have read a single word of your description, before they have checked your rating, and before they have any idea what your onboarding looks like. The screenshots did that work, or they did not.

The screenshots decide whether a referred user actually hits the download button.

We worked on a gifting and wishlist platform where the client was genuinely reluctant to spend time on App Store assets. Their reasoning was that the product was social by nature, referral would drive downloads, and therefore the store listing was secondary. What we found was that even referred users land on that page and still make a snap judgement. A friend's recommendation gets someone to the store. The screenshots decide whether they follow through.

That experience shaped how we think about app store screenshots entirely. They are a sales tool with a precise window, a strict format, and a user on the other side who is moving fast and trusting their instincts. Getting them right is a design and communications challenge, not a technical checkbox. This article sets out how to approach that challenge from the ground up.

Why Screenshots Are a Sales Tool, Not a Technical Requirement

App stores ask for screenshots as part of the submission process, and that framing shapes how development teams approach them: as a requirement to satisfy rather than an opportunity to use. The result is screenshots that show the app accurately but sell it poorly. They document rather than persuade, and there is a meaningful difference between the two.

A screenshot that shows your dashboard in its default state is accurate. A screenshot that shows a user what their life looks like after using your app is a sales argument. The first satisfies the store. The second converts a browser into a downloader. Both are screenshots. Only one is doing the job the format is capable of.

We take the position that a well-constructed store listing reduces churn, and screenshots are a large part of why. When the images accurately represent what the app does and feels like, the people who download it arrive with correct expectations. They have, in effect, pre-qualified themselves. They know roughly what they are walking into, so they are less likely to open the app, feel surprised, and leave. The screenshot set is part of that expectation-setting, and a misleading or vague one creates the kind of mismatch that shows up later in your retention data.

Treating screenshots as a technical requirement produces technically compliant images. Treating them as a sales tool produces something that actually grows your install base.

What the Store Actually Shows: Sizes, Limits, and Display Rules

Before the design conversation, it helps to understand what the stores will and will not display. Apple's App Store and Google Play have different rules, and designing to the wrong spec wastes effort and sometimes produces assets that display poorly or not at all.

Apple App Store rules

Apple allows up to 10 screenshots per app on the App Store, and they can be displayed in portrait or landscape orientation. Portrait is considerably more common in practice: ASOMobile report that 96% of top apps use vertical screenshots, which reflects both how phones are held and how the store renders images in search results. The standard display size for the iPhone 6.5-inch frame is 1242 x 2688 pixels. Apple requires you to submit assets for specific device sizes, and failing to match those exactly means rejection.

Google Play rules

Google Play allows up to 8 screenshots and accepts both portrait and landscape. The minimum size is 320 pixels on the short side, and the maximum is 3840 pixels on the long side. The aspect ratio must be 16:9 or 9:16. Google does not enforce device-frame matching in the same way Apple does, which gives a little more flexibility in how you present the visuals. Both stores display a preview of the first two or three screenshots in search results without requiring the user to tap through, which makes those first images the ones that carry the most weight.

Choosing Your Screenshots Before You Design Them

The design question comes second. The first question is what you are trying to show, and that is a strategy question, not a visual one. Teams that go straight to design often end up with screenshots that look polished but tell a disjointed story, because nobody decided what the story was before the designer opened their software.

Start by listing every meaningful thing your app does. Then ask which of those things a new user would care about most before they have downloaded anything. Those two lists are rarely the same. Features that feel significant to the team after months of building them are often not the ones that convert a stranger in a seven-second window.

The features that matter to the team are rarely the ones that convert a stranger in seven seconds.

We find it useful to think about the screenshots as a short argument: screenshot one makes a claim, screenshot two supports it, screenshot three adds a reason to trust it, and so on. Each image earns its place by advancing that argument rather than simply filling a slot. If you cannot explain why a particular screen is in the set, it probably should not be there.

A practical way to stress-test this is to look at your screenshot sequence and ask what a new user now knows after seeing each one. If the answer after the third image is still vague, the sequence is not doing enough work. According to ASOMobile, around 90% of users do not scroll past the third screenshot, so the first three images are effectively carrying the entire conversion argument.

Write out the argument you want each screenshot to make in plain language before you design it. If the argument is not clear in words, it will not be clear in an image either.

Writing Captions That Sell the Benefit, Not the Feature

Most app screenshots include a short caption, typically one line above or below the device frame. The most common version of this caption names a feature: "Track your progress", "Set your daily goals", "View your history". These are accurate. They are also almost entirely unconvincing to someone who has not yet decided to download.

A feature caption tells the user what the app does. A benefit caption tells the user what they get. "Track your progress" describes a function. "See exactly how far you've come" describes an experience. The second one gives the user something to want. The first one just confirms that a feature exists.

The discipline here is to keep asking "so what?" after each caption draft. "Set your daily goals", so what? You stay consistent. "Stay consistent, every day", that is the caption. It takes the feature one step further to the place the user actually cares about.

Keep captions short. One line, under eight words if you can manage it. The caption is read in a fraction of a second alongside the image, and anything longer either competes with the visual or gets ignored. It should confirm and amplify what the image is already showing, not explain it from scratch.

Test your captions by reading them without looking at the screenshot. If they still communicate something worth having, they are doing real work. If they only make sense alongside the image, rewrite them.

Keeping Your Screenshots on Brand

Screenshots exist at the intersection of two things: the actual product and the brand promise that brought the user to the store page. When those two things feel like they came from different companies, something breaks in the user's mind. The decision to trust or not trust becomes harder, and a harder decision usually resolves as a pass.

We worked on a mobile app in the health and wellness genetics sector where this mismatch was the central problem. The brand's packaging and online presence were aspirational and luxurious, all about transformation and reaching your full potential. The app itself was cold and clinical, purely functional in its design and copy. Users who moved from the marketing through to the app were making a jarring transition, and the screenshots sat right at the point where that jarring started. They showed a clinical interface under a premium brand promise, and the gap was visible.

Screenshots should feel like they belong to the same world as the brand's other touchpoints. That means consistent typography, the same colour palette, the same tone in the captions, and visual decisions that carry the emotional register of the brand rather than just documenting the product neutrally.

Headspace is a useful reference here. Their choice to use illustration rather than photography is a trust-building decision that most analysis misses. A photograph of a serene person sets a real-world standard the user may feel they are failing to meet. An illustrated character implies nothing about the user's own state. That choice runs consistently through every touchpoint, including their store screenshots, and it works precisely because it is consistent.

Designing for the User Who Already Wants to Download

There are two different users looking at your screenshots. The first is undecided: they landed on your page from search, they are browsing, and they need to be convinced. The second has already been convinced by something else, a recommendation, an ad, a piece of press, and they are now on the store page looking for confirmation that the thing they have heard about is real and worth their time.

Most screenshot advice focuses entirely on the first user. The second one matters too, and their needs are slightly different. They are looking for reassurance that their existing inclination is correct. They want to see that the app looks as good as they heard it does, that it appears straightforward to use, and that the quality seems consistent with the impression they already have.

For this user, visual quality and consistency carry a lot of weight. A screenshot set that feels slightly mismatched, with different type sizes, inconsistent padding, or captions that do not quite fit the images, introduces a small but real doubt in someone who was otherwise ready to tap download. The design has to feel coherent enough that it confirms rather than complicates.

After finalising your screenshot set, show it to someone who has already expressed interest in downloading your app. Their reaction tells you whether the assets confirm or complicate the impression they arrived with.

Testing Which Screenshots Actually Convert

Opinions about which screenshots are best are useful for getting to a starting point. Data is what tells you whether that starting point is working. Both stores provide mechanisms for testing, and using them removes the guesswork from what is otherwise a very guesswork-heavy process.

Apple offers Product Page Optimisation, which lets you test up to three alternate versions of your screenshots against the default. Google Play offers Store Listing Experiments with similar functionality. Both work by splitting traffic between variants and measuring conversion rate, meaning the proportion of people who view the page and go on to download.

What to test

The variables worth testing are the order of screenshots, the caption copy, whether or not you include device frames, background colour choices, and whether the first image leads with a lifestyle visual or a UI visual. These are meaningfully different approaches and the right answer depends on your specific audience and category. There is no universal winner.

How to read the results

Run tests long enough to reach statistical significance before drawing conclusions. A test that runs for three days on low traffic is noise. Set a minimum sample size before you start, stick to it, and change only one variable per test so you know what caused the result. Screenshots capable of increasing app page conversion rates by 20-35% are not a theoretical possibility, according to ASOMobile. That range reflects real variation between screenshot sets, and testing is how you find out which end of it your current assets are sitting at.

Common Mistakes That Cost You Downloads

The most frequent screenshot problems we see are repeatable, fixable, and almost always the result of moving too quickly from "we need screenshots" to "screenshots are done".

• Showing the UI without showing the benefit. The screen looks correct but gives no reason to care.
• Putting too much information in a single screenshot. A cluttered image reads as a cluttered app.
• Using the same visual weight across all screenshots. If everything looks equally important, nothing stands out.
• Ignoring Dark Mode. With over half of users regularly using it, a screenshot set that only shows Light Mode is already out of step with a significant portion of your audience.
• Making the first screenshot do too little. It is the image most likely to be seen and it needs to make the strongest single argument for the app.
• Writing captions for the team rather than the user. "Powered by our proprietary algorithm" means nothing to someone who has never heard of you.

There is also a subtler mistake worth naming. Some teams treat screenshots as a one-time task, something completed at launch and revisited only when the app changes significantly. The store listing is a live asset. Seasonal updates, new features, and A/B test results all create reasons to refresh the screenshot set, and an outdated set can quietly underperform for months without anyone noticing.

Conclusion

Screenshots are the part of your app store listing that most users will actually look at. The description is rarely read in full. The rating confirms trust but does not build it from scratch. The screenshots are where the visual argument for your app either lands or does not, and they do it in a window of a few seconds against a user whose attention is genuinely limited.

Getting them right means making three separate decisions well: what to show, how to show it, and how to write about it. What you show is a strategy decision about which parts of your app do the most persuasive work for a user who does not know you yet. How you show it is a design decision about consistency, quality, and brand alignment. How you write about it is a communications decision about benefit over feature, user language over team language, and clarity over completeness.

None of those decisions is made once and finished. The store is a live environment, user behaviour changes, and a screenshot set that converted well six months ago may be underperforming now without any obvious signal that it has stopped working. Build in the habit of testing, and treat the store listing as something to maintain rather than something to complete.

If you would like a set of eyes on your current store listing, or you are building towards a launch and want to approach the screenshots with a clear strategy from the start, let's talk about your app store presence.

Frequently Asked Questions