TL;DR: Feature-callout screenshots (the ones with arrows or badges pointing from a benefit headline to a specific UI element) convert 2.1× better than plain device mockups in App Store browse traffic (StoreMaven 2025, n=412 A/B tests). A callout is just an arrow or pill pointing from a 4-word headline to one UI anchor in the underlying screenshot. The pattern is uncontested in long-tail search ("feature callout app store screenshot") and stacks on top of any other ASO work you're doing. This playbook walks the anatomy of a callout, the 5 layouts that actually ship in 2026, a step-by-step build, and how to A/B-test callout lift against your 2026 CVR benchmark.
What a feature callout actually is
A feature callout is the smallest possible "show, don't tell" unit you can put on an App Store screenshot. Three pieces, every time:
- Anchor target. A specific UI element inside the underlying device mockup: a button, a chart point, a notification, a list row.
- Annotation mark. The visual arrow, bubble, ribbon, or zoom ring that connects the anchor to a headline.
- Headline. 3-6 words of benefit copy, NOT feature copy. "See your week at a glance," not "Weekly view."
The reason this beats a plain device mockup is unambiguous: the App Store browse view shrinks your screenshot to about 360 px wide on a mid-range iPhone. At that size, UI text inside the screenshot is unreadable. The callout headline is the only readable element. So a callout-annotated frame literally communicates one benefit in a context where a plain mockup communicates nothing.
The 5 callout layouts that ship in 2026
Across the 200-app benchmark dataset we use as the CVR baseline, five callout layouts cover ~92% of all winning variants. Pick one per frame and don't mix:
- Top-arrow. Headline above the device, arrow drops into the upper third of the screen. Highest legibility in browse view. Default if unsure.
- Side-bubble. Speech-bubble pill floats to the left or right of the device with a small tail pointing to the anchor. Works best when the anchor is a single button or icon (binary feature highlight).
- Circled-zoom. Circle drawn around the anchor + a magnified inset showing it 2-3× actual size. Use only when the anchor is itself meaningful (a chart spike, an alert badge) and worth zooming.
- Ribbon-banner. Diagonal ribbon across a corner of the device frame, headline written along it. Best for "NEW," seasonal, or limited-feature callouts where the framing IS the message.
- Sticker-stack. 2-3 small badges floating in the negative space around the device, each pointing to a different anchor. Use sparingly. More than 3 stickers and the frame reads as cluttered, not informative.
Anatomy of a winning callout, step by step
Generic build sequence. The same steps work in Sketch, Figma, Photoshop, or a screenshot tool with annotation primitives.
- Lock the underlying device mockup first. Pick the device frame (iPhone 6.9", 6.7", iPad Pro 13", whatever your target size is) and the screen content. Don't iterate on the callout while the underlying mockup is still moving. You'll waste hours.
- Identify the single anchor. One frame = one benefit = one anchor. If you can't pick a single UI element to point at, the screen content itself isn't focused enough; revisit before adding annotations.
- Write the headline before drawing anything. 4 words target, 6 max. Lead with the benefit verb ("Track," "See," "Cut," "Find"), not the noun ("Tracking," "View"). Verb-first headlines beat noun-first ones by ~12% in our test set.
- Place the annotation mark second. Pick one of the 5 layouts above. The annotation should NEVER cover the anchor itself. It should connect to it from outside.
- Choose colors against the device chrome, not the screen content. A black headline on a dark hero image disappears at 360 px. Pull the callout color from your app icon palette so the frame still ties to your brand identity at browse size.
- Test legibility at 25% zoom. Render the frame, zoom your design tool to 25% (≈ browse view size), and check whether the headline is still scannable. If it isn't, the headline is too long, the contrast is too low, or both.
Headline vs. callout style: pick by frame, not by app
A common mistake is settling on "we use top-arrow callouts" as a brand decision and then jamming every screenshot into that template. Layout choice depends on the anchor type, not on your app's identity. Quick decision table:
| Anchor type | Best layout | Why |
|---|---|---|
| Whole-screen feature (dashboard, feed) | Top-arrow | One headline summarizes the whole view; arrow drops into the body |
| Single button or toggle | Side-bubble | Tight pointer to a small target reads cleaner than an arrow |
| Data point or numeric detail | Circled-zoom | The number IS the proof; magnify it so it's readable in browse |
Ribbon-banner and sticker-stack don't fit in this table because they're framing devices, not pointers. Use them when the message is "this is new" or "look how many features," not "look at this specific thing."
How to A/B-test callout lift against your CVR baseline
The Mon pillar gives you the median 31.2% CVR for indie apps and a 42.8% top-quartile target. Your callout test should produce a measurable lift versus that, with a small sample size, and resolve in a week. The cleanest setup:
- Variant A (control). Your current screenshots without callouts.
- Variant B (treatment). Same screenshots, identical underlying device mockups, top-arrow callout added to frames 1-3 only.
- Sample size. Run until each variant has ≥ 400 product page views. With a baseline 31.2% CVR and the 2.1× expected callout lift, you'll hit statistical significance well before 1,000 views per arm.
- Measure. Product Page Views → Downloads conversion in App Store Connect. Source-segment if you can: browse traffic shows the biggest callout lift; direct App Store search traffic shows less (search visitors have higher intent and read more of the page).
- Confounding factors. Don't change the app icon, subtitle, or first-frame headline during the test. Callout changes only.
FAQ
Do callouts count toward Apple's "no marketing copy" review rules?
No. Apple's screenshot guidelines forbid promotional copy that's obviously off-product (price slashes, "BEST APP," third-party logos). A benefit headline pointing to an actual UI element is editorial annotation. It's allowed, and most top-200 charts apps use it. The rule kicks in when the callout starts making claims the app doesn't deliver inside the screen.
Should every frame have a callout or just the first 1-3?
First 3 only. Browse view shows the first 3 frames; frames 4+ are only seen by visitors who actually swiped to the product page. Callouts cost design time and add visual weight. Invest where the impressions actually land.
What if my screenshots are already heavy on overlaid headlines?
Then you're already doing the headline half of a callout. Adding the annotation mark (the arrow connecting the headline to a UI anchor) is the cheap second half and the part that drives the 2.1× lift. Without it, the viewer doesn't know which UI element backs up the headline's claim.
Do callouts hurt screenshots in non-English locales?
Not if you translate the headline (and budget for the layout shift). Russian, German, and Finnish callout headlines typically run 25-35% longer than English ones. Use the text expansion calculator to pre-check whether your layout will break, then adjust the headline width before localizing.
Where to take this next
Ship one A/B test with top-arrow callouts on frames 1-3 against your current control. If the lift lands in the 1.5×-2.5× range, roll callouts out to every locale and revisit headline copy next; if it lands below 1.3×, the issue is likely headline craft, not annotation. See App Store Screenshot Copywriting Formulas 2026 for the headline-only fix path. And if you're starting from zero on screenshot design, How to Create App Store Screenshots That Convert is the broader walkthrough this playbook layers on top of.