How to make App Store screenshots and previews

This is a repeatable process for a solo developer, not a studio pipeline, and it is deliberately narrower than the ASO checklist, which covers names, keywords and review prompts. Required device sizes change when Apple adds displays. Confirm the current screenshot and preview specifications in App Store Connect before you export, and don’t treat a pixel size from last year’s device as permanent.

The first screenshot does most of the work

Imagine the product page at the size it appears on a phone in a shop, in someone’s hand. The icon, the name, the subtitle and one tall image are in view. That image should still work if the captions are too small to read, which they often are.

A strong first frame usually has:

• The real UI of the main job, not a stock photograph with the icon pasted on it
• One idea, not four floating bubbles of marketing text
• A state that looks used but not messy: real names, a plausible date, no lorem, no debug flags, no half-filled “Test 3”
• Contrast that survives a dark and a light store context, because you do not control the chrome around the page

If the app is a camera, show a photo being taken or edited. If it is a tracker, show the tracker with a believable record. If it is a Watch app, show the Watch, but remember that the iPhone product page still has to make sense on an iPhone; the Watch design work is a complement, not a substitute for the phone screenshots.

Write a one-line brief for the first frame before you open the simulator: “Person sees the weekly log, already filled in, with today’s entry highlighted.” If you cannot write that line, you are not ready to capture.

Required sizes, and a set you can actually maintain

App Store Connect asks for screenshots for specific display sizes, and it can use a larger size to stand in for a smaller one in some cases. The exact list, and which size can substitute for which, is in the current upload documentation. Read that list at the start of every serious reshoot. A new iPhone display has, more than once, made an otherwise finished set incomplete.

For a solo developer, the maintainable approach is:

1. Design the set once, in a single reference size, usually the largest current iPhone size the store requires, in portrait unless the app is genuinely landscape-first.
2. Keep a short list of frames — five or fewer for a small app, each with a job: first impression, main task, a second important surface, a result, an optional Watch or widget frame.
3. Export the required size set from that source, rather than redesigning captions on every device.
4. Add iPad, Mac, Apple TV or visionOS sets only if you ship there. A token iPad set that shows a stretched iPhone layout will not help you.

Don’t promise yourself ten device-specific compositions. You will not keep them in date, and stale UI in a screenshot is worse than a slightly generic but accurate set. The same restraint I argue for in small, focused Apple apps applies to the marketing surfaces.

A practical check: if the UI changes in a way a user would notice, can you reshoot the whole set in an afternoon? If not, the set is too heavy.

Use the Aspect Ratio Calculator and the Image Resizer & Cropper when you are fitting a source image to a required size, but start from a capture at the correct native resolution if you can. Upscaling a small screenshot to a larger required size is how edges go soft.

Real UI versus a marketing frame

You have two honest styles, and a third that causes trouble.

• A raw device screenshot, sometimes with the status bar tidied, is the most truthful. It is also the easiest to reshoot. It works when the UI already explains itself.
• A marketing frame — the UI, on a device bezel or a simple background, with a short caption above or below — is useful when the screen needs a sentence of context. The caption should be a claim you can stand behind: “Track a week in one list,” not “The ultimate productivity companion.”
• A collage of floating windows, 3D phones and a paragraph of tiny text is the style that dates fastest and reshoots worst. It also tends to hide the actual app, which is the thing a person is trying to judge.

If you use a bezel, keep it current enough that it does not look like a cancelled product, and don’t let the bezel eat the readable area. If you use a caption, set it large, in a weight that survives compression, and leave more margin than you think you need. The store will crop and scale in ways you will not see in a design tool.

Never show a feature the build does not yet have. A screenshot is a claim, and App Review can treat misleading marketing the way it treats misleading metadata. The launch process should include a pass where someone compares the live build to the screenshots.

Captions, localisation and not adding clutter

Captions are optional. If the UI has a clear heading, you may not need them. If you add them:

• Write in the language of the locale, not in English pasted onto a German page.
• Use sentence case, and fewer words than feel comfortable. Three to six words is usually enough.
• Don’t repeat the app name in every caption.
• Don’t cover the part of the UI you are trying to show.
• Keep typography consistent across the set: one typeface, one size, one background treatment.

Localisation is the part indie sets usually skip, and it is the part a careful person notices. For each language you list on the product page, you should have screenshots whose captions (and, ideally, whose UI) match. A machine-translated caption with English UI is a last resort, and it is often worse than using the English set in that locale until you can do it properly.

Save captions in a small text file next to the export script, not only inside a design document. You will need them again in six months, when a label in the app has been renamed.

A preview video: length, first frame and sound

An App Store preview is a short video that plays on the product page. It is optional. A mediocre preview is worse than a strong first screenshot, because it can autoplay and still fail to show the app.

If you make one:

• Confirm the current length limits, device sizes and file requirements in App Store Connect. Those figures have changed before, and I will not freeze them here.
• The first frame should work as a poster. If the video never plays, that frame is a screenshot. Don’t start with a logo hold or a fade from black.
• Show the job in the first seconds, with the interface large enough to read on a phone.
• Assume the sound is off. If you use sound, captions or obvious visual progress should still carry the meaning. Don’t start with a spoken paragraph.
• Keep it short, even if the allowed maximum is longer. A small app can often say what it needs in the lower half of the allowed window.
• Capture from the real app, not from a slide deck about the app.

Editing can be plain: cut the dead air, avoid jump cuts that make the UI feel unstable, and don’t add stock music that fights the system mute. If you are not comfortable editing video, skip the preview and spend the time on the first three screenshots. You can add a preview later without pretending it is required for a good page.

Capturing from a simulator or a device

Both are valid; they fail in different ways.

The simulator is convenient, repeatable, and easy to script. Use a clean status bar (full signal, a plausible time, a full battery) if you are going to show it. Turn off any debug overlays. Watch for blurry text, which can happen when you capture a scaled window rather than the native resolution. The simulator is also a poor source for camera, performance, or anything that depends on genuine sensors; for those, use a device.

A physical device gives you real photos, real blur, and the exact rendering of the phone you have. It also gives you notifications, a messy status bar, and the wrong account signed in, unless you prepare it. Make a capture checklist and use a dedicated test account with demo data you are willing to show the world.

For both:

• Set the appearance (light or dark) on purpose. If the app is dark, you can still lead with light if the store page reads more clearly that way, but then be consistent.
• Use Dynamic Type at a size a real person might choose, not the smallest, and not an accessibility size that crops every label unless the point of the frame is to show that support.
• Fill the app with believable data. The Placeholder Image tool can supply avatars and dummy pictures you are allowed to use; don’t scrape a friend’s photos into a public screenshot without their say-so.
• Hide empty states unless the empty state is the point. A first screenshot of a blank onboarding carousel is a waste of the most valuable frame.

If you also need a marketing image for the website, don’t just reuse a tall App Store screenshot as an Open Graph image. The crops are different. The OG Image Maker is the right shape for a link preview; the store wants the device sizes it lists.

A repeatable export process

The second time you ship screenshots should be faster than the first. Aim for a folder in the repo or a disk you control that contains:

• the brief for each frame
• the caption strings, per locale
• the source captures, named by frame and device
• a short script or a notes file that lists the current required sizes and the command you use to resize
• the final files, named exactly as you will upload them

A simple pipeline for a marketing-frame set is: capture at the reference size, place the capture on the background with the caption, export to PNG, then resize to each required size without changing the composition. For a raw-screenshot set, it can be even shorter: capture at each required simulator device, crop nothing, upload.

Check the output at 100% and at a small phone-on-a-table size. If the caption vanishes when the image is small, it was never doing any work.

When the UI changes, don’t edit the old PNG in a hurry if you can recapture. Edited screenshots drift from the app, and the drift shows. Treat a reshoot as part of the release, the way you would treat a version number.

Checking the product page on a phone

App Store Connect’s preview in a desktop browser is useful and not sufficient. Before you submit, and again when the page goes live:

• Open the product page on an actual iPhone, in search results if you can find yourself, and at the top of the page. Is the first screenshot still clear?
• Scroll the set at the speed a stranger would. Does the story make sense, or did you front-load a settings screen?
• Confirm each required size has the right files, and that you have not uploaded a landscape frame where portrait is required, or the other way around.
• Play the preview, if you have one, with the sound off, and with the sound on. Does it start on the app, or on a logo?
• Check every locale you claim.
• Compare the screenshots to the build you are actually submitting. No features that aren’t there, no old tab bar, no debug menu.
• Look at the iPad or Mac page too, if you have one. A stretched phone screenshot on iPad is easy to spot.

If something is wrong after release, you can usually replace screenshots without a full binary review, but you should confirm the current process in App Store Connect rather than assuming a metadata-only change always goes through instantly. Then look at the page on a phone again. The desktop preview will lie to you about scale.

Key takeaways

• The first screenshot has to show the job of the app at a small size; write a one-line brief for it before you capture.
• Confirm current required sizes in App Store Connect, design one maintainable set, and only add extra device families you actually ship.
• Prefer real UI, with captions only when they add a sentence you can stand behind, and localise those captions if you localise the page.
• A preview video is optional; if you make one, lead with the app, design the first frame as a poster, and assume the sound is off.
• Keep a short export pipeline and check the live product page on a phone against the build you are submitting.

If you want a second pair of eyes on a screenshot set, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.