App Store screenshots that convert: a practical guide for indie developers
Most people decide whether to download your app in about three seconds. They glance at your icon, read half the subtitle, and scroll through maybe two screenshots. If those two screenshots don't answer the question "what does this app do for me?" they're gone. Your code doesn't matter. Your architecture doesn't matter. Screenshots are the sale.
Why most indie screenshots are bad
Go look at any indie app's listing right now. Chances are the screenshots are just raw screen captures with no context. A home screen with dummy data. A settings page. Maybe a login screen, which is genuinely baffling — nobody downloads an app because the login page looks nice.
This happens because developers think about screenshots last. You spent months building the app. You're tired. You take a few phone screenshots, upload them in whatever order, and move on. It feels like a formality.
It's not. According to Apple's own data, about 70% of App Store visitors never tap past the first impression — the icon, title, and first three screenshots visible in search results. Those screenshots are doing more selling than your entire description text, which almost nobody reads.
The good news: you don't need to be a designer to make decent screenshots. You need to understand what information they should communicate and in what order. That's a product question, not a design question.
The first screenshot is the only one that matters (almost)
When someone finds your app in search results, they see your first two or three screenshots as small thumbnails. On product pages, the first screenshot takes up the most visual space. In both cases, screenshot #1 carries disproportionate weight.
Your first screenshot needs to communicate one thing: the primary value of your app. Not a feature list. Not your brand. The one sentence answer to "why would I want this?"
A calorie tracker's first screenshot shouldn't show the food logging interface. It should show the result — a clean summary of today's nutrition with a headline like "See exactly what you ate today." People don't want to log food. They want to understand their eating habits. Show the outcome.
A budgeting app shouldn't lead with the transaction list. Lead with the monthly overview showing that the user is under budget. The transaction list is the work. The overview is the reward.
This is the mistake developers make most often. We lead with the feature we're most proud of technically. Users lead with the problem they're trying to solve. Those are usually different screens.
What goes in screenshots 2 through 5
If screenshot #1 is your hook, screenshots 2-5 are your argument. Each one should answer a potential objection or highlight a secondary benefit. Here's a sequence that works for most apps:
Screenshot 1: Primary value / outcome. Screenshot 2: The main workflow (how it actually works). Screenshot 3: A differentiator (what makes you different from competitors). Screenshot 4: Social proof or data (stats, accuracy, or a feature that builds trust). Screenshot 5: Secondary feature or platform support (widgets, Apple Watch, etc.).
You don't need to follow this exact order, but notice the logic: hook, explain, differentiate, reassure, expand. Each screenshot builds on the last. They tell a story even when someone is scrolling fast.
Apple lets you upload up to 10 screenshots. Don't use all 10 unless each one genuinely adds information. Five strong screenshots beat ten mediocre ones. After about six, most people have already decided whether to download or leave. Screenshots 7-10 are essentially invisible.
Caption text: what to write on top
The text overlaid on your screenshots (captions) is where most of the conversion happens. The app UI itself is too small to read in thumbnail view. The caption is what people actually read.
Good captions are short — five to eight words. They describe benefits, not features. "Track expenses in 5 seconds" beats "Expense Tracking Feature." "Never miss a workout" beats "Workout Scheduling." The difference is subtle but significant: one tells you what happens in your life, the other describes a menu item.
Avoid trying to be clever or cute in captions. People are scanning, not reading. "Your finances, finally figured out" sounds nice but tells you nothing about what the app does. "See where your money goes each month" is boring and effective.
If you're localizing for non-English markets, your captions need to be translated too, and not by Google Translate. Captions are marketing copy. Bad translations in captions look worse than no translation at all. If you can't afford a native speaker, skip localized screenshots for that market and use the English versions.
Design basics (for non-designers)
You don't need Photoshop. You don't need Figma skills. Here's a minimal approach that produces clean results.
Use a solid background color. Pick one or two colors from your app's palette and use them as the background behind your device frame. Gradients are fine if they're subtle. Avoid busy backgrounds, patterns, or stock photos behind the phone — they compete with the app UI for attention and always lose.
Put your device mockup at about 70-80% of the frame height. This leaves room for caption text above or below the device. Centering the device horizontally works. You don't need to get fancy with angles or perspective shots.
For caption text, use a clean sans-serif font. SF Pro, Inter, or your system font. White text on dark backgrounds, dark text on light backgrounds. No drop shadows, no outlines, no gradients on the text itself. Size it so it's readable as a thumbnail in App Store search results — pull up the App Store on your phone and see if you can read your captions at actual display size.
Tools that work well for this: Canva (free), Figma (free), or dedicated screenshot generators like AppMockUp, Screenshots Pro, or Previewed. These tools have templates specifically for App Store screenshots with the correct dimensions already set up.
The dummy data problem
Nothing kills conversion like screenshots showing "John Doe" as the user name and $0.00 as every balance. Your screenshots need to show the app looking like someone actually uses it.
Create a demo account with realistic data. If your app tracks expenses, populate it with two weeks of plausible spending. If it's a workout tracker, add a month of workout history so the progress charts look meaningful. If it's a notes app, write actual notes that someone might write.
The goal is for the screenshot to make someone think "that looks like my life." When they see a budget app with categories like Groceries, Coffee, Netflix, and Uber, they recognize themselves. When they see Category 1, Category 2, Category 3, they see a prototype.
This also applies to dates and times. If your app shows dates, make sure the screenshots show recent dates, not timestamps from six months ago when you last updated the listing. This is a small detail that signals whether the app is actively maintained.
What to steal from your competitors
Before designing your screenshots, look at the top 5-10 apps in your category. Not to copy them, but to understand the visual language users in your category expect. If every fitness app uses dark backgrounds with neon accents, you'll look out of place with a pastel color scheme. That might be intentional differentiation, or it might just confuse people.
When you're analyzing competitor listings, pay attention to what their screenshots emphasize. If everyone leads with the main dashboard view, there might be a good reason — users in that category expect to see the dashboard before deciding. Or it might be lazy conformity, and leading with something different could make you stand out.
Also look at what competitors don't show. If no fitness app shows its Apple Watch complication, and yours has a great one, that's a screenshot worth including. Gaps in competitor screenshots are features you can highlight.
This kind of competitive analysis takes about 20 minutes and should inform your entire screenshot strategy.
Landscape vs. portrait
Stick with portrait unless your app is primarily used in landscape (games, video editors, drawing apps). Portrait screenshots are displayed larger in search results and feel more natural for phone apps.
If your app works in both orientations, portrait screenshots for the listing and a landscape screenshot somewhere in the middle (showing a specific landscape feature) is a reasonable compromise. But don't mix orientations randomly — it looks messy.
For iPad screenshots, the same rules apply but you have more room. Some developers skip iPad screenshots entirely, which is a missed opportunity if your app has an iPad version. iPad users browse the App Store on their iPads and see iPad-specific screenshots. If you only have iPhone screenshots, the listing looks like a phone app that happens to run on iPad, which is exactly what they're trying to avoid.
Dark mode screenshots
If your app supports dark mode, include at least one dark mode screenshot. A lot of users browse the App Store with their phone in dark mode, and a dark mode screenshot feels native to them — it blends into the context they're viewing it in.
Don't make all your screenshots dark mode though. Light mode screenshots tend to show more detail and are easier to read at small sizes. A mix works well: mostly light, with one or two dark screenshots to show you support it.
Starting in iOS 18, Apple supports "appearance-aware" screenshots that automatically show light or dark versions based on the user's device settings. If you have the time, setting this up is worth it — it's a small touch that makes your listing feel polished.
Localization of screenshots
If you're targeting non-English markets, localized screenshots make a meaningful difference. Apple's data suggests localized screenshots can increase conversion by 25-40% in non-English markets.
This doesn't mean you need to recreate all your screenshots from scratch for each language. The approach that works: translate the caption text, and if possible, show the app UI in the local language. Keep the same layout, same background, same device frame. Just swap the text.
The markets where localized screenshots matter most are Japan, Korea, Germany, France, and Brazil. Users in these markets are particularly sensitive to English-only listings. In Japan especially, an all-English listing signals "this app isn't for me" regardless of how good it is. The localization guide and the geo arbitrage scanner can help you identify which markets are worth the effort.
One common mistake: localizing screenshots but leaving the in-app dummy data in English. If your screenshot caption is in Japanese but the app UI shows "John's Budget - $450 for Groceries," it's obvious the app isn't really localized. Use local names, local currency, and local content in the app data.
Testing whether your screenshots work
You can't A/B test screenshots on the App Store the way you would a landing page. Apple does offer product page optimization (PPO), which lets you test up to three treatment variations against your default page. The sample sizes required are large — Apple recommends running tests for at least 7 days — so this is more useful once you have steady traffic.
Before you get to that point, there are simpler ways to evaluate your screenshots. Show them to five people who aren't developers. Don't explain what your app does. Show the screenshots for five seconds and ask them what the app is for. If they can't tell you, your screenshots aren't working.
Another test: look at your screenshots at actual thumbnail size on your phone. Open your listing in the App Store and see it the way a real user would. Is the caption text readable? Can you tell what's on the screen? If you're squinting to read your own screenshot, every potential user is doing the same thing and then scrolling past.
Track your conversion rate (impressions to downloads) in App Store Connect before and after updating screenshots. This is a rough measure, but if you update your screenshots and your conversion rate goes from 25% to 35%, you have your answer. If you're tracking the right metrics, you'll catch this kind of improvement quickly.
Common mistakes
Too much text on each screenshot
If your screenshot has a headline, a subheadline, bullet points, and a call to action, nobody is reading any of it. One short caption per screenshot. That's it. The app UI provides the visual context. The caption provides the benefit. Together they should take two seconds to understand.
Showing the onboarding flow
Your onboarding screens are not a selling point. Nobody downloads an app because it has a nice tutorial. Show the app in use, not the app explaining itself.
Using real user data
This sounds obvious, but people do it. Don't screenshot your own real data with identifiable information, and don't use a beta tester's real account. Create dedicated demo data every time.
Ignoring the first three
App Store search results on iPhone show approximately three screenshots. If your third screenshot is a settings page and your best feature is shown in screenshot #6, most users will never see it. Front-load your strongest screens.
No visual consistency
Each screenshot should feel like it belongs to the same set. Same background color (or a deliberate color progression). Same font. Same device frame style. When screenshots look like they were made at different times by different people, it suggests the app itself is inconsistent.
Forgetting to update them
Your screenshots should reflect the current version of your app. If your UI has changed significantly since you last updated your screenshots, users will download the app, see something different from what they expected, and feel misled. It's a small thing that erodes trust immediately. Include screenshot updates in your release checklist.
The 30-minute screenshot refresh
If you're reading this and your current screenshots are raw screen captures with no context, here's a 30-minute process to fix that.
Minutes 1-5: Write down the one sentence answer to "why would someone download this app?" That becomes your first screenshot's caption.
Minutes 5-10: List your app's three most important screens. Not your favorite screens — the ones that show the most value to a new user. These become screenshots 2-4.
Minutes 10-15: Populate your app with realistic demo data. Names, dates, amounts that look like a real person's usage.
Minutes 15-25: Take your screenshots and drop them into a template tool (AppMockUp or Canva). Add one caption per screenshot. Pick a background color from your app's palette.
Minutes 25-30: Pull up your listing on your phone at actual size. Read the captions. Can you understand what the app does in five seconds? If not, simplify the captions.
This won't produce award-winning screenshots. But it will produce screenshots that are better than 80% of indie app listings, because the bar is genuinely that low. Most indie developers treat screenshots as an afterthought, so even a small amount of intentional effort puts you ahead.
Screenshots as ongoing work
Your screenshots aren't a set-and-forget thing. Update them when you ship a major feature. Update them when you rebrand. Update them seasonally if your app is relevant to seasons (fitness apps in January, budgeting apps in tax season).
Keep a "screenshot update" item in your release checklist. Every time you submit a new version to the App Store, ask yourself: do my screenshots still accurately represent what this app looks like and does? If the answer is no, spend 15 minutes refreshing them.
If you're using ASO techniques to improve your listing over time, screenshots are part of that cycle. Your title and subtitle might be driving impressions, but your screenshots are converting those impressions into downloads. Improving your marketing to drive more traffic to a listing with bad screenshots is just bringing more people to a store with a bad window display.
The apps that consistently rank well in their categories usually have screenshots that look current, communicate clearly, and show the app in its best light. Not because screenshots directly affect ranking (they don't), but because they affect conversion rate, and conversion rate does affect ranking.
If you want to see what competitors in your target category are doing with their screenshots, the AppOpportunity scanners can help you find apps in your space, and looking at their listings is a free masterclass in what works and what doesn't. Some of the abandoned apps with outdated screenshots are particularly instructive — they show you exactly what "I'll get to the screenshots later" looks like after two years.
Quick reference: screenshot dimensions
Apple requires specific sizes for App Store screenshots. Here are the ones you actually need:
iPhone 6.7" (required): 1290 x 2796 pixels. This is for the latest Pro Max models. All other iPhone sizes can be auto-generated from this one.
iPhone 6.5" (required if supporting older models): 1284 x 2778 pixels. Required if you support iPhone 11 Pro Max through iPhone 14 Plus.
iPad 12.9" (required for iPad apps): 2048 x 2732 pixels. If your app runs on iPad and you don't provide iPad screenshots, you're missing iPad-specific search traffic.
If you use a screenshot generator tool, it handles these dimensions automatically. If you're doing it manually in Figma or Canva, set your artboard to these exact sizes and work at 1x scale.
The bottom line
Screenshots are the most underinvested part of most indie app listings. The ROI on spending an hour making good screenshots is probably higher than the ROI on most features you could build in the same hour. If your conversion rate goes from 25% to 35%, that's 40% more downloads from the same traffic. No feature ships that fast with that kind of impact.
Lead with value, not features. Keep captions short and benefit-oriented. Use realistic demo data. Test at thumbnail size. Update them regularly.
That's really it. Like most things in app store optimization, the bar for "good enough" is lower than you think, and clearing it puts you ahead of most of your competition.
Find app opportunities backed by real data
AppOpportunity scans the App Store for abandoned apps, angry users, rising niches, and gaps across 5 countries. Stop guessing, start building where the data says to.
See Pricing →