App Store Screenshots Best Practices: Nine Rules and What Each One Rests On

The App Store screenshot best practices with the firmest backing come from Apple itself: the first one to three screenshots appear in search results, so they need to carry the pitch alone, and every screenshot should show the app in use. Our corpus of top-chart listings adds a rule about keeping captions short, and the rest of this list keeps a set clear of review trouble and readable in every language you sell in.

Apple's own guidance on screenshots is brief. App Review Guideline 2.3.3 says screenshots "should show the app in use," and the product page guide covers how many you can upload and which ones search shows. Much of the other advice online is design preference presented as a rule, and the Google results for this phrase on November 2, 2026 included an AppFollow guidelines post from 2019 and a Moburst guide from 2023, both older than Apple's current iPhone size rules. Each practice below names its basis: an Apple document we read on November 2, 2026, our August 2026 corpus of top-chart iOS listings, or our own editorial judgment where neither applies. That way you can tell which rules come with a citation and which are a recommendation you're free to weigh against your own taste.

The nine practices

1. Make slides one to three work as a unit in search

Basis: Apple's product page guide.

Search results show the first one to three screenshots, depending on orientation, and a visitor can decide from that row without opening the product page. Treat those three as a short pitch, with the first stating what the app does for the person and the next two backing it up. A slide that only makes sense after the reader has seen slide four belongs later in the set. If you add an app preview video, it takes the first spot in search and the screenshots follow it, so plan the row with the video included.

2. Show the app in use on every slide

Basis: App Review Guideline 2.3.3.

The guideline names what doesn't count: title art, a login page, or a splash screen shown on its own. A welcome slide with only a logo on a gradient fails that test however polished it looks, because nothing in it shows the app working. Lead with a screen that has realistic content in it, such as a budget with real categories filled in. Empty states and onboarding steps are weak choices for the same reason, since they show the app before it has done anything. Overlays are allowed, so a caption, a device frame, or a highlighted touch point on top of the real screen is fine.

3. Keep captions short enough to read in the search row

Basis: our corpus, plus an editorial check.

Top listings mostly let the app UI lead. In our August 2026 corpus, only about 7% of screens give the text more space than the app interface, and the rest are balanced or led by the UI. Screenshots in search results are much smaller than on the product page, so a caption that reads well at full size can become unreadable there. To test yours, shrink an exported slide to roughly thumbnail width on your phone and see whether you can still read the caption. If you can't, cut words first and only then consider a smaller font. You can also generate a set from your own captures and run the same thumbnail check on its opening row.

4. Write captions about the result the reader gets

Basis: our corpus, plus editorial judgment.

Feature-name headlines, like "Smart Folders" or "Budget Reports," make up about one in five headlines across the corpus, so plenty of top apps use them. They're a fair choice when the name already says what the user gets. When it doesn't, rewrite the caption around the change for the user, as in "Find any file in two taps." The feature-name headline page has real examples of when the plain label works, and the headline formulas cover the alternatives.

5. Put the proof for each caption on the same slide

Basis: editorial judgment.

A caption that says "Track every subscription" should sit above a screen that lists subscriptions. If the best screen for a claim lives in a different flow, use that screen and move the caption with it, or rewrite the caption to match the screen you have. Reviewing captions and screens side by side with the current build open also catches a feature that was cut or renamed since the captures were taken. Guideline 2.3 asks for metadata that accurately reflects the app, so a slide that promises something the build can't do gives App Review a reason to reject it. The layout library shows crops and zoomed UI cards that keep the relevant part of a screen visible at small sizes.

6. Leave prices and other platforms out of App Store images

Basis: App Review Guidelines 2.3.7 and 2.3.10, and Google Play's metadata policy.

Guideline 2.3.7 says screenshots shouldn't include prices, and 2.3.10 rules out names, icons, or imagery of other mobile platforms in your metadata. In practice that means no Android phone in an App Store screenshot and no "50% off this week" banner, even when the same art runs in an ad. If you also publish on Google Play, its metadata policy lists "#1," "App of the year," "10% off," and "Editor's choice" among examples of text that store graphics can't carry. The guide to rejected App Store screenshots covers what to change if App Review flags a slide.

7. Include a Dark Mode screen if the app supports it

Basis: Apple's product page guide.

Apple suggests including at least one screenshot that shows the Dark Mode experience when your app has one. It shows a visitor how the app looks with the setting they may already use, and it gives the set a change of pace partway through. Keep the caption style and background system the same on that slide so it still reads as part of the set.

8. Design at the required sizes and check the files before upload

Basis: Apple's screenshot specifications.

The required iPhone slot is now the 6.3-inch display (1206 x 2622 or 1179 x 2556), and apps that run on iPad also need the 13-inch iPad display. If you upload a 6.9-inch set instead, App Store Connect scales it into the 6.3-inch slot, and it scales your sets down for the smaller devices you leave empty. Designing once at those sizes saves you from maintaining a separate export for every device. The screenshot sizes table lists every accepted pixel size per class, and the requirements page covers format and color rules. The free screenshot size checker reads each export in your browser and flags a wrong size, a wrong format, or a leftover alpha channel. It needs no account, and it won't resize files or predict what App Review decides.

9. Translate captions for each storefront you sell in

Basis: editorial judgment.

A visitor in Germany who sees English captions has to translate your pitch before they can judge it. Translate the captions for every localization you've added in App Store Connect, then recheck the line breaks, because German and French captions often run longer than the English ones. Screens with a lot of interface text may need localized captures too, or the caption and the UI will be in different languages. The localization checklist walks through what to verify in each language before upload.

How these practices relate to the patterns in top sets

These nine are rules for a single listing. The roundup of the best App Store screenshots looks at finished sets instead, with the galleries worth browsing and the slide order and visual system that top listings repeat. The category idea pages then show how those patterns shift by app type, because a game and a budgeting app reward different first slides.

Where Screenies fits

Practices 2 and 5 both assume you start from real screens, and that's where a Screenies set starts: you upload captures from your build, and the app UI on every slide comes from them, with the headline for each slide planned in the same pass. Headlines are rendered as real text, the iPhone set exports at 1290 x 2796 for the 6.9-inch slot, which App Store Connect scales into the required 6.3-inch slot, and the iPad set at 2064 x 2752 for the 13-inch slot, and translating a finished set's captions for practice 9 costs 0.1 credits per slide per language. Credits come in one-time packs, listed with per-device costs on the pricing page.