How to Write App Store Screenshot Captions That Convert

The average App Store visitor spends about seven seconds on your product page before deciding to download or move on. In those seconds, they are not reading your description. They are scanning your screenshots. More specifically, they are reading the short text overlays on those screenshots: the captions.

Bad captions waste your best real estate. Good captions can lift your conversion rate by 20% or more. The difference between the two is not talent or a big marketing budget. It is knowing a handful of specific techniques and applying them consistently.

This guide covers everything: how to frame benefits instead of features, how many words to use, how to sequence your captions across a screenshot set, and the mistakes that quietly kill conversions. If you have not yet built your screenshots, start with our step-by-step guide to creating App Store screenshots, then come back here to write the words that go on them.

Why captions matter more than you think

On the App Store, your first three screenshots show up directly in search results. Users see them before they ever tap into your full listing. Those thumbnails are small, roughly the size of a postage stamp on a phone screen. Your app UI becomes a blur of color at that size. The caption is the only thing they can actually read.

That means your captions are not supplementary. They are the primary communication channel. If your caption says "Settings Screen" while your competitor's says "Your morning routine, simplified," you have already lost the comparison.

There is an additional benefit worth knowing: Apple's search algorithm now reads the text in your screenshots and uses it as a signal for keyword relevance. Well-written captions can help your app surface for terms you have not explicitly targeted in your title or keyword field. This is not a replacement for proper keyword optimization, but it is a meaningful bonus.

Write benefits, not features

This is the single most important rule. A feature describes what your app does. A benefit describes what the user gets. Features are about your app. Benefits are about the person reading your caption.

Here is a quick test: read your caption aloud and ask, "So what?" If you can answer "so what" with something more compelling, you have written a feature and need to go one level deeper.

Here is the difference in action. The same four screenshots, the same template, the same app UI. Only the captions change:

Feature-focused (weak)

Benefit-focused (strong)

Same screenshots. Completely different impression. The top row describes what the app does. The bottom row tells you what changes in your life. Here is the breakdown:

Notice the pattern: every strong caption is about the user, not the app. The word "you" or "your" appears often. The weak versions talk about what the app does. The strong versions talk about what changes in the user's life.

Keep it short: the word count sweet spot

Your main headline should be 2 to 6 words. That is not a rough guideline. It is a hard constraint imposed by physics: your caption will be viewed at thumbnail size on a 6-inch phone screen. Anything longer becomes a block of gray that no one reads.

If you need to say more, use a subtitle line below the headline. Subtitles can go up to about 8 to 12 words. They work well for adding a concrete detail: a number, a timeframe, or a specific use case. The hierarchy should be clear at a glance: big, bold headline on top and smaller, lighter subtitle below.

A good way to test readability is the "25% zoom test." Open your screenshot design at full resolution (1290 x 2796 px for iPhone), then zoom out to 25%. If you cannot read the headline instantly, increase the font size or cut words. At the standard resolution, a headline font of 56 to 72px and a subtitle font of 28 to 36px are safe starting points. Use medium or semibold weight. Thin fonts disappear at small sizes.

Sequence your captions like a story

Your screenshot set is not five disconnected slides. It is a narrative. Users swipe through them in order, and each caption should build on the last. Think of it as a pitch: you have about five sentences to convince someone your app is worth a download.

A proven sequence that works across most app categories:

Write all five (or more) captions in a list before you design anything. Read them out loud in sequence. If they sound like a coherent pitch for your app, you are on the right track. If any caption feels redundant or disconnected, cut it or rewrite it.

Five headline formulas that work

If you are staring at a blank text field, these templates can get you started. They are not magic, but they are patterns that consistently perform well in App Store screenshot captions.

These formulas work because they are specific and outcome-oriented. Avoid vague adjectives like "powerful," "amazing," or "best." If every app in your category claims to be "the best," none of them are saying anything.

Using subtitles to add detail without clutter

A subtitle is the smaller line of text below your main headline. Not every template uses one, and not every screenshot needs one. But when used well, a subtitle can add specificity that the headline alone cannot carry.

Good subtitle use cases: adding a concrete number ("Over 10,000 recipes"), naming the mechanism ("Powered by Apple Health"), or specifying the context ("For teams of 1 to 100"). Bad subtitle use cases: restating the headline in different words, adding a second benefit that competes with the first, or cramming in a marketing tagline.

Keep subtitles to one line. If it wraps to a second line at thumbnail size, it will not be read. Use a lighter font weight or a muted color to create clear visual hierarchy between the headline and subtitle. The headline should grab attention. The subtitle should reward a closer look.

Localizing captions for international markets

If your app earns meaningful downloads from non-English markets, translating your captions is one of the highest-return moves you can make. A screenshot with native language text outperforms an English-only screenshot by a wide margin in markets like Japan, Germany, South Korea, and Brazil.

The good news: you do not need to redesign your entire screenshot set for each language. Keep the same layout, phone frames, and visual design. Just translate the text overlays. If you use a tool like Screenshot Otter, you can write captions with the AI Caption Assistant, auto-translate into 40+ languages, and export new screenshot sets without starting from scratch.

One important note: direct translation is not always enough. Some headlines that work well in English ("Never miss a beat") rely on idioms that do not translate cleanly. For your top three to five markets, have a native speaker review the translated captions to make sure they sound natural and carry the same intent. For more detail on this, see our full guide to ASO screenshot localization.

Seven caption mistakes that kill conversions

Testing your captions with Product Page Optimization

Apple offers a built-in A/B testing tool called Product Page Optimization (PPO). You can create up to three alternate screenshot sets and run them against your original. Apple splits your organic traffic between the variants and shows you which version converts better.

The most effective caption tests are simple: change the headline on screenshot one and keep everything else the same. This isolates the variable and gives you a clear signal. Running a test where you change captions, backgrounds, and phone frames all at once tells you that one version won, but not which change caused it.

Let your test run for at least seven days to account for day-of-week variation in traffic patterns. Apple recommends collecting a few thousand impressions per variant before drawing conclusions. When you have a winner, implement it and start your next test. Even a 10% improvement in conversion rate compounds over time. For a full walkthrough, see our guide to A/B testing App Store screenshots.

Putting it all together: a caption writing workflow

Here is the process that works well for most indie developers and small teams: