How to Create App Store Screenshots That Convert: Sizes and Rules

In short, this is a sales sequence more than a design task. In this guide, Talha Aslan and team walk through the App Store and Google Play rules using official sources. Start with a quick check:

1. If your first frame shows a splash screen or a login page, replace it with the most valuable screen in the app.
2. Remove prices, "best" claims and phrases such as "download now" from your images.
3. Retake any screen that shows notifications, a carrier name or a low battery icon.
4. If you publish in more than one language, translate the text inside the images too.
5. Finally, plan a store test so data, not guesswork, picks the winner.

Why do app store screenshots drive the download decision?

Because people see your store page before they ever try the app. Most visitors skip the description, while the images take up the largest part of the page. That makes app store screenshots the first, and often the only, chance to explain the product.

Apple gives a clear hint here. According to Apple's product page guidance, when an app has no preview video, the first one to three images also appear in search results. The orientation of your images decides how many show. In other words, your opening frames compete side by side with rival apps right in the search list.

On the other hand, screenshots do more than grab attention. They also set expectations. If people cannot find the experience they saw in the images, they tend to delete the app quickly. So a strong set affects both installs and early retention. We cover the first-run experience in our guide to designing an app onboarding flow.

What are the App Store screenshot sizes and rules?

Apple's App Store Connect screenshot specifications list the basics. You can upload at least one and up to ten screenshots per device size. Files must use .jpeg, .jpg or .png. In addition, images cannot include alpha channels or transparency.

For sizes, Apple groups screens into device classes. For example, one accepted portrait size for the large Dynamic Island class is 1320 × 2868 pixels. If your app supports iPad, Apple also asks for the 13 inch iPad class; one accepted portrait size there is 2064 × 2752 pixels. The same table shows which class you must provide and which ones fall back to a larger class.

One rule saves real time. If your UI stays the same across device sizes and languages, you only need images at the highest required resolution. App Store Connect then scales them down for you. However, Apple updates this table as new devices arrive, so always check the current list before you upload.

Finally, guideline 2.3.3 asks that screenshots show the app in use. Title art, a login page or a splash screen alone will not do.

What are the Google Play screenshot requirements?

Google collects its rules on the Play Console preview assets help page. To publish, you need at least two screenshots across device types. You can add up to eight per supported device type.

Files must be JPEG or 24 bit PNG with no alpha channel. The shortest side cannot drop below 320 pixels, and the longest side cannot exceed 3840 pixels. Also, the long side can be at most twice the short side. That ratio rule rules out very tall "panorama" images from the start.

There is also a promotion tier. For some Google Play formats that use screenshots to recommend apps, Google wants at least four images at a minimum resolution of 1080 pixels. That means 9:16 portrait at 1080 × 1920 or more, or 16:9 landscape at 1920 × 1080 or more. Missing this tier will not break your listing; still, Google says it may limit promotional opportunities.

Large screens such as tablets and Chromebooks follow a separate rule. There, each side should fall between 1,080 and 7,680 pixels, and Google asks for at least four screenshots.

How do the App Store and Google Play rules differ?

Both stores aim for the same thing, yet they differ in the details. The table below puts the main differences from the official help pages side by side. Numbers can change, so check the live pages before each upload.

The practical lesson is simple. You can export both stores from one design file, but you still need to plan ratios and counts separately.

Why are the first two screenshots the most important?

Because most people never scroll the store page. The frames that fit on the first screen must explain what your app does at a glance. Apple showing the first few images in search results makes those frames twice as valuable.

So put the answer to "what do I get?" in the first two frames. The first frame should show the core benefit. The second frame should show the key feature that makes that benefit possible. For example, a booking app could open with the idea "Book in two taps" and follow with a calendar screen full of open slots.

Meanwhile, spending the first frame on brand storytelling is tempting, yet it usually wastes space. Your logo already lives in the icon. We explain how the icon does its own job in our app icon design guide. Give the first two frames to the product itself and leave brand lines for later frames.

How do you know if your first two frames work? Try a simple test. Show only those two frames to someone who has never seen your app for three seconds, then ask what the app does. If the answer matches your message, you are on track. If not, change the first screen or its caption. This quick check filters out weak ideas before you spend traffic on a store test.

How should you order your screenshots?

Treat the order like a story. Apple's product page guidance also suggests that each image focus on one main benefit or feature. That way people see the full value of the app as they scroll. We use this order as a starting point on projects:

1. Core benefit: the strongest screen, showing the problem the app solves in one line.
2. Key feature: the main function that delivers that benefit.
3. Ease of use: a flow screen that shows how few steps the task takes.
4. Personalization: settings, favorites or content tailored to the user.
5. Trust: secure checkout, data protection or support.
6. Extras: notifications, Dark Mode or the tablet layout.

This list is a starting point, not a template. As an example scenario, picture a food ordering app. There, the "ease" frame could show order tracking, while the "trust" frame could show the payment screen. Therefore, always adapt the order to how your own users make decisions.

Apple also recommends that if your app supports Dark Mode, at least one image should show that experience. Placing it near the end of the set works well in most cases.

How do you write captions for app store screenshots?

A caption is the short benefit line you place above or below the screen. On app store screenshots, that line explains what the screen shows within seconds. So write it like a road sign, not like an ad slogan.

Google Play suggests a clear limit here: taglines should take up no more than 20% of the image. It also asks you to avoid small text and busy backgrounds behind text. In practice, a good caption has these traits:

• It opens with a verb or a concrete benefit: "Save receipts with one photo."
• It stays short enough to read at a glance on a phone.
• It matches the screen below it and does not promise a different feature.
• It avoids hype such as "best", "number one" or "free".

We cover the broader rules of short, clear microcopy in our UX writing guide. The same principles apply to store images. Also keep captions aligned with the key ideas in your store description, so the promise people read in the image shows up in the text too.

Which design choices make screenshots easier to read?

The first choice is contrast. Your caption needs to stand out from its background; white text on light gray simply disappears on a phone. The second choice is type size. Store images make their first impression small and scaled down, so text that looks comfortable in your design file can turn tiny on a phone.

The third choice is the device frame, and here the stores differ. Google Play lists device imagery among things to avoid in screenshots. Apple, on the other hand, wants to see the app in use and allows text and image overlays. That is why we start Google Play sets with a clean, frameless layout.

Next, use the same color system, the same typeface and the same caption position across the whole set. As a result, the images flow like one product page when people scroll. Build the palette from the app itself; a gap between the store images and the opened app hurts trust.

Finally, review every frame on a real phone at small size. A layout that looks perfect on a design canvas can feel very different in the store list.

What content causes problems in screenshots?

Both stores take a firm line on misleading or irrelevant content. Guideline 2.3.7 of the App Store Review Guidelines says metadata such as screenshots and previews should not include prices or unrelated terms. Guideline 2.3.10 adds that you should not include names, icons or imagery of other mobile platforms in your metadata.

Google Play gives a more detailed list. According to its preview assets page, you should avoid the following:

• Words that suggest ranking, awards, testimonials, pricing or promotions, such as "Best", "#1", "Top", "New", "Free" or "Sale".
• Calls to action such as "Download now" or "Try now".
• Time sensitive content that goes out of date quickly.
• Third party trademarks or logos without permission.
• Google Play or other store badges and icons.
• Blurry, stretched, pixelated or heavily compressed images.

Take these rules seriously for trust, not only to avoid rejection. We list the most common rejection reasons in our post on why apps get rejected, and metadata issues come up often there.

How do you clean up the status bar and demo data?

Google Play clearly recommends a clean notification bar: no notifications or carrier names, plus full battery, Wi-Fi and cell icons. Apple has no list this detailed. Even so, the same cleanup looks more professional in both stores.

Demo data matters as much as the status bar. An empty list, a "Test User" name or filler text makes the app feel unfinished. So before you capture anything, set up a demo account and fill it with realistic data. Example scenario: for a budgeting app, you prepare sensible expense items, consistent dates and a balanced chart.

However, never use real people's data in demo content. Real customer names, phone numbers or email addresses have no place in store images. Invented but realistic names, addresses on example.com and consistent content work fine.

Most teams repeat this work by hand for every release. Instead, connect screenshot capture to your automated UI test flow. Then every release produces the same clean result, which saves a lot of time on multilingual projects.

How do you localize app store screenshots?

Localization goes beyond translating the captions. You rebuild app store screenshots for each market with that market's language, date and currency formats, and user expectations. Both Apple and Google recommend localizing images for every market you serve.

In practice, handle three layers separately:

1. Text layer: rewrite the caption in the target language instead of translating it word for word. Languages with long words, such as German, change your line breaks.
2. Interface layer: the app inside the screenshot should run in that language too. An English caption over a Turkish interface looks inconsistent.
3. Content layer: names, currency and examples in the demo data should fit that market.

Apple also notes that when a localized asset is missing, the store uses the next best available language. That is a safety net, not a strategy. For instance, a German store page that shows English images looks weak next to local rivals. We explain how localization fits into wider ASO in our app store optimization (ASO) guide.

Can a preview video replace screenshots?

No, but it can strengthen them. Apple's app preview specifications allow up to three previews per device size and language. Each must run between 15 and 30 seconds. Files can reach 500 MB, and previews always appear before screenshots.

Apple also says previews autoplay with muted audio on the product page. Therefore, the first seconds need to make sense without sound. Guideline 2.3.4 allows only video screen captures of the app itself in previews, though you can add narration and text overlays.

On Google Play, you add a video through a YouTube link. Google says the video must be public or unlisted, free of ads, not age restricted and embeddable. It also recommends showing the real app experience within the first 10 seconds and keeping the video short, since only the first 30 seconds autoplay.

In short, treat video as a shop window in front of your screenshots, not a replacement. Without a video, your first images take over that shop window role.

What does the Google Play feature graphic do?

The feature graphic is a horizontal promo image that Google Play uses in some placements. Google lists a required size of 1024 × 500 pixels, in JPEG or 24 bit PNG without alpha. The App Store has no equivalent, so teams often leave it to the last minute.

Google gives a few clear tips for this graphic. Keep key visuals near the center and away from edges that may get cut off. Pick vibrant colors, because pure white, black or dark gray blends into the store background. Also avoid fine details and prominent branding that repeats your icon.

In addition, Google suggests alt text of 140 characters or less for the feature graphic. That text describes the image for people who use screen readers. So write it as one short, natural sentence about the image, not as a keyword list.

How do you test screenshots with store listing experiments?

Google Play Console store listing experiments let you compare versions of your store page with real visitors. Google defines two types. A default graphics experiment tests the icon, feature graphic and screenshots on your default language listing. A localized experiment covers up to five languages you choose and can also test descriptions.

For each app, you can run one default graphics experiment or up to five localized experiments at the same time. You can add a small number of variants against the current listing; check the help page for the current limit. Target metrics include options such as unique user install clicks.

You also set the confidence level and the minimum detectable effect. Google notes that experiments stop automatically after six months. A good start for a screenshot test looks like this:

• Change only the first two frames and keep the rest of the set fixed.
• Test one idea per variant, such as a different benefit line or a different first screen.
• Wait to apply a result until the "more data needed" status clears.

How does App Store product page optimization work?

Apple's counterpart is product page optimization. With it, you can test icons, screenshots and app preview videos. According to Apple's documentation, a test can include up to three treatments against your original page and can run for up to 90 days.

You choose the traffic share, and Apple splits it evenly among treatments. For example, if you allocate 40% to two treatments, each gets 20% and the original page gets 60%. Each person sees the same treatment for the whole test. Also, only one test can run at a time, and you cannot change a test after it starts.

One more detail matters. Any new metadata in treatments needs App Review approval before the test goes live. If you want to test alternate icons, those icons must ship inside the published app binary, which often means a new version. Tests that only change screenshots can move forward independently of a new version.

Results appear in App Analytics in App Store Connect. Apple recommends waiting until at least one treatment shows a result with at least 90% confidence before you apply it or stop the test.

How should you read test results?

First, accept that small gaps are often noise. A variant can lead in week one and fall behind in week two. That is why both stores show a confidence level on the results screen and advise against deciding without enough data.

Take a sample calculation: the original page converts at 30% and the new variant at 31%. With low traffic, that one point gap may not be a real gain. You can check your own numbers with our A/B test calculator to see whether the difference holds up statistically.

On the other hand, keep watching after you apply a winner. An image that lifts installs but sets the wrong expectation tends to come back as low ratings. We explain how to ask for ratings within the rules in our guide to app ratings and reviews. In short, read conversion rate together with ratings and retention.

Step by step screenshot production process

To turn theory into practice, we follow this sequence on projects. It works for the first launch and for later updates:

1. Read the current official store pages and list your target sizes.
2. Reduce the reason to download into one sentence; that sentence becomes the first caption.
3. Sketch a story order of six to eight frames on paper.
4. Fill the demo account with realistic data and clean the status bar.
5. Capture screens at the highest required resolution.
6. Write captions, then check readability on a phone at small size.
7. Localize text and interface for each market.
8. Upload the images and confirm the order in the preview.
9. Start a store test for the first two frames.

File structure matters here as well. Keeping a separate folder for each language and device class helps you see at a glance which image is live where in later releases.

What are the most common screenshot mistakes?

The mistake we see most in practice is spending the first frame on a splash screen or a logo. Apple's guidelines already say that title art, login and splash screens alone fall short. The second common mistake is overloading images with text; people in the store look rather than read.

The third mistake is showing a feature the app does not have, or drawing the interface differently from reality. That brings rejection risk and also damages trust. The fourth is creating images once and never updating them. As the interface changes, old images stop telling the truth.

Finally, do not forget download size and speed. Screenshots do not change your app size, yet a heavy app package can waste the interest your images create. We look at this in our post on whether app size affects downloads. To sum up, good images are the shop window of a good app; they cannot rescue an unfinished one.

Who should build your app and its store page?

Screenshot work stays weak when you treat it apart from the app itself. Images come from the interface, and when the interface changes, the images must change too. That is why the most consistent result comes when the team that builds the app also plans the store page.

At Talha Aslan and team, our mobile app development service covers designing and building your app, and we also handle the store launch. The screenshot set, preview video, localization and store tests are part of that process. As a result, your images speak the same language as your app with every release.

If you want a full plan that includes your store page, request a quote for your mobile app project. We discuss scope, target markets and languages, then prepare a quote tailored to your project. Put simply, we build your app and we take it to the stores.