From Product UI to Store-Ready App Store Screenshots: A 7-Step Workflow

Your app took months to design and build. On the App Store and Google Play, most people will judge it in seconds, from a handful of images they see before they ever open the full listing. That makes app store screenshots one of the most important design assets you ship, and usually one of the most rushed.

The problem is rarely talent. It is process: screens exported one at a time, captions written the night before launch, sizes fixed by trial and error inside App Store Connect, and nothing left editable when the UI changes a few months later.

This guide lays out an app screenshot workflow that holds up after launch: seven steps from real product UI to store-ready screenshots, with the current App Store and Google Play screenshot requirements, the review rules that trip teams up, and a way to test what actually converts.

Short answer: to make App Store screenshots that work, start from real UI, not decoration. Give each screenshot one job, capture it with clean demo data, add a short benefit caption, build the whole set from one master layout, adapt it for each device and store, export the exact sizes each store accepts, then localize and A/B test. The first three frames matter most, because on the App Store they can appear directly in search results.

Why Raw Screenshots Undersell Your App

A raw capture shows the real product, which is exactly why it belongs at the center of every frame. On its own, though, it rarely explains why a feature matters. Someone scrolling search results has never seen your dashboard before and has no idea which number on it is the point.

Store-ready creative adds the missing layer. A headline explains the benefit. Consistent backgrounds, type and spacing connect separate screens into one set. Seen together, the frames become a short product story: the promise first, the main workflow next, then the features and proof that answer the remaining doubts.

What the creative should never do is hide the app. Both stores are explicit about this. Apple’s App Review Guideline 2.3.3 says screenshots should show the app in use, not merely title art, a login page or a splash screen, and Google asks for screenshots that show the actual in-app experience. Every step below serves that rule: make the real interface easier to understand, never harder to see.

Step 1: Plan One Job for Every Frame

Before you open a design file, write the story as a list. Each frame gets exactly one job, and the order follows the questions a new user asks: what is this, how does it work, why this one, and can I trust it?

Frame	Its one job	Example caption (fitness app)
1	The core promise	Your training, planned for you
2	The main workflow	Log a workout in two taps
3	The key differentiator	See your progress at a glance
4	A second major feature	Your plan, on your wrist
5	Personalization	Plans that adapt to your week
6	Trust or proof	Private by default

Front-load the plan. The first three frames carry most of the decision. Apple notes that, depending on orientation, the first one to three screenshots appear in search results when no app preview is available, and Google recommends prioritizing real UI in the first three. Later frames are for people who are already interested and want detail.

If your app supports Dark Mode, Apple suggests including at least one screenshot that shows it. Reserve that slot now rather than squeezing it in later.

Step 2: Capture Real Screens With Clean Demo Data

Screenshots are only as good as the state of the app you capture. Empty lists, placeholder names and a status bar at 12% battery make a polished product look unfinished.

• Seed a demo account. Use realistic but fictional names, photos and numbers, and show features in a finished state, such as a completed weekly plan instead of an empty one. Apple’s guideline 2.3.9 asks for fictional account information rather than data from a real person, and you need the rights to every image that appears.
• Clean the status bar. Google asks you to remove carrier names and notifications and to show full battery, Wi-Fi and signal icons. On the iOS Simulator, xcrun simctl status_bar booted override --time 9:41 sets a clean time, and Android’s System UI demo mode does the same job on Android.
• Capture at native resolution. Use the simulator or device that matches your largest export size so text stays sharp. Upscaling a small capture is the fastest route to the blurry, stretched look Google explicitly warns against.
• Keep a capture list. Note the device, locale, theme and app state for every screen, so you can recapture the exact same set after the next release.

Step 3: Write Captions That Sell a Benefit

Screenshot captions do the explaining the screen cannot. The test is simple: a feature name describes what is on the screen, and a benefit says why anyone should care. “Reports” identifies a feature. “See your progress at a glance” tells someone what they get.

• Make it readable at thumbnail size. Check every caption on a real phone, at the size it appears in search, not on a desktop monitor.
• One idea per caption, matched to the screen. A caption that promises something the screen does not show weakens trust in the whole set.
• Leave room for translation. German and Portuguese captions often run noticeably longer than English ones, so size the caption area for the longest language you plan to ship.
• Skip the claims stores discourage. Google recommends that taglines take up no more than 20% of the image and avoid words like “Best”, “#1”, “Top”, “New” or “Million Downloads”, as well as calls to action like “Download now”. Apple’s guideline 2.3.7 keeps prices out of screenshots.

Before and After: Caption Rewrites

Most weak captions fail in one of three ways: they name a feature, they brag, or they ask for the download. Here is what fixing each one looks like.

App type	Weak caption	Stronger caption	What changed
Budgeting	Budgets	Know what you can spend today	A feature name became an outcome
Meditation	Sleep sounds	Fall asleep without scrolling	It names the problem the app solves
Photo editor	Filters	Fix dull lighting in one tap	A specific result the screen below can prove
To-do list	The #1 to-do app	See today’s work in one list	Ranking claims are discouraged on Google Play
Grocery	Download now and save 20%	Your weekly list, sorted by aisle	No call to action and no price promotion
Language learning	Lessons	Five-minute lessons for your commute	It adds who the feature is for and when

For more caption examples and how to sequence them, see our guide to building a caption-led product story from your app store images.

Step 4: Build the Whole Set as One System

Designing screenshots one at a time is how sets drift. The type size shifts, the device scale changes, one frame is dense and the next looks almost like a raw capture. Build a single master frame first and derive every other frame from it.

• A grid with fixed safe margins and one caption position, so the eye lands in the same place on every frame.
• A type scale with one display face and two weights at most. If your brand typeface is too thin to read at thumbnail size, choose a heavier display face for captions. Visualmodo’s font pairing tool is a quick way to test combinations against your UI font.
• Color tokens taken from the product itself, so the listing and the app read as the same brand.
• One background rule: a consistent solid or gradient per frame, or a continuous panorama that runs across frames. Google allows stylized sets that split UI across several images, but still wants real UI prioritized in the first three.

Premium store design is usually restraint. A beautiful interface, confident typography, one clear benefit, strong contrast and space for the product to breathe will look more expensive than heavy effects that bury the UI, and the set stays readable when someone swipes through the carousel quickly.

Step 5: Adapt the Layout for Each Device and Store

Stretching an iPhone composition onto an iPad or a Play Store tablet slot rarely looks premium. Keep the system recognizable and let the composition change: the caption can move higher, the device can scale down, an iPad layout can use more breathing room, and a small phone layout may need a shorter caption.

Device Frames: Where Apple and Google Differ

Apple’s guidelines allow text and image overlays, so framed iPhone and iPad shots are common on the App Store. Google’s Play Console guidance on preview assets goes the other way. It recommends avoiding device imagery, because frames date quickly and can alienate people on other hardware, and it asks you not to show fingers tapping the screen. A practical compromise: framed or unframed for iOS, depending on your brand, and full-bleed UI without device frames for Google Play screenshots.

Keep each store’s set free of the other platform. Apple’s guideline 2.3.10 rules out imagery of other mobile platforms, so no Android phones or Google Play badges in your iOS set, and Google likewise recommends keeping other stores’ badges out of Play assets. If your app runs on Wear OS, those screenshots must be square, UI only and unframed.

Tablets and Large Screens

Use real tablet UI for tablet slots. If your iPad app has a sidebar or split view, show it instead of a scaled-up phone screen, because that is what iPad buyers want to verify. On Google Play, tablet and Chromebook listings need at least four screenshots in 16:9 or 9:16, and Google advises leaving out extra text that could be cropped on large-screen homepages. Google has put real effort into surfacing quality apps on large screens, and a stretched phone screenshot in a tablet slot tells shoppers the opposite.

Step 6: Export the Right Screenshot Sizes for Each Store

This is where most launch-week time disappears. App Store screenshot sizes are strict: Apple accepts only the exact pixel dimensions it lists, while Google Play accepts a range within fixed limits. Both stores refuse files for mechanical reasons before a person ever reviews them. The table covers what matters for most phone and tablet apps, and Apple’s full screenshot specifications list every legacy size and platform.

Store and device	Size and format	What to know
App Store, iPhone 6.9-inch	1320 × 2868, 1290 × 2796 or 1260 × 2736 px (portrait)	Upload this set and Apple can scale it for smaller iPhones. The 6.5-inch size (1284 × 2778 or 1242 × 2688 px) is required only if 6.9-inch screenshots are missing.
App Store, iPad 13-inch	2064 × 2752 or 2048 × 2732 px (portrait)	Required if your app runs on iPad.
App Store, all devices	1 to 10 screenshots, JPEG or PNG	No transparency or alpha channel. You can add up to three app previews of up to 30 seconds each.
Google Play, phone	JPEG or 24-bit PNG, no alpha. Each side 320 to 3,840 px, long side no more than twice the short side	Up to 8 per device type, at least 2 to publish. For recommendation formats, provide at least 4 at 1080 × 1920 px (9:16) or 1920 × 1080 px (16:9) or larger.
Google Play, tablet and Chromebook	At least 4 screenshots, 1,080 to 7,680 px, 16:9 or 9:16	Keep extra text away from edges that may be cropped.
Google Play, feature graphic	1024 × 500 px, JPEG or 24-bit PNG	Required to publish. Keep the focal point centered.

Apple Watch apps need their own screenshots in one of Apple’s listed sizes, and Apple requires the same watch size across every localization.

Pre-Upload Checks That Prevent Rejections

• Exact dimensions. A file that is off by a few pixels will not upload to App Store Connect.
• No transparency. Export PNGs without an alpha channel, or use JPEG. This is a frequent cause of failed uploads on both stores.
• The app in use on every frame. No frame that is only a logo, splash screen or login page.
• Age-appropriate imagery. Apple asks that screenshots suit a 4+ rating even if your app is rated higher (guideline 2.3.8).
• Upload order equals story order. The stores display screenshots in the order you upload them, so frame one really is frame one.
• Alt text on Google Play. Play Console lets you add alt text to each screenshot. Describe what the screen shows in 140 characters or less.

By Hand or With a Screenshot Generator

Multiply one set by two stores, two or three device classes and every language you support, and hand-built files turn into dozens of exports that drift out of sync. There are three realistic routes: a design tool with your own master templates, mockup kits for quick one-off visuals, or a dedicated generator. StoreScreens.ai is one example of the last route: you describe the app in a sentence, add your real screens as references, and it generates a coordinated set with headlines at App Store and Google Play sizes, including localized versions. Whichever route you choose, review the output against the checks above before it goes live. The stores hold you responsible for what ships, whatever tool produced it.

Step 7: Localize, Test and Refresh

Screenshots are a living part of your listing, not a launch-day deliverable. Treat the master set as a system you return to, and every future update gets faster.

Localize the Message, Not Just the Words

Apple recommends localizing screenshots for each market you sell in, and Google recommends localizing taglines and text overlays. Translation is the floor. Good screenshot localization also asks whether the same feature should lead in every market: the feature that sells in one country may matter less than offline mode or local payment support in another.

Test Before You Trust Your Taste

On the App Store, product page optimization lets you test up to three alternate versions of your icon, screenshots and app previews against your original page, for up to 90 days. Change one thing per treatment so you know what caused the result, and follow Apple’s advice to wait until a treatment reaches at least 90% confidence before applying it. Custom product pages let you show different screenshots to different audiences, such as people arriving from a specific ad campaign. Google Play covers the same ground with store listing experiments and custom store listings.

Screenshots are one lever in a wider app store optimization plan, alongside your app name, subtitle, keywords and ratings. They are also the lever that most directly decides whether a store visit becomes an install.

Know When to Refresh

• The UI changed visibly, so your screenshots no longer match what people see after installing.
• A headline feature shipped that belongs in the first three frames.
• You launched in a new market or language.
• A test produced a clear winner.
• Seasonal or time-bound captions are going stale. Google specifically advises swapping those out on time.

App Store vs Google Play Screenshots: Key Differences

The workflow is the same for both stores, but the rules are not. If you ship on both, keep one story and one visual system, and adapt the execution to each store using the differences below.

Rule	App Store	Google Play
How many screenshots	1 to 10 per device size	Up to 8 per device type, at least 2 to publish
Phone sizes	Exact sizes only, such as 1320 × 2868 px for 6.9-inch iPhones	Flexible: 320 to 3,840 px per side, long side no more than twice the short side, 1080 × 1920 px or larger recommended
File format	JPEG or PNG, no transparency	JPEG or 24-bit PNG, no alpha
Device frames	Allowed	Device imagery discouraged
Text on screenshots	Text and image overlays allowed, no prices	Taglines up to 20% of the image, no rankings, prices or calls to action
Other platforms	No imagery of other mobile platforms (guideline 2.3.10)	No badges from other stores
Extra listing assets	Up to 3 app previews of up to 30 seconds	Required 1024 × 500 px feature graphic, plus one optional preview video
A/B testing	Product page optimization: up to 3 treatments for up to 90 days	Store listing experiments
Pages for specific audiences	Custom product pages	Custom store listings

Final Checklist Before You Upload

• The first frame states the core promise in a few words.
• Every frame has one job, and the order tells a story.
• Every frame shows real, current UI with fictional demo data.
• Captions describe benefits, stay readable at thumbnail size and avoid rankings, prices and calls to action.
• One master layout drives every size and every locale.
• No other platform’s devices or store badges appear in either set.
• Exports match the exact required sizes and contain no transparency.
• Localized captions fit without shrinking the type.
• The next A/B test is already planned.

The Store Page Should Feel Like Part of the Product

A strong listing does not feel separate from the app behind it. The colors belong together, the typography makes sense, the screens are authentic and the hierarchy is deliberate. Someone seeing the app for the first time understands what makes it useful before they install it.

That is the real job of app store screenshots. They are not decoration around a product. They are the first chapter of the product experience.

Screenshot Sizes, Limits and Rejections: Quick Answers

About this guide: sizes and rules were checked on September 27, 2026 against Apple’s App Store Connect Help, the App Store Review Guidelines, Apple’s product page and product page optimization documentation, and Google’s Play Console Help on preview assets. Apple adds new device sizes as new hardware ships, so we recheck this page whenever Apple or Google changes these requirements.

Editorial note: Visualmodo has no commercial relationship with StoreScreens.ai or any other tool mentioned in this guide. StoreScreens.ai is named as one example of a dedicated screenshot generator. Check any generated set against the store rules above before you upload.