App Icon and Screenshot Best Practices

Before anyone reads your description, they see your icon and a handful of screenshots. These visuals do much of the persuading, and they are also where many listings go wrong: cluttered icons, screenshots that show an empty login screen, claims the app cannot back up. This guide covers how to design the icon, how to plan the screenshot sequence, how to localise, and how to test changes properly on both stores.

Specifications such as image sizes, counts, and file formats change. Always confirm the current asset requirements in Play Console and App Store Connect before you export.

Icon principles

An icon is a very small image shown in search results, on the home screen, and in notifications. Design for the smallest size first.

• One idea. A single recognisable shape or symbol beats a collage. If you cannot describe the icon in a few words, simplify it.
• Contrast. The symbol should stand out from its background. Check it on light and dark wallpapers and in dark mode lists.
• Minimal text. Words become unreadable at small sizes. A single letter or short mark is the practical limit.
• Distinct in the category. Search for your category and look at the first results. If your icon looks like theirs, you disappear. If it looks nothing like the category norm, people may not understand what the app does. Aim for familiar but distinctive.
• Respect platform shapes. Each platform applies its own mask or shape and has safe zones. Keep important parts inside them and follow the current guidelines for adaptive icons on Android and icon grids on iOS.
• No misleading badges. Fake notification dots, star ratings, or “free” ribbons break store rules and erode trust.

Test the icon at tiny sizes, in a grayscale view, and next to the icons of the category leaders. Ask people who have never seen the app what they think it does.

The first-three-screenshots rule

On many listing layouts, only the first few screenshots are visible before a user has to scroll sideways. Many visitors never go further. So the first three must stand alone as your pitch.

A workable structure:

1. Screenshot one: the core benefit. Show the main screen in the state that makes the app look useful, with a headline that states the outcome in a few words.
2. Screenshot two: the strongest differentiator. What does your app do that alternatives do not?
3. Screenshot three: proof or breadth. A second key feature, a result screen, or a view that shows the depth.

Later screenshots can cover secondary features, settings, themes, and widgets. Order them by how likely each is to persuade, not by menu order.

Show real, populated states

Use realistic sample content. Empty states, error messages, and default placeholder text make an app look unfinished. Use fictional data that is clearly plausible, and never use real people’s information. If your app shows sensitive content, create a clean demo account for the capture.

Captions that work

Captions turn a screenshot into a message.

• Keep each caption to a short phrase that names a benefit, not an internal feature label.
• Use large, high-contrast text that stays legible when the image shrinks to a phone-sized thumbnail.
• Keep the wording consistent in tone across the set, so the sequence reads as one story.
• Put the caption where it will not collide with the interface or get cut off by the layout.
• Do not stuff captions with search terms; they are for humans. For the text side of listing optimisation see the keyword research guide.

Device frames and layout

Device frames can make screenshots feel familiar, but they also consume space. Use them if they help the picture stay readable, and drop them if the interface becomes tiny. Be consistent: if you frame one image, frame all of them in the set. Avoid showing a competitor’s hardware branding or anything you do not have the right to use.

Check what the stores allow regarding frames and extra graphics. Both have rules about screenshots needing to represent the app in use, so purely decorative collages with no real interface are risky. Confirm the current rules in the developer help pages.

Localisation

If your listing is available in several languages, translate the screenshots as well as the text.

• Translate captions with a native speaker or a reviewer who knows the topic, and watch for text length: German or Finnish phrases may run longer than English ones.
• Check right-to-left languages, where the layout and the reading order change.
• Where practical, show the app interface in the same language as the caption so the whole image is consistent.
• Localise formats such as dates, currency, and units in the sample content.

Not every language deserves the same investment. Start with the markets that bring you the most visitors, and use the consoles’ country reports to choose.

Testing: store listing experiments and product page optimisation

Opinions about design are cheap, and results can surprise you. Both stores provide official ways to test variants with real visitors.

• Google Play: store listing experiments let you test different icons, screenshots, feature graphics, and descriptions against the current listing.
• Apple: product page optimization lets you test alternative icons, screenshots, and previews on your product page.

Ground rules for useful tests:

1. Test one variable per experiment, so the result has a clear cause.
2. State a hypothesis beforehand, for example that a benefit headline will outperform a feature label.
3. Run the test long enough to cover your normal weekly cycle and to reach a clear result, rather than ending early when one variant leads. The consoles show their own confidence indicators; follow their guidance.
4. Record the outcome in a shared log, including losing variants, so you do not repeat them.
5. Apply the winner only after reading the details of the result, not just the headline figure.

The limits on how many tests you can run, and which assets are testable, are set by the stores and can change. Check the current options in each console.

What not to claim

Store policies prohibit misleading information, and users punish it in reviews. Keep to the following:

• Do not show features the app does not have or content it does not include.
• Do not display awards, rankings, or endorsements you have not received, and keep any real ones current.
• Do not imply affiliation with a brand, a platform, or a government body.
• Do not promise outcomes such as earnings, medical results, or guaranteed performance. Apps in sensitive categories deserve extra caution; our guide on cycle tracking privacy shows how seriously regulators treat health claims.
• Do not use rating stars, “number one” badges, or price tags in the icon or screenshots unless the store’s rules explicitly allow them.
• Do not use screenshots from a different version that looks materially different from what installs.

Read the current metadata and store listing policies in Play Console and the App Review Guidelines in App Store Connect before you finalise assets.

Keeping visuals current

Screenshots age. Update them when the interface changes, when a new platform design language appears, or when your pitch changes. Add a visual check to the release routine, and for portfolios, use a shared design template so a set of apps looks cohesive without being identical. The portfolio checklist shows how to store assets and review dates in your inventory.

For a wider view of what drives installs, see the organic install checklist, and for other topics aimed at app owners visit the publishers hub.

Quick production checklist

• Icon legible at small size, on light and dark backgrounds.
• First three screenshots tell the whole story in order.
• Captions short, readable, and benefit-led.
• Sample content realistic and free of real personal data.
• Localised sets for priority markets.
• One experiment running at a time, with a recorded hypothesis.
• Every claim verifiable in the shipped app.