How to Design App Store Screenshots That Convert
Learn the exact sizes Apple and Google accept and how to design device-framed screenshots that turn browsers into downloads.
TCTechToolsCenter TeamYour app's screenshots are the single biggest driver of downloads on the App Store and Google Play — more than the description, more than the icon on its own, and often more than the star rating itself for a first-time visitor deciding in the space of a few seconds whether to tap "Get" or scroll past. Great screenshots tell a story, highlight one benefit each, and use the exact pixel sizes the stores accept — no oversized uploads, no rejections, no awkward stretching after the fact.
The exact sizes you need
Apple requires specific screenshot dimensions per device class — 6.9″ (1320×2868), 6.7″ (1290×2796), 6.5″ (1242×2688), 5.5″ (1242×2208) and iPad (2048×2732). Google Play accepts phone, 7″ and 10″ tablet screenshots at flexible aspect ratios, plus a mandatory 1024×500 feature graphic and, optionally, a 1280×720 TV banner for Android TV listings. Using an App Store Studio that renders at these exact sizes means your uploads are always accepted on the first try, instead of bouncing back with a dimension-mismatch error that costs you a resubmission cycle.
Sponsored
What makes a screenshot convert
- Lead with your strongest, most differentiated feature on the first screenshot — most visitors on both stores never scroll past the first two or three images.
- Add a short, benefit-led headline above each device frame — describe the outcome for the user ("Track every expense in seconds"), not the feature name alone ("Expense tracking").
- Use one idea per screenshot — don't crowd the frame with three features at once; a visitor skims each screenshot for under a second, and a cluttered frame communicates nothing in that window.
- Keep colours and fonts consistent with your brand across the whole set — an inconsistent set reads as unpolished even if each individual screenshot looks fine on its own.
- Show the app inside a realistic device frame for context — a bare screenshot with no frame looks more like a generic web page than a real, installable app.
Screenshot order strategy: what goes where
The order of your screenshots is a deliberate narrative decision, not just a gallery to fill. The first screenshot should answer "what is this app and why should I care" in under a second — your single best hook, not a generic splash or logo screen. The second and third should build the case with concrete features or outcomes, ideally in the order a new user would actually experience them. Social proof (a rating, a user count, a press mention) works well around the third or fourth position, once genuine interest is established rather than as the opening pitch. The final screenshot is a good place for a clear call to action or a summary benefit — something to close on, since it's often the last thing a scrolling visitor actually reads before deciding.
Localisation: a genuinely underused conversion lever
Both app stores let you upload separate, fully localised screenshots per market — not just translated app store descriptions, but different screenshot text, and even different feature emphasis, for different regions. An app with meaningfully different conversion rates across markets is very often losing conversions simply from screenshots that read as an afterthought translation (or worse, untranslated English text) rather than genuinely tailored to that market's language and cultural context. This is a real, measurable lever that a surprising number of apps never bother pulling, even though the infrastructure to do it is already built into both stores' listing tools at no extra cost.
Video previews: worth the extra effort
Both stores support a short video preview alongside static screenshots — typically capped at 15-30 seconds — and listings that include one commonly see meaningfully higher conversion than static-only listings, since a moving demo communicates an app's actual feel and flow in a way a still image can't. The practical trade-off is production effort: a video needs to be genuinely well-edited (fast cuts, real in-app footage, no dead time) to help rather than hurt, since a slow, unpolished video can lose a visitor's attention faster than they'd have spent skimming a couple of static screenshots. For a smaller team, prioritising a strong static screenshot set first, then adding a video preview once the app itself is stable and screen-recording it is trivial, is a reasonable sequencing.
A/B testing your screenshots
Both Google Play (via its built-in Store Listing Experiments) and Apple (via Product Page Optimization) let you run genuine A/B tests on your screenshot set against a live slice of real store traffic, measuring actual conversion-rate differences rather than guessing from opinion. This is worth using even for a small app — testing screenshot order, headline wording, or which feature leads first, on real visitors, routinely surfaces a winning variant that internal team opinion would never have predicted. It costs nothing beyond the time to set up the experiment and wait for a statistically meaningful sample.
A simple workflow that covers both stores
Capture clean in-app screenshots directly from the actual running app (not a mockup of a feature that doesn't exist yet — both stores can reject misleading screenshots), drop them into a device frame, add a headline and a branded background, then export every required size for both stores at once from the same source set. Pair it with a consistent brand kit — the same colour palette, font and logo treatment — so your visual identity carries across the whole listing, the app icon, and any paid ad creative you run pointing back to the same listing.
Common mistakes that quietly hurt conversion
- Screenshots that don't reflect the actual current app — an outdated UI in your screenshots, after a redesign, creates a jarring first-open experience that erodes trust immediately.
- Text too small to read on a store listing's thumbnail size — screenshots are often first seen as small thumbnails in search results, not full-size, so headline text needs to remain legible at a fraction of its actual display size.
- No clear narrative across the set — five screenshots that each show a different, unrelated feature with no build toward a single value proposition read as scattered rather than compelling.
- Skipping the feature graphic (Google Play) — this large banner appears in several prominent placements across the Play Store and is easy to forget since it isn't a "screenshot" in the traditional sense.
The short version: screenshots are a conversion surface, not an afterthought checkbox before submission. Getting the exact sizes right avoids rejections; getting the narrative, localisation and ordering right is what actually moves the download rate — and unlike most app-store-optimisation work, it's something you can test, measure and iterate on directly against real traffic.
How screenshots connect to broader App Store Optimization
Screenshots are one piece of a larger ASO (App Store Optimization) picture that also includes your app's title, subtitle/short description, keyword field (on Apple) and long description — but screenshots carry disproportionate weight because they're the first visual, low-effort thing a visitor actually engages with, versus text that requires actively reading. A technically well-optimised keyword set that ranks your app highly in search results is wasted if the screenshots that follow don't convert that visibility into an actual install — the two need to work together, not be treated as separate, unrelated tasks.
Seasonal and campaign-specific screenshot updates
Both stores make it easy to update screenshots at any time without a full app version release, which opens the door to seasonal or campaign-timed refreshes — a shopping app highlighting a festive-sale feature in October-November, a fitness app leading with a New Year's-resolution angle in January. This is a genuinely underused lever since it costs nothing beyond design time and can meaningfully lift conversion during exactly the windows when category-wide search traffic and competitor advertising spend both spike.
Competitor research before you design
Before designing a screenshot set, it's worth spending fifteen minutes looking at the top 5-10 ranking apps in your category on both stores — not to copy them, but to spot the visual and messaging patterns that category's users already expect (a fitness app's users expect to see progress charts and workout variety; a finance app's users expect to see security/privacy framing prominently). A screenshot set that ignores established category conventions entirely can look genuinely out of place next to what a visitor has already scrolled past, even if the design itself is well executed in isolation.
A worked example: refreshing an underperforming listing
A budgeting app has healthy search visibility (it ranks well for its target keywords) but a conversion rate well below its category average — visitors are finding the listing but not installing. Auditing the existing screenshots reveals the first three all show variations of the same dashboard screen with no clear headline text at all, relying purely on the visuals to communicate value. The fix: reorder around a clear narrative (screenshot one: the core value proposition as a headline over the dashboard; screenshot two: the specific standout feature, bank-sync automation, with a benefit-led headline; screenshot three: a security/privacy reassurance screen, since finance apps see this specifically raise conversion; screenshot four: social proof, a review count or press mention), run it as a Play Store Store Listing Experiment against the existing set for two weeks, and keep whichever variant wins on a large enough sample. This kind of structured, measured iteration — not a one-off redesign followed by hoping — is what actually compounds conversion gains over time.
Icon and screenshot consistency
The app icon is the very first visual a potential user sees, often well before they even open the store listing (in search results, in a "similar apps" carousel, in an ad). A screenshot set with a completely different colour palette or visual style from the icon creates a subtle but real disconnect once a visitor actually taps through — the promise made by the icon and the experience shown in the screenshots should feel like the same product, not two separately branded efforts.
Updating screenshots after a redesign
It's easy to ship a UI redesign and forget the store listing entirely — screenshots don't update themselves alongside a new app version, and a listing showing an interface that no longer matches what installs creates exactly the kind of first-open mismatch that drives an immediate uninstall from an otherwise interested new user. Building "update store screenshots" explicitly into the release checklist for any release that touches visible UI, not just as an afterthought once someone happens to notice the mismatch, closes this gap permanently rather than catching it reactively.
Accessibility considerations in screenshot text
Screenshot headline text should meet a reasonable minimum contrast and size even before accounting for a store's thumbnail-scaling, since a meaningful share of visitors browsing on a phone in bright daylight, on an older display, or with some degree of low vision will struggle with thin, low-contrast overlay text that looks perfectly fine on a designer's calibrated monitor. This isn't just a compliance nicety — it directly affects how many of your actual visitors can read the pitch you spent time crafting at all.
Reviewing screenshots against store guidelines before submission
Both Apple and Google publish explicit rules on what a screenshot can and can't show — no misleading claims, no unreleased features, no third-party logos without permission, no simulated device chrome that isn't the actual current OS style, and specific rules around depicting other apps or copyrighted material. A rejection at review for a guideline violation costs a full resubmission cycle (often days), so a quick pass against the current published guidelines before submitting — not just checking that the pixel dimensions are correct — is worth the ten minutes it takes.
None of this requires a big design team or budget — a clear narrative, the correct sizes, and a willingness to actually test variants against real traffic will outperform a beautifully designed but untested, unfocused set almost every time.
Tools used in this article
Sponsored
Frequently asked questions
Apple accepts 6.9″ (1320×2868), 6.7″ (1290×2796), 6.5″ (1242×2688), 5.5″ (1242×2208) and iPad (2048×2732). Rendering at these exact sizes avoids upload rejections.
TechToolsCenter Team
Product & Tools
The team behind TechToolsCenter — building fast, private, browser-based tools and writing practical guides on how to get the most out of them.
Related articles
What Is Lorem Ipsum, and Why Do Designers Still Use It?
It looks like Latin, it isn't quite Latin, and it's been the default placeholder text in design for over 500 years — literally. Here's where Lorem Ipsum actually comes from, why designers still reach for it over real sentences, and when it's the wrong choice.
Letterhead Design: What to Include (and What to Leave Off)
A letterhead is meant to be read past, not stared at — the best ones say who you are in the header and then get out of the way of the actual letter.
WCAG Color Contrast Explained: How to Pass Accessibility Audits
A contrast ratio isn't a vibe check — it's a precise formula, and WCAG sets hard numeric thresholds your design either passes or fails.