← All

App store screenshots that drive installs

App store screenshots that drive installs

You built the app and uploaded it. Now it sits in the store with a trickle of downloads while competitors with worse products pull ahead. The gap between a good app and a profitable one often comes down to what users see before they ever tap "Get."

The fix is rarely a redesign. It is getting the exact specifications, design rules, and free testing tools right so store browsers turn into installers. Below, you will find what Apple and Google actually require, how the two platforms differ in ways most builders miss, and how to A/B test your screenshots without spending a dollar.

Developers see a 2.5 point lift in conversion rate when they tailor product page visuals to specific audience segments.

Effective app store screenshots follow platform-specific rules that most solo builders either ignore or get wrong, and fixing them is one of the highest-impact changes you can make before your next release.

Your first three screenshots carry most of the weight

The first one to three screenshots appear in search results when no preview video is present. Screenshots four through ten only appear after a user taps into your full listing.

Screenshot one must answer a single question at thumbnail scale: "What does this app do for me?" Screenshots two and three support that answer. Everything after that tells the deeper feature story for users who are already interested.

The two stores do not surface visuals the same way, which means each platform demands its own layout decisions.

Google Play works differently

On Google Play, the feature graphic, not screenshot one, is a prominent asset users encounter in browse and search contexts. Screenshots sit below it on the listing page. If you are publishing on both platforms, design your Apple screenshots and your Google Play feature graphic as separate, primary conversion assets.

Your first screenshot is not a place to show off your settings screen.

Get the specs right before you design anything

Bad dimensions create rejection risk and wasted design work. Once you know the constraints, you can design assets that survive review and look right in the store.

Wrong dimensions or formats can lead to:

  • cropping
  • rejection
  • weaker conversion

Apple App Store

Upload portrait screenshots at 1290×2796 pixels or 1320×2868 pixels for the largest iPhone display in App Store Connect. App Store Connect automatically scales this size down for smaller devices.

For iPad, upload at 2064×2752 pixels for the 13-inch display. Accepted formats are .jpeg, .jpg, .png, or .apng. You can upload multiple screenshots per device size per localization.

Google Play Store

Google Play does not mandate one exact screenshot size, but it does require screenshots to be between 320 px and 3840 px on each side and within allowed aspect ratios. Official guidance specifies explicit minimum and maximum pixel dimensions and file formats for screenshots, rather than just saying they must be "high resolution".

You need screenshots across device types to publish. Verify file format acceptance and current limits directly in Play Console at submission time.

Content rules both stores enforce

The content inside the frame matters as much as the file you upload. Polished visuals can still trigger review issues if what they show violates store rules.

Guideline 2.3.3 explicitly prohibits:

  • login screens
  • splash screens
  • title art

Google Play also prohibits ranking indicators, promotional pricing, and misleading depictions of functionality.

Design rules from official platform guidelines

Passing review is the starting line, not the finish. Once specs are locked, each screenshot needs to do one clear conversion job so users can read your message, trust what they see, and decide to install.

Text overlays: platform rules diverge

App Store review guidelines permit overlays as tools that highlight the user experience. Overlays must highlight, not obscure, the UI. Google Play takes the opposite stance, instructing developers to "keep text minimal" and use taglines only when absolutely necessary.

Do not reuse text-heavy Apple screenshots on Google Play without redesigning them.

Legibility on busy backgrounds

A 2025 conference session covers a useful technique: when text overlays a busy or high-contrast image, add a subtle gradient or blur behind the text. Caption text should occupy a distinct layer above the UI, separated by contrast and spatial positioning.

Screenshot ordering

Order screenshots by feature importance, not by the sequence features appear in your app. Product page guidance instructs developers to showcase features in each screenshot.

Show actual UI

Your screenshots need to show the app in use. Apple's review guidelines require that screenshots show the app "in use," and Google Play requires that screenshots accurately represent the app's current functionality and content.

Lifestyle imagery can provide context, but pure lifestyle photos without visible app UI do not satisfy this requirement and may create review risk.

Localization changes the workload on Google Play

Text inside screenshots creates more assets to manage across languages. On Apple, screenshots are required for app submissions, but localized screenshots are optional and primarily improve product-page performance rather than keyword coverage.

Factor this operational cost into whether you add text overlays on Google Play at all.

Free tools that work without a design team

Use the lightest tool that gets assets shipped. The right tool does not make bad screenshots good, but it can cut repetitive resizing and export work across devices, localizations, and store requirements.

Zero budget, need it done today

AppScreenStudio is free with unlimited exports, no watermark, and no account required. Upload raw screenshots, select a template with device frames, customize headlines and backgrounds, and export required sizes automatically. It is a free option for getting screenshots out quickly.

Already using Canva for marketing

Stay in Canva. The free tier includes templates and basic export options. Magic Resize, which lets you resize one design across multiple formats in a click, requires Canva Pro.

Already using Figma for wireframes

The Figma Starter plan is free and includes access to community templates. Find a pre-built app screenshot template and limit your custom edits. Starting from a template is the simpler path.

When to automate

Automation starts to matter once every screenshot change multiplies across languages and device formats. That burden becomes an operational problem for solo builders fast.

How to A/B test screenshots with zero budget

Each store offers a built-in testing tool, but the workflow differs by platform. Knowing the limits up front leads to cleaner experiments and less wasted traffic.

Apple product page optimization

PPO lets you test icons, screenshots, and videos against your original product page. You can run one test at a time with up to three variants. Tests run for up to 90 days. Results appear in App Analytics.

Key constraints to know before you start:

  • You can not change a test once it starts.
  • Finalize all variants first.
  • Shipping a new app version while a test runs ends the test automatically.
  • Screenshot tests do not require a new app version if you are only swapping previously approved screenshots.
  • Apple requires at least one iPhone screenshot per PPO treatment, which reduces the asset burden compared with recreating every screenshot size.

Finalize assets before launch and avoid overlapping release work with a test.

Peak Brain Training was featured in product page optimization materials with an app icon test showing an 8% lift. A second test on the same page found that a product page without a preview video outperformed one with a video. Test your assumptions, do not trust them.

Google Play store listing experiments

Google Play's equivalent lets you test screenshots, feature graphics, and localized text descriptions. Unlike Apple, you can run multiple experiments simultaneously and test text metadata.

Practical rules for solo builders

A tight test structure is the only way to learn which change moved the result. Official guidance states: "consider how many elements you change in a treatment so you can more easily determine which one led to a particular result."

Change one variable at a time. For low-traffic apps, test two variants maximum. More treatments usually mean more time to reach confidence. Set your test duration before launch and do not stop early based on preliminary signals.

Show the transformation, not the feature tour

Lead with the user outcome. Most people do not install because they admire feature depth. They install because the screenshots make the result feel clear and worth trying.

Each image needs one main benefit. Benefits describe what the user gains, and features describe what the software does. Your screenshot captions should read like conversion copy, not a feature list.

Generate multiple caption variations per screenshot, each short and specific, then test the best performers.

If you already have working screens, you already have material to capture. Take real screenshots of your actual UI, frame them inside device mockups with benefit-driven captions, and upload them at the correct dimensions. That combination, executed well, puts you ahead of most listings in the store.

Start with your first three screenshots. Get the specs right, show the transformation your app delivers, and run a free A/B test within the first month. To move from app idea to publishing faster, explore Anything.