App Store Screenshot Design: First 3 Screenshots, Frame Size, and Copy (2026)
By Yogesh Devaliya
Published · Last updated
I want to be straight about what this post is.
It is not a conversion study of 100 apps. We did not run store A/B tests on a hundred listings and we are not going to invent percentages to look like we did.
What this is: a layout and copy guide for App Store and Play Store screenshots. The rules of thumb come from three places: official store specs, named ASO experiments that anyone can go read, and patterns you can see with your own eyes in public listings, including the sets we keep in ScreenVault.
Where a number has a source, I will name it. Where something is just craft (frame height, type size, spacing), I will say that too.
Why the first few screenshots get almost all of the attention
You do not need a mysterious industry stat to see this. Open the App Store, search for almost any category, and look at a result card. You get the icon, the name, the rating, and a couple of screenshots. The rest of the gallery is behind a tap.
Google Play is explicit about the same idea for featured placements: stylized screenshots are allowed, but you should prioritize UI in the first three screenshots.
Source: Google Play graphic asset requirements
The one hard scroll number people keep quoting comes from a single A/B test, not from Apple. In the ŠKODA Little Driver experiment (Bamboo Apps, published on Sensor Tower), the average screenshot scroll rate was 17%. In that test, most visitors never moved past the first visible screenshot. Reordering screenshots and changing backgrounds moved installs by up to 16.6%.
That is a useful data point. It is also one branded game, one test, one team. Treat it as evidence that the first frame matters a lot. Do not treat 83% as a law of nature.
Source: Sensor Tower / Bamboo Apps case study
Visual first impressions are fast. Lindgaard, Fernandes, Dudek, and Brown (2006) found that people form stable ratings of website visual appeal in as little as 50 milliseconds. That paper is about homepages, not store listings. The takeaway still holds in a weaker form: the screenshot is judged as a picture long before anyone reads your description.
Source: Lindgaard et al., Behaviour & Information Technology, 25(2), 115–126.
Practical consequence: spend most of your time on frames 1 to 3. Frames 4 to 8 are for people who are already interested.
Section 1: The layout inside the canvas
Most screenshot advice stops at pixel dimensions. The decision that actually makes a set look finished or cheap is the proportion of device, headline, and empty space.
There is no Apple or Google spec for this. What follows is a working template that keeps the UI readable at search size and leaves room for a headline.
Device frame: start at 60–70% of canvas height
If you use a device mockup (most non-game apps should), try this:
Under ~50% of canvas height. The phone looks like a sticker on a poster. The UI inside it is too small to parse in a search thumbnail.
60–70%. The device is the visual anchor. There is still room above for a headline that stays readable when the whole image is shrunk.
Above ~75%. The frame crowds the canvas. Headlines get squeezed onto the UI, which is the fastest way to make both the words and the app harder to see.
Exception: a later frame whose only job is showing dense UI (a map, a dashboard, a table) can go larger and drop the headline. That is a supporting frame, not Screenshot 1.
App Store canvas vs Play Store canvas
The iPhone 6.9“ screenshot slot is a tall portrait. Apple currently accepts 1320×2868, 1290×2796, and 1260×2736. All of those sit around 9:19.5.
Google Play’s featured-phone portrait is 9:16, with 1080×1920 as the usual minimum for those placements.
Same 65% frame rule on both. Very different leftover space.
On the taller App Store canvas, 65% for the device leaves a comfortable headline band. On Play’s shorter 9:16 canvas, that same percentage eats more of the remaining space. If you copy an iOS layout onto Play without adjusting, headlines clip and margins collapse.
Two Play-specific rules from Google, not from us:
- For Wear OS, device frames are not allowed. Screenshots must show only the watch UI.
- For phone screenshots that you want eligible for featured placements, Google asks you to keep taglines to no more than 20% of the image, put real UI in the first three frames, and avoid extra device photography (hands, physical phones) that can date the listing. A simple outline frame is still common for phone listings. It is required to be absent on Wear OS.
Source: Apple screenshot specifications · Google Play graphic asset requirements
Type size is a thumbnail problem
In search, the screenshot is small. Designers review at full canvas size, then wonder why the headline died in the grid.
A practical floor (this is production craft, not a lab result):
| Text element | App Store canvas (e.g. 1290×2796) | Play Store canvas (1080×1920) |
|---|---|---|
| Primary headline | 72pt minimum, 80–100pt is safer | 60pt minimum, 72–90pt is safer |
| Supporting line | 40–48pt | 36–44pt |
| Badge / label | 32pt | 28pt |
| Anything smaller | Skip it | Skip it |
The test is not the Figma zoom. Export the frame, shrink it to about 200px wide, and read it from a normal viewing distance. If the headline fails that test, it does not belong on the screenshot.
Weight matters as much as size. At thumbnail scale, Regular weight turns into a gray smear. Bold (700) is the floor. Heavy / Black (800–900) is what most clean listings use for the main line.
Google’s own wording is blunt: avoid overloading the screenshot with small type or backgrounds that compete with the text. Those details will not be visible on many phones.
Padding
Keep a consistent outer margin of about 5–8% of canvas width. On 1290px that is roughly 65–100px. On 1080px, about 55–85px.
The gap between the headline and the top of the device should be at least as large as that outer margin. If the type sits on the bezel, the layout feels cramped even when every other choice is fine.
A starting zone map
App Store portrait (~9:19.5):
- Headline zone: ~15% of height
- Device frame: ~65% of height
- Bottom breathing room: ~15–20% of height
- Left / right margins: ~6% of width each
Play Store portrait (9:16):
- Headline zone: ~12–15% of height
- Device frame: ~65% of height
- Bottom: the rest, often tighter than iOS
- Same side margins
These are starting proportions. Games often run the art larger. Split layouts (text column + UI column) break the map on purpose. If you just need a default that does not look amateur, start here.
Nakxi’s screenshot generator templates are built around this kind of zone split for both stores, so the first structural decisions are already made if you would rather not start from a blank canvas.
Section 2: What Screenshot 1 has to do
Screenshot 1 appears in search, browse, and the product page. Every other frame is optional until someone taps.
Apple’s rule is not a suggestion. Guideline 2.3.3: screenshots should show the app in use, not merely title art, a login page, or a splash screen. Text and image overlays are allowed. Fake marketing art that hides the product is how listings get rejected.
Source: App Review Guidelines, 2.3.3
What well-made Screenshot 1s keep doing, across the public listings we look at:
One benefit-led headline. Not the app name. Not a slogan from the brand deck. A short outcome. “Pay anyone in seconds.” “Sleep better, starting tonight.” “One inbox for every account.”
Actual UI, large enough to read. The device is there so people can recognize the product, not as decoration.
High contrast between type and background. A 60% white headline on a photo looks fine at 1290px and disappears at 200px.
At most two text elements. One main line, maybe one support line. Price badges, star dumps, and feature lists in the same frame usually make a mess.
What weak Screenshot 1s keep doing:
- Logo as the hero
- Feature names (“Biometric Login”, “Dark Mode Included”)
- No UI at all
- A paragraph stacked across four lines
The gap is not taste. It is whether a stranger can tell what they get in one glance.
Section 3: Frames 1 to 3 as a sequence
The usual mistake is treating each screenshot as its own poster. The first three work better as one short argument.
Screenshot 1: the promise. The outcome.
Screenshot 2: the proof. The screen that delivers that outcome. If frame 1 says “Fall asleep in minutes,” frame 2 shows the session, the timer, or the sleep score. Not a lifestyle photo with no UI.
Screenshot 3: the reinforcement. A second reason. Ratings if they are real. A volume claim if it is true. A before / after if the product actually has one. Do not repeat frame 1 in different words.
| Frame | Job | What to skip |
|---|---|---|
| Screenshot 1 | State the outcome | Logo, tagline, feature list |
| Screenshot 2 | Show the mechanism | Decorative graphics with no UI |
| Screenshot 3 | Add proof or a second benefit | The same message as frames 1 and 2 |
Look at how careful finance listings tend to sequence this (Revolut, Wise, and similar). Frame 1 is usually clarity and trust. Frame 2 is a real product surface. Frame 3 is a credibility cue. That is an observation from public listings, not a claim that this sequence caused their download numbers.
Section 4: Copy length, and what we can actually say about indexing
There is no magic word count. There is a width constraint.
A 10-word headline at a modest point size becomes a gray bar at search size. 4 to 7 words for the main line is the range that still reads. A support line can go to about 12 words if it is smaller and you have already passed the 200px test.
Write like a person. Skip “seamlessly,” “effortlessly,” and “reimagining.” If you would not say it out loud to a friend, do not put it on the screenshot.
On indexing: be careful here, because the ASO internet overstated this in 2025.
- Apple’s public search documentation still lists title, subtitle, keywords, and category as the text relevance fields. Apple has not published a spec that says screenshot OCR is a keyword ranking factor.
- What Apple has said: screenshots are one input into App Store Tags and related discovery features. The pictures are part of how the store understands the app.
- Appfigures and others reported that after the June 2025 algorithm period, caption-like text in screenshots started showing up in keyword tools. That is industry observation, not an Apple help article.
- Google Play can use listing assets in promotion and discovery. That is not the same as “put keywords on the image and you will rank.”
Write screenshot copy for humans first. If it also happens to repeat a phrase already in your title or subtitle, that is fine. Do not stuff the image with keywords you would not show a user.
Source: Apple Product Page Optimization · Appfigures on the 2025 algorithm change
Section 5: Lock a small design system before you make ten frames
This is production discipline, not conversion science. Users see two or three screenshots side by side in search. If each one looks like a different file from a different week, the set feels unfinished.
Lock these before you design:
- One typeface (a geometric sans is the usual choice)
- One headline size, reused across frames
- One spacing grid (margin to device, gap between lines)
- Two or three colors, not a new accent per screenshot
Inconsistent mockup styles are in the same bucket. Flat outline in frame 1, 3D clay in frame 3, no device at all in frame 5. Pick one device treatment and keep it.
Section 6: Category conventions are real
You cannot copy a meditation layout onto a game and expect it to feel native. This is pattern-matching from public listings, not a ranked “what converts” table.
| Category | What top listings tend to show | What usually looks off |
|---|---|---|
| Finance | Quiet layout, clear numbers, trust language | Neon, animation-heavy frames, walls of text |
| Productivity | A finished task, a cleaner inbox, a saved hour | Abstract art, vague motivation |
| Fitness | Progress, a workout in progress, energy | A static chart with no hook |
| Games | Action in frame 1, actual gameplay | The menu screen |
| Utilities | One concrete claim (scan, protect, convert) | A feature grid in 8pt type |
| Travel | A real booking or trip surface, plus a place | Stock beaches with no app |
The common thread is a specific value moment, not the settings screen.
Section 7: Testing is how you get causal numbers
Everything above is directional. If you want numbers for your app, test.
Apple Product Page Optimization
- Up to 3 treatments against the original
- You can test icon, screenshots, and preview separately
- A test runs for up to 90 days, or until you stop it
- Apple recommends at least 7 days so you catch a full week of traffic
- “Performing better / worse” uses a 90% confidence threshold
- You do not need to wait 90 days. 90 days is the cap, not the minimum.
Google Play Store Listing Experiments
- You pick a traffic split and run a variant against the control in Play Console
Source: Apple Product Page Optimization · Google Play Store Listing Experiments
How big can a screenshot change be? It depends on the listing. The ŠKODA test above saw up to 16.6% more installs from order and background. SplitMetrics and others have published larger single-app lifts (including screenshot-only tests). Those are case studies, not a promised 10–20% for everyone. Change one variable per test so you know what moved.
Section 8: Failure modes that keep showing up
Logo-first. Brand advertising dropped into a performance slot. People arriving from search are choosing an app, not joining a brand.
Feature parade. Five bullets in frame 1, four different ones in frame 2. Nothing lands.
Raw simulator dump. No headline, no hierarchy. Fine as a source file. Weak as a store asset.
Mixed mockups. Three device styles in one set.
Only readable at full size. The 200px test would have caught it.
Short version
- Start the device around 60–70% of canvas height. Check the leftover space on both 9:19.5 (App Store) and 9:16 (Play).
- Screenshot 1: one outcome + real UI. Apple requires the app in use (2.3.3).
- Frames 1–3: promise, proof, reinforcement. Google asks you to prioritize UI in those three for featured placements.
- 4–7 words on the main line. Pass a ~200px-wide preview before you export.
- One typeface, one size scale, one palette, one device style.
- Respect the category. Finance wants calm. Games want the action.
- Test Screenshot 1 copy first in PPO or Play experiments. One change at a time.
If you want this structure without rebuilding it in a general design tool, Nakxi’s App Store screenshot generator has the platform sizes and templates already set. It is a faster start than a blank Figma file, especially with more than one locale.
Related posts
- App Store Screenshot Size Guide for 2026
- Most Common App Screenshot Mistakes (2026)
- How to Write App Store Screenshot Copy That Increases Downloads
- App Screenshot Benchmark Research: Methodology
- App Store Screenshot Templates
Sources
- Apple — Screenshot specifications
- Apple — App Review Guidelines, 2.3.3
- Apple — Product Page Optimization
- Google Play — Graphic assets and screenshot requirements
- Google Play — Store listing experiments
- Bamboo Apps / Sensor Tower — ŠKODA Little Driver screenshot A/B test (17% scroll rate; up to 16.6% install lift)
- Lindgaard, G., Fernandes, G., Dudek, C., & Brown, J. (2006). Attention web designers: You have 50 milliseconds to make a good first impression! Behaviour & Information Technology, 25(2), 115–126.
- Appfigures — 2025 App Store algorithm notes (industry observation on screenshot captions, not an Apple spec)
- Incipia — App Store screenshots study of the top 100 apps (older pattern study of public listings; rank correlations, not causal conversion)
FAQ
Do screenshots affect App Store rankings directly?
Not as a keyword field the way title and subtitle do. They affect conversion, and conversion is one of the signals both stores use when deciding what to show. Higher conversion can feed better placement over time. Screenshot text as a ranking keyword is not something Apple documents. Treat captions as conversion copy first.
Should you always use device mockups?
For most phone apps, a simple frame helps people recognize that they are looking at a phone product. Skip heavy device chrome if it fights the UI. Do not use frames on Wear OS Play listings. Google also prefers UI-first screenshots for some featured phone placements. If you are unsure, test framed vs UI-only.
Is it worth designing separate screenshots per locale?
If you have the traffic and the production time, yes. Localizing the overlay text (not only the description) is the part that usually matters first. Full cultural reshoots are extra. I have not attached a single lift percentage here because the published numbers vary by market and app.
How often should screenshots be updated?
When the product in the screenshots no longer matches what a new user sees after install. That mismatch shows up later as churn. Beyond that, run a Screenshot 1 test when you have enough traffic to finish a PPO or Play experiment cleanly.
What is the fastest change to try today?
Open Screenshot 1. Ask if a new user can say, in one short sentence, what they will be able to do after installing. If that takes an explanation, rewrite the headline and test it. That is usually the highest-leverage move that does not require a new design system.