App Preview vs Screenshots: What Converts Better on the App Store

You have one afternoon and two empty slots on your product page. One wants up to ten still images. The other wants a video of up to thirty seconds that you have not made yet. The question is which of the two is worth the afternoon.

Search app preview vs screenshot and you get six pages that answer it with a percentage. Five of those six are published by companies that sell screenshot generators, and all five conclude that screenshots matter more. The numbers may even be right. But an average across other people's apps was never going to tell you about yours, and Apple ships a free tool that will.

Quick verdict

• Do screenshots first, always. They are required, a preview is not. A listing without screenshots cannot ship; a listing without a preview is perfectly valid.
• Add a preview when motion is the argument. If what makes your app good is a gesture, a speed, a transition, or something changing — a still cannot carry it, and no amount of screenshot craft will fix that.
• Skip the preview if your value is a layout. A reference app, a reader, a calculator, a settings-heavy utility: stills show those completely, and a mediocre preview is worse than none.
• Then stop guessing. Apple's Product Page Optimization tests up to three alternate versions of your page against the original for up to ninety days and reports the confidence level. That is the only number about your app that means anything.

What each one actually is

The most useful fact about this comparison is that the two assets are not symmetric, and Apple decided that for you.

Screenshots are required. Every app needs them, at one to ten images per device size class. App previews are optional, at up to three per localisation, fifteen to thirty seconds each. That asymmetry is the whole reason the ordering question has an obvious answer even before you get to conversion.

Three behaviours matter more than the specs:

Previews autoplay muted. In search results and on the product page, the video starts by itself with the sound off. Any preview whose argument lives in a voiceover is broken by default, not by preference.

A preview is also a still. If a viewer has autoplay turned off, the App Store shows the poster frame instead — which defaults to the five-second mark unless you choose otherwise. Most people never choose, which means their preview also functions as a screenshot they did not design.

Screenshots carry the search-results impression. Someone scrolling results sees your first two or three images at thumbnail size, next to four competitors. That moment is decided by stills far more often than by video.

The pixel dimensions, codecs and duration bounds for both are a separate matter with their own rejection reasons; the spec sheet lives on the blog.

What screenshots do better

They are legible small. A screenshot with one bold caption survives being shrunk to a thumbnail. Thirty seconds of motion at that size is a blur.

They are cheap to change. Rewriting a caption and re-uploading is a ten-minute job. Re-cutting a preview is an afternoon, which means in practice screenshots get iterated and previews get made once and left alone for two years.

They need no take. No clean run, no performance, no timing. This is why they exist for every app and previews exist for some.

They work with the sound off, and with autoplay off, and on every device class. There is no state in which a screenshot degrades.

What a preview does that a screenshot cannot

Show that it is real. A screenshot set can be, and often is, a design mockup. A preview of the app running is evidence that the software exists and behaves.

Show speed. If your app is fast, that is invisible in a still. It is the entire content of three seconds of video.

Show a gesture. Swipes, drags, pinches, anything with a physical feel. A still can only label these.

Show a transformation. Before and after — an empty canvas becoming a finished thing — is the strongest case for video, because the interesting part is the change rather than either state.

The test is not "would a video be nicer". It is: can a still image carry your app's best moment? If yes, screenshots are sufficient and a preview is polish. If no, the preview is not optional in any meaningful sense.

Why every number on this page's competitors is someone else's app

The pages ranking for this query cite conversion figures — a percentage lift from adding video, a higher lift for games, a share of install decisions attributed to screenshots. You will see the same numbers on several of them.

I have deliberately not repeated any of those figures here, for three reasons.

Nobody names a primary source at the point of citation. The numbers circulate between articles. Tracing one back to a study with a methodology, a sample and a date is harder than it should be for something presented as settled.

The publishers have an interest. Five of the six results on this SERP are screenshot-tool companies, and all five conclude that screenshots do more of the work. That does not make them wrong. It does mean the finding and the business model point the same direction, and you should notice when that happens.

An average cannot answer a specific question. Even a perfectly sourced figure would be a mean across thousands of listings spanning games, banking apps and to-do lists, with different traffic, different categories and different creative quality. Your app is one listing. The variance between apps in a category is larger than the difference the average is describing.

The useful version of "which converts better" is always "which converts better for this listing, right now" — and that is a question you can actually answer.

How to actually measure it: Product Page Optimization

Apple ships an A/B test for exactly this decision, free, inside App Store Connect. It tests app icons, screenshots and app previews. These are its published limits, read from Apple's developer documentation on 20 August 2026:

• Up to three alternate treatments against your original, and one test at a time.
• Up to 90 days, or until you stop it.
• You choose the traffic share. Apple's own example: allocate 40% across two treatments and each treatment gets 20%, with the original keeping 60%.
• A given person sees the same treatment throughout, so results are not muddied by someone seeing both.
• The dashboard reports impressions, conversion rate, percent improvement and confidence level.
• A treatment is only called better or worse at 90% confidence or above. Below that, you have not learned anything, whatever the percentages look like.
• You cannot change a test once it has started. Set it up properly the first time.

Running the test that answers this question

1. Ship the screenshots first and let them settle. They are required anyway, and they are your baseline. Do not test against a page you are still editing.
2. Make one preview, aimed at the single moment a still cannot carry. Not a tour.
3. Create one treatment: your existing page plus the preview. Change nothing else — not the icon, not the screenshot order. One variable, or the result means nothing.
4. Allocate traffic you can afford to split. Higher share reaches confidence sooner; it also exposes more people to the version that might be worse.
5. Leave it alone. Checking on day three and reacting to an early lead is how people conclude the opposite of the truth. You cannot change the test anyway.
6. Read the confidence level before the percentage. Under 90%, the answer is "not yet", regardless of how good the improvement looks.
7. If it wins, keep it and test the next thing — the poster frame is a good second test, since it is what non-autoplay viewers actually see.

That sequence takes weeks rather than an afternoon, which is why every page on this SERP prefers to quote an average. It is also the only way anyone finds out.

While you are at it, choose the poster frame

Since the poster frame defaults to five seconds in, it is worth deciding what lands there rather than discovering it later.

0.0s  App open, populated state      ← the frame people see if autoplay is off
1.5s  First interaction begins
3.0s  The result appears
5.0s  DEFAULT POSTER FRAME lands here — make sure it is not a transition

If second five of your preview is a half-finished animation or an empty sheet, that is the still a share of your visitors will see instead of the video.

Which one you should build first

Screenshots, in every case. They are required, they are cheap to revise, and they carry the search-results impression. There is no app for which the correct order is reversed.

Then a preview, if your best moment moves. Games, anything gestural, anything whose selling point is speed or a transformation. For these, the preview is not decoration — it is the only place the argument can be made.

Then a preview anyway, eventually, if you have the time. Even for a layout-driven app, a preview proves the software is real, and the poster frame gives you one more designed still. Just do it after the screenshots are good, not instead.

And a test, once both exist. Everything above is a prior. Product Page Optimization is the evidence.

Frequently asked questions

Do I need an app preview video?

No. Screenshots are required for an App Store listing and app previews are optional, so a listing with strong stills and no video is complete and valid. You need one when your app's value is something a still cannot show — a gesture, a speed, a transformation. If a screenshot captures your best moment fully, the preview is polish rather than a requirement.

Can I have an app preview without screenshots?

No. Screenshots are mandatory per device family and a preview cannot substitute for them, so a listing with only a video will not pass submission. The dependency runs one way: you can ship screenshots with no preview, but not the reverse. This is the clearest signal Apple gives about which asset to build first.

How many screenshots should an App Store listing have?

Apple allows one to ten per device size class, and the first two or three do almost all of the work, because those are what appear in search results before anyone taps through. Three strong images beat ten mediocre ones. Use the later slots for secondary reasons to download rather than padding the set out to the limit.

Does the app preview play automatically?

Yes, and with the sound off by default, both in search results and on the product page. If a viewer has disabled autoplay, the App Store shows a still instead — the poster frame, which defaults to the five-second mark unless you set it. So a preview needs to make sense muted, and its fifth second needs to be a frame worth showing on its own.

Where to start

Fill the screenshot slots properly this afternoon. That is the required asset, the one that carries the search-results impression, and the cheapest to improve later.

Then be honest about whether your app's best moment holds still. If it does not, the preview is the only place that argument can be made, and putting it off is not a neutral choice — it just means the argument goes unmade.

If your app is on Apple platforms and what stops you is the recording, Reely drives the feature in the iOS Simulator and composites the reel from a flow you describe rather than one you perform. That makes the preview cheap enough to re-cut when the UI changes. The docs cover how a flow is written, or download it for Mac and try it on the one screen you would put in a preview.