# App Store Screenshots: Turn Features Into Reasons to Download

Canonical page: https://www.aso.guide/blog/app-store-screenshots/
Author: ASO Guide
Published: 2026-10-03

Your first App Store screenshot should show what someone can do with your app. “Build better habits” leaves them guessing. A daily checklist with the caption “See today’s habits in one place” makes the idea concrete.

App Store screenshot optimization means choosing, ordering and explaining UI captures so prospective users can understand the app and decide whether it fits their needs. This guide turns the listing from our [App Store metadata article](https://www.aso.guide/blog/app-store-metadata/) into a five-frame storyboard. You’ll write captions, choose screens to capture and check what readers understand from the sequence.

## Decide what the first screenshot should explain

Start with the user’s task. If your [keyword research](https://www.aso.guide/blog/app-store-keyword-research/) points to people looking for a habit tracker with reminders, show how the app helps them follow their daily habits. A screen full of settings would answer a different question.

Apple says the first one to three screenshots can appear in search results when no app preview is available, depending on image orientation. Put the app’s main use early, then use later frames to explain supporting features. [Apple: Creating your product page](https://developer.apple.com/app-store/product-page/).

The opening depends on what your audience wants to do. A photo editor might show an edited photo beside its editing controls; a route planner might show a route someone can follow. In either case, the image should support the caption. You’ll still need to test whether that opening attracts downloads.

Write a short brief before opening a design tool:

- Who is considering this app?
- What are they trying to do?
- Which screen shows that task most clearly?
- What could they misunderstand about it?

For our fictional habit tracker, Daynook, the audience wants a daily checklist, reminders and a history of completed habits. The app doesn’t plan an entire day or provide guided workouts. Write those limits into the brief so they carry through to the design.

## Make each caption something the interface can support

A useful caption tells the reader what they can do or understand. “Powerful reminders” says little about how reminders work. “Choose a reminder time” tells the reader what to look for in the screen.

Point to the part of the screen that supports the caption. If you can’t, change the image or the wording. If a claim depends on a feature still in development, leave it out of the release assets.

Apple’s review rules require screenshots to show the app in use and permit text and image overlays. They also require rights to the materials you use and fictional account information in place of a real person’s data. [Apple: App Review Guidelines, sections 2.3.3 and 2.3.9](https://developer.apple.com/app-store/review/guidelines/#accurate-metadata).

Captions can sit above or beside a UI capture, but leave enough room for people to see the app. Crop only when the remaining context still explains the action. A close-up of a button with no surrounding screen may leave people unsure what they’re looking at.

## A five-frame storyboard for Daynook

This storyboard proposes a sequence for the fictional Daynook app. It hasn’t been tested, and the capture notes describe screens to prepare. For a real listing, check that each control exists and capture it from the submitted app.

It moves from the daily checklist to recording a completion, setting a reminder, reviewing history and adding a habit.

### Frame 1: show the daily checklist

**Vague caption:** “Build better habits.”

**Proposed caption:** “See today’s habits in one place.”

Capture the daily checklist with a few recognizable sample habits, such as reading, walking and practicing a language. Show both completed and incomplete items, if the actual UI supports those states. Keep enough surrounding interface to make it clear this is today’s list.

The reader should recognize a habit tracker they can use during the day. Keep it distinct from an hourly calendar, which would suggest Daynook can schedule the whole day.

### Frame 2: show recording a completion

**Vague caption:** “Stay on track.”

**Proposed caption:** “Mark a habit when you complete it.”

Use the same sample habit as in frame 1 and capture its completed state. Make the completed state easy to spot without a decorative arrow. If a touch indicator helps explain the action, keep it clearly separate from the app’s own controls.

If the first frame already makes completion clear, combine the two. Use the spare frame to answer another question, or leave it out. You don’t have to keep all five.

### Frame 3: show setting a reminder

**Vague caption:** “Never miss a day.”

**Proposed caption:** “Choose a reminder time.”

Capture the reminder control with a sample time selected. Show the controls the app actually has. Don’t add weekday choices, smart suggestions or multiple reminders just to make the image look more useful.

“Never miss a day” promises more than a reminder can ensure. The revised caption describes the choice the user can make.

### Frame 4: show completion history

**Vague caption:** “Watch yourself grow.”

**Proposed caption:** “Look back at completed habits.”

Capture the history view with a few sample completions. If frame 2 records a completion, make sure a later history image doesn’t contradict it.

Show how the app presents that history. An invented chart, streak or prediction would give readers the wrong idea about what they can review.

### Frame 5: show adding a habit

**Vague caption:** “Make it yours.”

**Proposed caption:** “Add a habit you want to practice.”

Capture the actual habit-creation screen with a sample name entered. Keep the form recognizable and make the habit name easy to read.

We’ve put setup last because the opening frames explain what the user gets from doing it. If readers can’t tell how to add a habit, move this frame earlier and check again. Understanding the sequence is one check; measuring downloads is another.

## Check readability at the size people will see

Reviewing a full-resolution export on a large monitor can hide problems. Put the assets into a small phone-sized layout and look at them without zooming. Check both the sequence and each image on its own.

Can you read the main caption? Can you identify the relevant control? Does the first image still explain the app if the reader never swipes?

Start with one short caption per frame. Add supporting text when a reader needs it to understand the screen. The right length and type size depend on the layout, device and language. If a caption wraps awkwardly, shorten it or give it more room before shrinking the type.

Use clear contrast between text and background. Don’t depend only on color to explain completion: preserve a checkmark or another visible state indicator where the actual app uses one. Keep captions away from crowded UI regions.

Each frame should stand alone. A continuous background can tie the sequence together, but splitting an important sentence across two images forces the reader to swipe to finish it. Check translations in the finished layout too; translating a caption can change its length and emphasis.

## Export for the supported device and localization

Apple currently accepts one to ten screenshots in JPEG or PNG format, with no alpha channel or transparency. Its specification table lists accepted dimensions and device requirements. [Apple: Screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications/).

For example, the current 6.9-inch iPhone category accepts a portrait image of 1320 × 2868 pixels, among other sizes. The 6.5-inch set is required for an iPhone app if a 6.9-inch set isn’t supplied. Apps that run on iPad require the 13-inch set; 2064 × 2752 pixels is one accepted portrait size. The table includes other accepted sizes. Check it again before exporting and uploading.

Capture the corresponding device experience. Stretching a phone image onto an iPad canvas doesn’t explain the tablet layout. For a separate Mac listing, use Apple’s Mac requirements.

Apple describes automatic scaling when the interface is the same across device sizes and localizations. You can supply specific assets through Media Manager and inspect the sets there. [Apple: Upload app previews and screenshots](https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots/).

Before upload, check that the captures match the submitted version, use fictional data, and contain no private names, messages or account details. Review the wording and UI in each localization. A translated headline above an untranslated screen can make the experience harder to understand.

## Review the sequence before testing conversion

Show the storyboard to prospective users who haven’t seen your brief. Ask them to describe the app, the first action they expect to take and the feature they would use next. Let them answer before explaining the intended meaning.

Record specific misunderstandings. “It looks nice” doesn’t tell you whether someone expects a calendar, a checklist or a workout plan. For Daynook, repeated expectations of hourly scheduling would justify revising the opening image or caption.

These answers tell you whether people understand the screenshots. To learn whether the changes affect downloads, you need a separate test.

For an eligible app, Apple’s Product Page Optimization lets you compare alternative screenshots with the original page. A focused test might compare the checklist-first opening with an existing opening while keeping later frames unchanged. Save the question, assets and selected localizations before starting. [Apple: Product Page Optimization](https://developer.apple.com/app-store/product-page-optimization/).

Apple requires review of new test metadata. Screenshot-only tests can be submitted independently of a new app version; changing the approved default screenshots follows the version workflow described in its upload documentation. Check which workflow you’re using before planning a release.

Keep product, pricing and campaign changes in a dated log. A before-and-after download increase alone cannot isolate the effect of a caption. Sparse traffic may leave a test inconclusive; don’t declare a winner simply because one variant is temporarily ahead.

## Your screenshot brief

Copy these fields for one device and localization:

- Audience and task:
- App version, device, orientation and language:
- First-frame promise:
- Proposed caption for each frame:
- Screen and state supporting each caption:
- Sample data needed for the captures:
- Expected misunderstanding to check:
- Caption and UI readability checks:
- Accepted export dimensions and format:
- Owner and review date:
- Conversion question to test after comprehension review:

For Daynook, the developer owns the brief and checks whether unfamiliar readers recognize the checklist and understand how to record a completion. Expectations of full-day planning mean the opening needs work. Once the sequence is clear, prepare the captures and validate the exports. Its effect on downloads remains untested.

## Frequently asked questions

### How many App Store screenshots should I use?

Apple permits one to ten. Use enough to explain the experience without repeating the same point. The five-frame example is a starting point. Shorten or expand it to suit the questions your readers have.

### Should the first screenshot show a feature or a benefit?

Show the feature in use and use the caption to explain why someone would use it. A checklist supports “See today’s habits in one place.” The words and image should answer the same question.

### Can I add text over an App Store screenshot?

Yes. Apple permits text and image overlays, while requiring the screenshot to show the app in use. Keep the UI recognizable and make sure the wording describes functionality available in the submitted app.

### Do screenshot captions guarantee better keyword rankings?

No. The Apple guidance cited here doesn’t establish a ranking weight for caption text. Write captions to explain the app. Treat any observed ranking movement as something to investigate, not proof that a particular phrase caused it.

### Can I update screenshots without releasing a new app version?

Apple says updating approved default screenshots requires a new version. Product Page Optimization provides a separate test workflow: a test without alternate app icons can be submitted for review independently of a new version. Both workflows require the applicable review steps.

### Do I need an app preview video as well?

A preview is optional. If you use one, check its poster frame and how it works with the screenshots. Apple says previews precede screenshots on the product page, so check what readers see when both are present.

## Prepare one sequence you can explain

Choose the screens for one localization, write captions beside them and ask a prospective user what they expect from the app. Revise any promise the interface doesn’t support. Save the final assets with the date they go live. You’ll need that record when reviewing the results.

The next article will explain ASO metrics: how to distinguish visibility, conversion and downloads when evaluating a listing change. If you use [ASO Analytics](https://www.aso.guide/#features), keep its keyword history alongside your creative change log. Use App Store Connect for the screenshot experiment itself.
