App store screenshots and preview videos: how to plan and make them

The short answer

Plan app store screenshots as a short story: the problem, the main action, the result. Put your strongest screen first, add brief captions, use real screens from the current version, and prepare sets for each device type and language. Check the current Apple and Google documentation for exact sizes and limits before exporting.

What the images are for

On both Apple's App Store and Google Play, the screenshots and any preview video sit beside the name and description. A visitor deciding whether to install scans these before reading much text. Their job is simple: show what the app does, who it is for and why it is worth trying, in a few seconds.

They are not decoration, and they are not a place for claims you cannot support. Every image should represent the app as it really is, because a mismatch between the store page and the real app leads to bad reviews and, in some cases, a rejected update. The guide to why apps get rejected lists the metadata problems reviewers look for.

Plan the story before you open a design tool

Write a one-line summary of the app for a stranger, then choose the three to five moments that prove it. A shared template makes this easy to review:

1. Screen one: the main benefit or the most-used action, since this is the image most people will see.
2. Screens two and three: the steps that make the first benefit work.
3. Later screens: secondary features, trust points such as sync or privacy controls, and anything that sets the app apart.

Choose screens in which the app looks as if it is being used, with believable sample content and not empty states or placeholder text. Do not include real customer data. If you show a profile or a message, invent a person who does not exist and use a made-up name.

If your app has an onboarding flow worth showing, consider whether it helps a buyer or only repeats what the store page already says; the guide to designing the first screens can help you decide.

Captions and layout

Many apps place a short caption above a device frame. Keep captions to a few words that name a benefit in plain language, such as "Plan your week in one view". Avoid jargon and avoid repeating the app name on every image.

• Use large, high-contrast text; many viewers see the image at thumbnail size on a phone.
• Keep the key part of the screen away from the edges, where it may be cropped in a different layout.
• Use one consistent style across the set, but do not make every image identical.
• Do not cover the interface with decoration that hides what the app looks like.
• Do not show features that are not in the version being reviewed.

Text embedded in an image cannot be translated by the store, so each language needs its own set. Remember that captions in an image are not read by screen readers; put the same meaning in your written description. For general accessibility points, see mobile app accessibility basics.

Apple and Google: what is different

Both stores accept screenshots, and both let you add video. The rules differ in the details, and those details change, so check the official pages when you export.

Do not rely on an old blog post for pixel sizes. The platform pages list the accepted dimensions, file types and maximum number of images, and they are updated when new devices appear. Ask your developer to export from the official specification at the time of release.

Preview videos

A short video can explain a flow that a still image cannot, such as scanning, drawing or a live map. On Apple's store the preview is meant to show the app in use, so record the real app instead of animating a mock-up. Show the main action within the first moments, because many people will not watch to the end, and make the video understandable with the sound off.

Do not add celebrity images, prices that may change, or claims such as "best" and "number one" that you cannot substantiate. If you use music, make sure you have the right to use it. Re-record whenever the interface changes enough to mislead.

Localise and test

If you list the app in several countries, translated captions and locally relevant sample content make the page feel written for the visitor. A date format, currency symbol or example address that looks foreign can undermine trust. Our guide to app localisation basics covers this in more depth. Note the right-to-left layout needs for Arabic if you serve the UAE, and the line-breaking behaviour of Japanese text.

Both stores offer ways to test alternative store pages; see the current documentation for each. Treat any result as a clue about your own audience, not as a universal rule, and change one element at a time. A good listing also invites honest reviews; how to get app reviews and ratings follows on from this.

Keeping the images accurate over time

Store images go out of date quickly. Every redesign, renamed feature or new icon makes the old screenshots slightly wrong, and a visitor who notices the difference after installing may leave a poor review.

• Keep the source files, not just the exports, in a shared folder owned by the business.
• Add a line to your release checklist: do the screenshots still match the app?
• Use a script or template for sample data so each new set uses the same believable content.
• Record who approved the images and when, especially if a regulated product such as health or finance is involved.
• Review the set after each major operating system release, because the interface of the phone around your app changes too.

You do not have to replace the whole set for every update. Change only the screens that no longer match, and keep the first image strong. When in doubt, compare the store page and the installed app side by side on a real phone.

Checklist before you upload

• Every image shows the current version of the app.
• No private data, real names or real email addresses appear.
• Text is readable at thumbnail size.
• The first screen explains the main benefit.
• Each language has its own set.
• Sizes and formats were taken from the latest official specification.
• The captions match the written description and the privacy details; see privacy labels and data safety forms.
• The set is saved in an editable file so it can be updated for each release.

Screenshots are part of release planning, not an afterthought. If you want a team to design, build and prepare a launch listing, see our mobile app development service.

Related guides

• Mobile app development
• App Privacy Labels and Data Safety Forms Explained
• App Beta Testing: TestFlight and Google Play Testing Explained
• App store optimisation basics
• Ecommerce website vs mobile app for your store
• What to build in the first version of your app

Questions and answers

How many screenshots should an app have?

Enough to tell the story of the app, often a handful that cover the main benefit, key steps and distinguishing features. Each store sets its own minimum and maximum, so check the current documentation before you plan the set.

Which screenshot matters most?

The first one, because it is the image most visitors see. Show the main benefit or the most-used action with a short caption, and use believable sample content.

Can I use mock-ups instead of real screens?

Device frames and captions are fine, but the screen content should reflect the real app. Showing features that do not exist can cause a rejection and unhappy reviews.

Do I need an app preview video?

No. It is optional on both stores. It is useful when motion or a flow is hard to show in still images. Make it understandable without sound and keep it current.

Do I need different screenshots for each language?

If captions are part of the image, yes. Prepare a set for each language you list in, and adapt sample content such as dates, currencies and names.

What sizes should I export?

Sizes change over time and differ for each device type, so use the official Apple and Google specification at the time of release. Do not rely on older articles.