# App Store Screenshots for Launch: A Practical Production Guide

> Plan, capture, design, localize and validate app store screenshots for an iOS or Android launch without creating an unmaintainable asset set.

- Canonical: https://zeroraised.com/blog/app-store-screenshots-for-launch
- Published: 2026-10-18
- Updated: 2026-10-18
- Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised)
- Publisher: ZeroRaised (https://zeroraised.com/)
- Section: Growth
- Tags: app-store-optimization, mobile-apps, launch-assets, bootstrapping

App store screenshots should show a real, current product state and explain one useful outcome in a sequence a new visitor can understand. Build the sequence before styling it, capture from a controlled release candidate, then export and validate separate files for Apple and Google Play because their requirements are not interchangeable ([Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications) and [Google Play preview-asset guidance](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

**Disclosure:** [ZeroRaised](https://zeroraised.com/) publishes this guide and is a launch and discovery site for bootstrapped indie makers. This article makes no claim about ZeroRaised traffic, conversions or launch results.

## TL;DR

| Decision | Practical default for launch | Platform constraint to check | Primary source |
|---|---|---|---|
| Story | Lead with the app’s main outcome, then show the short path that produces it | Apple expects the majority of a set to show the app in use; Google says screenshots must demonstrate the actual app or game experience | [Apple guideline 2.3.3](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026 |
| Quantity | Use the fewest frames that make the product clear; do not pad the set with repeated screens | Apple accepts one to ten screenshots per device size. Google Play accepts up to eight per supported device type and requires at least two across device types for a store listing | [Apple specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026 |
| Source image | Capture the submitted release candidate with stable sample data | Both stores require imagery that represents the actual experience; Apple explicitly rejects misleading screenshots, and Google’s metadata policy requires screenshots to reflect the app | [Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) and [Google Play metadata policy](https://support.google.com/googleplay/android-developer/answer/9898842?hl=en), checked 18 Oct 2026 |
| Copy | Use one short claim per frame and make every claim provable inside the submitted build | Google discourages ranking, price, promotional, testimonial and call-to-action language in screenshots; Apple permits text overlays but says they must not crowd out the app | [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en) and [Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026 |
| Localization | Translate the promise, recapture localized UI when it materially changes the image, and review each locale visually | Apple supports localized screenshots and fallback behavior; Google recommends localizing added taglines and branding text | [Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), [Apple localization](https://developer.apple.com/help/app-store-connect/manage-app-information/localize-app-information/) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026 |
| Production | Keep capture state, copy, layout and export settings separate so each can change without rebuilding everything | Apple’s Asset Library and Google Play’s asset workflow manage store media, but neither replaces your own editable source and review process | [Apple Asset Library](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets/) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026 |

This guide is the asset-production companion to the broader [product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers). It does not cover signing, binary submission, release tracks, launch-site campaigns or application security. Use the [bootstrapped app launch guide](https://zeroraised.com/blog/how-to-launch-a-bootstrapped-app) for the wider release sequence.

## What app store screenshots need to do before launch

The screenshot set has three jobs: identify the result, make the interface credible and help the right person decide whether the product fits. Those are editorial goals, not store promises. A visually impressive frame that does not explain the product can fail the first job; a clear claim wrapped around a fictional interface can fail the second.

Start with a sentence that can govern the whole set:

> This app helps **[specific user]** complete **[specific job]** by **[distinct method or advantage]**.

Turn that sentence into a sequence of questions. What outcome should be visible first? What action creates it? What evidence reduces doubt? Which secondary capability changes the decision? A six-frame planning sheet might look like this:

| Position | Question answered | Capture to prepare | Overlay copy |
|---|---|---|---|
| 1 | What useful result do I get? | The strongest completed state | A plain outcome, not a slogan |
| 2 | How do I begin? | The main input or setup step | The shortest accurate action |
| 3 | What happens next? | The core workflow in progress | The product’s differentiating behavior |
| 4 | Can I inspect or control the result? | A detail, editor or review state | The control that matters |
| 5 | Does it fit my context? | A real secondary feature | The relevant qualifier |
| 6 | What makes it trustworthy? | A transparent status, history or settings state | A narrow, verifiable proof point |

This is a planning pattern, not a recommendation to upload exactly six images. Apple permits between one and ten screenshots for each device size, while Google Play permits up to eight for each supported device type; the useful count is the shortest complete explanation inside those limits ([Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

Do not begin with every feature in the backlog. Begin with the release that will actually be reviewed. If the first version imports a receipt and categorizes it, show that path. Do not imply that it also reconciles a bank account because that is planned for the next release. Apple asks developers to update screenshots so they match the current interface, and Google bars misleading metadata and asks for images that reflect the actual experience ([Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) and [Google Play metadata policy](https://support.google.com/googleplay/android-developer/answer/9898842?hl=en), checked 18 Oct 2026).

## A dated example: Shotie’s Show HN launch

**Dated note, 12 Oct 2026:** Hacker News user `abolfazlarab` submitted “Show HN: Shotie - App Store screenshots generated from your code,” linking to Shotie. The item is a concrete recent example of a maker product built around a pre-submission asset task; it is not evidence about typical launch results or conversion performance ([Show HN submission](https://news.ycombinator.com/item?id=50052682), checked 18 Oct 2026).

Shotie’s own page says its macOS app can capture from an iOS Simulator or Android emulator, accept uploaded screens, use a chosen AI coding tool to recreate screens from code, produce localized sets and export a zip. Those are the vendor’s feature claims, not an independent evaluation ([Shotie product page](https://shotie.app/), checked 18 Oct 2026).

The useful lesson is broader than one product. Screenshot production has four separable layers:

1. **State:** the account, data, permissions and screen the product displays.
2. **Capture:** the pixels recorded from the chosen build and device class.
3. **Composition:** the background, crop, device treatment, headline and ordering.
4. **Delivery:** the language, dimensions, file format, filename and store placement.

You can handle those layers manually, with design templates or with code. Separating them is the important decision. If a price changes, you should not have to recreate sample data. If the interface changes, you should not rewrite every headline. If a store changes an accepted size, you should be able to change an export target without redesigning the sequence.

## App store screenshots: Apple and Google Play requirements compared

Check the live specifications again immediately before export. The table below records the first-party pages as checked on 18 Oct 2026, not a permanent promise about future requirements.

| Requirement | Apple App Store | Google Play |
|---|---|---|
| General count | At least one and up to ten screenshots per device size | At least two screenshots across device types to publish; up to eight per supported device type |
| General file type | JPEG, JPG or PNG; no alpha channel or transparency | JPEG or 24-bit PNG with no alpha for general screenshots |
| General dimensions | Exact accepted pixel sizes depend on Apple’s listed display class | Minimum dimension 320 px, maximum dimension 3840 px; the long side cannot exceed twice the short side |
| Phone launch baseline | At least one screenshot for an iPhone with Dynamic Island in the medium display class | Phone assets follow the general screenshot requirements; four high-resolution 16:9 or 9:16 images are required for eligibility in recommendation formats that use screenshots |
| Tablet condition | At least one 13-inch iPad screenshot if the app supports iPadOS | Large-screen guidance asks for at least four tablet or Chromebook screenshots, 1080 to 7680 px, in 16:9 landscape or 9:16 portrait |
| Product fidelity | More than half of each device-type set must show the app in use; misleading presentation is not allowed | Images must demonstrate the actual in-app or in-game experience and focus on core features and content |
| Added copy | Text and image overlays are allowed when the app remains visible and unobscured | Taglines should be used only when necessary and occupy no more than 20% of the image under Google’s recommendation guidance |
| Ordering context | App Store Connect lets the developer sort screenshot placement | On surfaces that show video and screenshots together, the video appears before screenshots, followed by the most suitable images in their left-to-right order |

Sources: [Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), [Apple guideline 2.3.3 reference](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) and [Google Play preview-asset guidance](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026.

The platform rows are not a shared design brief. For example, Google explicitly advises against device imagery in its general screenshot recommendations because it can become obsolete or alienate some users. Apple allows visual overlays but evaluates whether the actual app remains the majority of the set and is not crowded out ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en) and [Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026). Build one story, then adapt the compositions to each destination.

Also treat special form factors as separate deliverables. Google publishes distinct rules for Wear OS, Android TV, Android Automotive OS and Android XR on the same preview-assets page. Apple lists separate specifications for iPhone, iPad, Mac, Apple TV, Vision Pro and Apple Watch ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en) and [Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), checked 18 Oct 2026). Do not infer a watch, car or headset export from the phone design.

## Step 1: freeze the release candidate and the screenshot story

Name the exact build before capture. Record the version, commit or build identifier, operating-system version, device or simulator profile, appearance mode, locale and account fixture. This is an editorial production practice, but it solves a concrete review question: can the team reproduce the state shown in the listing?

Next, write one line for every proposed frame. Use this structure:

`Frame 01 | outcome | completed plan | “Know what ships next” | requires Pro: no`

The line forces five decisions: order, purpose, screen state, copy and access condition. Delete a frame when it repeats another purpose. Split a frame when it tries to explain two unrelated ideas. Mark any paid or permission-gated capability so the screenshot does not accidentally present restricted behavior as the default experience.

Use a capture account that contains realistic but non-personal sample data. Names, addresses, messages, financial details, health details, API keys and notification previews can survive in a crop or status area even when they were not the intended subject. The safest production fixture is deliberately fictional, visually plausible and reusable. “Fictional” here describes the sample records, not the product capability.

Lock the sample clock, amounts and status values when those affect the interface. A dashboard that changes between captures creates avoidable differences across device sizes and locales. If deterministic fixtures are impossible, document a short reset procedure and the acceptable values for each screen.

## Step 2: capture clean source screens

Capture the app itself before adding backgrounds, headlines or hardware frames. Preserve those raw captures in a separate directory. They are the evidence layer, while the composed exports are the marketing layer.

For every raw capture, check:

- the correct release candidate is installed;
- the intended account and permission level are active;
- sample content is complete and contains no private information;
- loading, error and skeleton states are absent unless the frame specifically explains them;
- the status area contains no stray carrier name, alert, low battery or personal notification;
- light or dark appearance matches the planned variant;
- the keyboard, cursor, debug overlay and touch indicator appear only when they explain the feature;
- the screen is not stretched, sharpened or reconstructed after capture.

Google’s guidance specifically asks developers to remove excess status-bar elements, avoid service providers or notifications, keep battery and connection icons full, and reject blurry, distorted, stretched or incorrectly rotated screenshots ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026). Apple’s guidance permits overlays that explain interaction but says they must not obscure the primary functionality ([Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026).

Capture the real state at a native size whenever possible. Do not resize one phone capture into a tablet shell. Do not place an iOS interface in an Android frame or vice versa. If the app supports a layout that materially changes with screen size, capture that layout instead of relying on a crop.

Apple says App Store Connect can scale down the highest required resolution when the interface is consistent across device sizes and localizations, while also allowing tailored assets for individual device sizes and localizations ([Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), checked 18 Oct 2026). Treat that as an upload convenience, not permission to pretend different layouts are identical.

## Step 3: write copy that the interface can prove

A screenshot headline should help a visitor interpret the visible state. “Turn notes into assigned tasks” can be supported by a screen showing a note and its extracted assignments. “The smartest work platform” cannot be established by the pixels beneath it.

Use three tests for every line:

1. **Specificity:** does it name an action, result or relevant property?
2. **Fidelity:** can a reviewer find that behavior in the submitted build?
3. **Durability:** will it remain correct after the launch offer, date or temporary event ends?

The third test prevents the asset set from expiring quietly. Google recommends avoiding time-sensitive copy, store-performance claims, ranking language, testimonials, prices, promotions and calls to action in screenshots. Its examples include language such as “#1,” “New,” “Sale” and “Million Downloads,” and calls such as “Install now” ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026). Google’s broader metadata policy also prohibits deceptive claims and requires metadata to reflect the app’s functionality ([Google Play metadata policy](https://support.google.com/googleplay/android-developer/answer/9898842?hl=en), checked 18 Oct 2026).

Keep qualifications beside the claim when they change its meaning. If offline use applies only to downloaded projects, say “Review downloaded projects offline,” not “Works offline.” If collaboration requires a paid workspace, the image or listing context should not imply that every account includes it. This is editorial advice intended to keep the presentation accurate.

Do not make each frame depend on the previous one to form a sentence. Store surfaces can crop, reorder by device suitability or present only part of a set. Google says screenshots may appear in search or on the homepage as well as the listing, and Apple describes screenshots as a prominent product-page asset ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en) and [Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026). A visual panorama may still work, but each visible frame should remain intelligible on its own.

## Step 4: design for a small preview, not the artboard

Review the composition at the size a person is likely to encounter first, not only at full export resolution. A headline that looks restrained on a large artboard can become illegible when reduced. A finely detailed dashboard can turn into texture. This is a design test, not a claim about a universal store layout.

Use a consistent grid across the set:

- one stable headline area;
- one dominant interface area;
- a repeatable margin system;
- a controlled background palette;
- a fixed rule for corner radius, shadows and device treatment;
- an intentional crop that preserves the interaction being explained.

Then allow the product state to change. Consistency should make comparison easy, not make every image identical. If frame one is a completed result and frame two is the input that creates it, their difference should be obvious even when the copy is covered.

Give the interface more visual weight than decoration. Apple says the majority of each set must show the app in use, and its examples reject sets dominated by title art, sign-in screens or splash screens. Google asks developers to prioritize UI in the first three images when using stylized multi-image compositions and recommends limiting taglines to 20% of an image ([Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

Do not assume a device frame adds credibility. It can consume space and create a maintenance dependency on changing hardware silhouettes. Google’s general recommendations tell developers to avoid device imagery, while its Wear OS rules go further and prohibit placing screenshots in device frames ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026). If a destination permits a frame and it materially explains a cross-device interaction, make that a conscious platform-specific choice.

## Step 5: build an asset system you can update

Keep four source folders or logical groups:

```text
screenshots/
  captures/      # untouched product screens by platform, device and locale
  copy/          # headlines, qualifiers and localization notes
  layouts/       # editable compositions and shared styles
  exports/       # generated files organized by store destination
```

Add a small manifest beside them. YAML, JSON or a spreadsheet is enough:

```yaml
release: 1.0.0-42
set: launch-core
frames:
  - id: outcome
    order: 1
    state: plan-complete
    claim: Know what ships next
    access: all-users
  - id: assign
    order: 2
    state: note-to-owner
    claim: Turn decisions into assigned work
    access: all-users
targets:
  - apple-iphone
  - apple-ipad
  - google-phone
locales:
  - en-US
```

This schema is only an example. The durable principle is to record which build, state, text, access level, platform and locale produced every export. Put the same frame ID in filenames so review feedback can identify an asset without attaching it again.

Choose the production method by change frequency and matrix size:

| Method | Best fit | Main advantage | Main risk | Minimum control |
|---|---|---|---|---|
| Manual capture and composition | One platform, one language, infrequent releases | Lowest setup cost | Small edits are repeated by hand | Checklist plus named source files |
| Reusable design template | Several sizes or a small localization set | Visual adjustments remain accessible | Copy and captures can drift from the template | Locked styles plus manifest |
| Code-generated composition | Many locales, devices or frequent UI changes | Repeatable layout and export | Bad inputs can reproduce an error across the whole matrix | Versioned data, deterministic render and visual review |
| Hybrid capture plus generated layout | Stable capture flow with many delivery variants | Separates product truth from repetitive composition | Integration can hide stale captures | Build ID, capture date and human sign-off |

Automation reduces repeated labor; it does not decide which outcome belongs first, whether the claim is honest or whether the crop is legible. A generated set still needs comparison against the submitted build. The Shotie example is useful here because its product page explicitly separates capture or code-based screen creation, composition, localization checks and export, while the Show HN title foregrounds generation from code ([Shotie](https://shotie.app/) and [Show HN submission](https://news.ycombinator.com/item?id=50052682), checked 18 Oct 2026).

## Step 6: localize the whole frame

Localization is not replacing one English string. The headline may grow, the interface may change language, numbers may use different separators, names may need local examples and a right-to-left layout may change visual direction. Review the final pixels for each locale rather than approving a translation table in isolation.

Use this order:

1. Decide which launch markets genuinely need a localized listing.
2. Translate the intended meaning, not the line length.
3. Capture localized UI when on-screen language is part of comprehension.
4. Fit the translated overlay without shrinking it below comfortable reading size.
5. Check truncation, line breaks, punctuation, numeral formatting and right-to-left composition.
6. Have a fluent reviewer check the image in context.

Apple lets developers add localized metadata and explains that the most relevant available localization is used when an exact language match is missing. It also permits tailored screenshots by localization, while allowing scaling when the interface is consistent ([Apple localization guidance](https://developer.apple.com/help/app-store-connect/manage-app-information/localize-app-information/) and [Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), checked 18 Oct 2026). Google recommends localizing added taglines and branding text, while saying that in-game UI does not have to be localized for every market ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

Those options are not a reason to claim a localized experience the app does not provide. If only the listing is translated, make sure the screenshots do not imply that the entire interface is available in that language. If the app is fully localized, showing the matching interface usually gives the visitor a more accurate preview. These are editorial recommendations based on fidelity, not platform guarantees about performance.

## Step 7: export and run a mechanical preflight

Export to named targets, not a generic “mobile” preset. Use the live Apple specifications for the required display classes and exact pixels. Use the live Google page for file type, dimensions, aspect ratio and special device rules ([Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

Run the following checks on every file:

- filename maps to store, platform, device class, locale and frame ID;
- pixel width and height match the intended target;
- file type is accepted for that target;
- color and transparency export settings comply with the target;
- orientation is correct;
- file opens without corruption;
- no text is clipped;
- the raw UI is not stretched;
- the frame contains no private or irrelevant status information;
- the set order matches the manifest;
- duplicate files and obsolete variants are excluded from the upload folder.

Apple currently accepts JPEG, JPG and PNG files and disallows alpha channels or transparency. Google’s general screenshot rules specify JPEG or 24-bit PNG without alpha, a minimum dimension of 320 px, a maximum of 3840 px and a longest side no more than twice the shortest ([Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026). Do not rely on a design tool’s preset name as proof that the exported bytes meet those rules.

Generate a contact sheet for each destination and locale. It should show every image in upload order at a reduced size, with the filename underneath. This catches inconsistent margins, repeated screens, copy rhythm problems and accidental omissions faster than opening exports one by one.

Finally, compare the contact sheet with a fresh install of the selected release candidate. Trace each claim to a reachable product state. A reviewer should be able to answer: where is this screen, who can reach it, what data is required and does the store build behave this way?

## Step 8: upload, inspect and preserve the approved set

After upload, inspect the listing editor rather than assuming the local contact sheet predicts every presentation. Verify placement, ordering, language and device category. Apple’s current tools let developers sort placements and manage screenshots across Product Page Information, Media Manager and Asset Library; Google Play’s preview assets are managed through the Graphics section of the main store listing ([Apple Asset Library](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets/) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

Preserve three things after submission:

- the exact exported set;
- the editable sources and manifest;
- the approval state and build they describe.

Apple’s Asset Library can store, reuse and manage screenshots and other media across eligible placements, and its App Store Connect API supports asset-library workflows ([Apple Asset Library](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets/), checked 18 Oct 2026). Keep your own source archive as well because it contains the capture fixtures, copy decisions and layout logic needed for the next release.

## Common screenshot mistakes before submission

### Starting with a splash screen

A logo may identify the product but does not demonstrate its job. Apple explicitly says screenshots should not merely show title art, a login page or a splash screen, and requires more than half of each device-type set to show the app in use ([Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026). Use the first frame to show a meaningful completed or active state.

### Treating decoration as product evidence

A dramatic background, angled phone and bold headline can make weak evidence look polished. Remove the decoration temporarily. If the remaining screen does not support the headline, change the state or the claim.

### Showing unreleased behavior

Do not use a design mockup for a capability that the submitted build cannot perform. Both Apple and Google require listing imagery to reflect the real app experience ([Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots) and [Google Play metadata policy](https://support.google.com/googleplay/android-developer/answer/9898842?hl=en), checked 18 Oct 2026).

### Reusing one composition everywhere

Phone, tablet, watch, television, car and headset listings have different interface contexts and may have different rules. Apple and Google publish device-specific requirements rather than one universal screenshot format ([Apple screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications) and [Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

### Embedding fragile claims

Prices, rankings, launch dates, limited offers and download counts can make an asset wrong quickly, and Google’s screenshot recommendations specifically discourage those categories ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026). Prefer durable product meaning. Put changing commercial details in store fields designed to be maintained.

### Shrinking translated copy until it fits

Tiny text solves an export problem by creating a comprehension problem. Rewrite the localized line, allow a different break or adjust the composition. Do not force every language to occupy the English text box.

### Automating without visual review

A repeatable pipeline can repeat stale data, clipped copy, the wrong locale or a privacy leak across every target. Require a contact-sheet review and a final comparison with the release candidate, regardless of how the assets were generated.

## A two-day production plan for a small team

This schedule is ZeroRaised editorial advice. It assumes the release candidate and store accounts already exist; it is not a platform requirement or a claim about how long every app needs.

### Day 1: story and captures

In the first session, freeze the build and write the governing product sentence. Draft the frame map, then delete repeated ideas until each remaining frame answers a distinct question.

In the second session, create or reset the sample account. Capture every planned state on the required platform and device profiles. Review raw captures for privacy, stray status information, inconsistent data and incorrect access levels before anyone starts composing.

In the third session, write headlines against the captured evidence. Reject any line the pixels cannot support. Mark platform-specific exclusions, such as a composition that uses device imagery and therefore should not be carried into a Google Play set without reviewing Google’s guidance ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).

### Day 2: composition and validation

Build the first three frames before the rest. Review them at reduced size and without headlines. If the main outcome and flow are still unclear, repair the sequence before multiplying it into sizes and locales.

Create target-specific exports from the approved layout. Run the mechanical preflight, generate contact sheets, and ask someone who did not build the screens to explain the sequence back to you. Their explanation is a clarity check, not user research and not proof of conversion.

Upload to the appropriate store editors, inspect the resulting order and record the submitted asset version. Leave enough time to correct rejected dimensions or a missed locale without moving the public launch announcement.

## What to test after launch

Do not call the launch set “winning” merely because the app was approved. Approval establishes compliance with the review process, not that the story is the clearest possible one.

Apple’s product page optimization can test up to three alternate icons, screenshot sets and previews for an iOS or iPadOS product page, with variants randomly shown to a defined user group and results available in App Analytics. Apple says the app must be Ready for Distribution to run such a test ([Apple product page optimization](https://developer.apple.com/help/app-store-connect/create-product-page-optimization-tests/overview-of-product-page-optimization/), checked 18 Oct 2026).

Google Play store-listing experiments can test screenshot variants on default or localized listings and report against install, open or pre-registration click metrics. Google recommends changing one asset at a time so the cause of a difference is easier to interpret ([Google Play store-listing experiments](https://support.google.com/googleplay/android-developer/answer/12053285?hl=en), checked 18 Oct 2026).

Test a decision, not a mood. Examples include outcome-first versus workflow-first ordering, a narrow audience qualifier versus a general benefit, or a completed result versus an input state in frame one. Keep the product version, other listing elements and traffic context as stable as the platform and release allow. Record draws and inconclusive results instead of turning noise into a marketing claim.

If the product changes during the test, stop and reconsider the interpretation. Apple warns that releasing a new version while a product-page test is running may affect results when the release changes assets or metadata under test ([Apple product page optimization](https://developer.apple.com/help/app-store-connect/create-product-page-optimization-tests/overview-of-product-page-optimization/), checked 18 Oct 2026).

## The final app store screenshot checklist

Use this immediately before submission:

- [ ] The target keyword, audience and product promise agree with the store description.
- [ ] Frame one shows a useful product outcome or differentiator.
- [ ] Every claim is visible, reachable and accurate in the selected build.
- [ ] The majority of each Apple device set shows the app in use, as Apple requires ([Apple screenshot guidance](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026).
- [ ] Google Play images show the actual experience and avoid prohibited or discouraged promotional language ([Google Play preview assets](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026).
- [ ] No capture contains personal information, secrets, test notifications or irrelevant status details.
- [ ] Platform, device class, orientation, locale and appearance mode are intentional.
- [ ] Exported dimensions, format and transparency settings match the current first-party specifications.
- [ ] Headlines remain readable on the reduced contact sheet.
- [ ] Localized copy and UI have been reviewed in the final composition.
- [ ] Filenames map every export to a frame and destination.
- [ ] Upload order and placement have been checked inside each store editor.
- [ ] Editable sources, raw captures, manifest and final exports are archived together.
- [ ] The team knows which product change will trigger a screenshot review.

The best launch set is not the one with the most effects. It is the smallest truthful sequence that lets the intended user understand the product, recognize the real interface and decide whether to continue.

When the store listing is ready, coordinate it with the broader release rather than treating approval as the whole launch. ZeroRaised is a launch and discovery site for bootstrapped indie makers without institutional VC or accelerator equity. Review the [ZeroRaised home board](https://zeroraised.com/), current [submission form](https://zeroraised.com/submit) and [maker perks](https://zeroraised.com/perks), then use the [Product Hunt launch guide](https://zeroraised.com/blog/how-to-launch-on-product-hunt) only if that audience and launch format also fit the product.

If motion explains the workflow better than still frames, use the [product demo video guide](https://zeroraised.com/blog/how-to-make-a-product-demo-video) to build the companion asset.

Use the [app store keyword research guide](https://zeroraised.com/blog/app-store-keyword-research-for-indie-apps) to connect the screenshot sequence to search intent and the store metadata plan.

## Sources

- [Apple: Screenshot specifications](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications), checked 18 Oct 2026
- [Apple: Guideline 2.3.3, show your app in use](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots), checked 18 Oct 2026
- [Apple: Localize app information](https://developer.apple.com/help/app-store-connect/manage-app-information/localize-app-information/), checked 18 Oct 2026
- [Apple: Manage your App Store assets](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets/), checked 18 Oct 2026
- [Apple: Product page optimization overview](https://developer.apple.com/help/app-store-connect/create-product-page-optimization-tests/overview-of-product-page-optimization/), checked 18 Oct 2026
- [Google Play: Add preview assets to showcase your app](https://support.google.com/googleplay/android-developer/answer/9866151?hl=en), checked 18 Oct 2026
- [Google Play: Metadata policy](https://support.google.com/googleplay/android-developer/answer/9898842?hl=en), checked 18 Oct 2026
- [Google Play: Run A/B tests on your store listing](https://support.google.com/googleplay/android-developer/answer/12053285?hl=en), checked 18 Oct 2026
- [Hacker News: Show HN, Shotie](https://news.ycombinator.com/item?id=50052682), checked 18 Oct 2026
- [Shotie product page](https://shotie.app/), checked 18 Oct 2026

## Frequently asked questions

### How many app store screenshots should I prepare for launch?

Prepare only the frames needed to explain the core value, main workflow and strongest proof, while staying within each store's current minimum and maximum. A concise set is easier to keep accurate than a padded sequence.

### What should the first app store screenshot show?

Show the app's main outcome or clearest differentiator in a real, legible product state. The first frame should make sense without relying on the rest of the sequence.

### Can app store screenshots include text and device frames?

Yes when the store's current policies permit them, but the text, device treatment and interface must remain accurate. Check Apple's and Google's current specifications before export because platform rules differ.

### Should I automate app store screenshots?

Automate repeated capture, layout or export work when the product has several device sizes, languages or frequent releases. Keep a human review for copy, crop, visual order and fidelity to the submitted build.

### Do localized listings need localized screenshots?

Use localized screenshots when text inside the image or market-specific context affects comprehension. Keep copy outside the interface separate from the underlying capture so each locale can be reviewed and updated independently.