Turn App Screenshots into an App Store Preview Video

App Store preview videos convert better than screenshots alone, and most indie apps ship without one. The usual reason is not laziness — it is that recording a clean demo of a real device is fiddly, and the screenshots already exist.

You can build a serviceable preview from stills. It will not beat a well-directed screen recording, but it comfortably beats no video at all, and it takes an afternoon rather than a week.

What Apple actually requires

Get this wrong and the upload is rejected, so it goes first.

• Length: 15 to 30 seconds.
• Content: captured or rendered app footage. Apple wants the app itself, not a marketing edit with actors and lifestyle shots.
• Resolution and frame rate: device-family specific, typically 30 fps. Check the current requirements in App Store Connect before exporting — Apple revises these.
• Count: up to three previews per localisation.
• Audio: optional. Most previews are watched muted.

Two practical consequences. First, 15 seconds is short — you get three or four screens, not a tour. Second, because it is watched muted, everything has to be carried visually. Text overlays do the work a voiceover would.

Quick comparison

Plan the sequence before you touch a tool

Fifteen seconds is roughly four screens at three to four seconds each. That budget forces a decision most people avoid: what is the one thing this app does?

A structure that holds up:

1. The hook (0–4s) — the screen that shows the core value. Not your splash screen, not onboarding. The thing people came for.
2. The proof (4–9s) — one or two screens showing it working. A list filling, a result appearing, a chart drawing.
3. The payoff (9–14s) — the outcome state. Task done, insight delivered, message sent.
4. The close (14–15s) — app icon and name, briefly.

Skip login screens, empty states and settings. Nobody downloads an app because its preferences panel looked nice.

Method 1: Screenify Studio

A macOS app that opens still images as if they were footage, which is what makes a screenshot-based preview possible without a video editor.

Step 1 — open your screenshots. Drag them into the welcome screen; drop several and they queue in order.

Step 2 — set the duration of each still on the timeline. Three to four seconds each is the right starting point.

Step 3 — add a device frame. For a preview that will sit on the App Store, a flat iPhone frame matching your capture device keeps the screen readable. There are 47 flat iOS device models, or a 3D stage if you want the phone at an angle.

Step 4 — add movement. A static image held for four seconds feels dead. Place a slow zoom on each still — a gentle push in toward the part that matters. This is the single change that makes a slideshow feel like a video.

Step 5 — add transitions between stills. Keep them short and plain; a cross-dissolve of a few frames is enough.

Step 6 — add text overlays. Since it will be watched muted, each screen needs a few words saying what it is. Three to five words, high contrast, on screen long enough to read twice.

Step 7 — export to App Store Preview spec, which produces the resolution, frame rate and format Apple expects per device family.

Good for: going from a folder of PNGs to a spec-compliant file without learning an NLE. Frames, zoom, transitions and the store export are all in one pass.

Bad for: macOS only. And the free plan watermarks exports — a watermark is not acceptable on a store preview, so this needs the paid plan to actually ship.

Method 2: ffmpeg

Free, scriptable, and reproducible — useful if you will regenerate the preview every release.

Step 1 — name your stills in order: 01.png, 02.png, and so on, all the same dimensions.

Step 2 — build the slideshow:

ffmpeg -framerate 1/3.5 -pattern_type glob -i 'shots/*.png' \
  -vf "scale=886:1920,fps=30,format=yuv420p" \
  -c:v libx264 -crf 18 -movflags +faststart preview.mp4

1/3.5 holds each image for 3.5 seconds. Adjust scale to your target device resolution.

Step 3 — add a slow zoom so it does not look like a slideshow:

-vf "zoompan=z='min(zoom+0.0008,1.12)':d=105:s=886x1920:fps=30,format=yuv420p"

d=105 is frames per image at 30 fps — 3.5 seconds. The zoom creeps to 1.12x over that time.

Step 4 — check the duration. It must land between 15 and 30 seconds:

ffprobe -v error -show_entries format=duration -of csv=p=0 preview.mp4

Good for: regenerating a preview every release with one command. Works on any OS.

Bad for: no device frames, no text overlays without more filter work, and zoompan is notoriously fiddly to get smooth. Expect to iterate.

Method 3: iMovie

Already on your Mac, and adequate for a simple sequence.

Step 1 — new project, import the stills.

Step 2 — set each clip's duration to about 3.5 seconds.

Step 3 — enable the Ken Burns effect for slow movement, then tune the start and end framing per image.

Step 4 — add cross-dissolves between clips.

Step 5 — add titles for the muted-viewing text.

Step 6 — export at 1080p and verify the resolution matches Apple's requirement for your device family.

Good for: free, installed, and familiar enough to finish in an hour.

Bad for: no device frames, and its export presets are not built around App Store specs, so you may need to convert afterwards. Ken Burns also tends toward more movement than a product preview wants.

Method 4: Rotato

Worth it when you want the phone itself animating in 3D rather than a flat sequence.

Step 1 — import your screenshots.

Step 2 — place them on a 3D device from the 30+ model library.

Step 3 — keyframe the camera so the device turns, pushes in or pulls back across the sequence.

Step 4 — set the background, or export with transparency to composite elsewhere.

Step 5 — export and check duration and resolution against Apple's spec.

Good for: a preview where the device motion is the visual interest. The animation control is the deepest here.

Bad for: a rotating phone makes screen content harder to read, which fights the purpose of a store preview. Also no text overlay tooling, so you will finish somewhere else.

Choosing the four screens

The tooling above is the easy part. Which screens you pick decides whether the preview works, and the instinct most people follow is wrong.

The wrong instinct is to show the journey. Sign-up, empty state, first item created, settings, result. It feels complete and it wastes twelve of your fifteen seconds on things nobody downloads an app for.

The right instinct is to show the product mid-use, already full. A populated list, a chart with real data, a conversation in progress. A viewer decides whether your app is for them by recognising their own situation in it, and an empty state contains nothing to recognise.

Practical selection rules:

• Skip anything before value. Splash screens, onboarding, permission prompts, login. All of it is friction the viewer will discover later.
• Use realistic content, not lorem ipsum. Placeholder text signals that the app is not finished. Fake but plausible data — real-looking names, believable numbers — reads as a working product.
• Pick screens that differ visually. Four list views look like one screen held for fifteen seconds. Vary the shape: a list, a detail view, a chart, a completion state.
• Show one differentiator explicitly. If your app does one thing competitors do not, that screen is mandatory and should get the most time.
• End on a resolved state. Task complete, message sent, report generated. Finishing on an unresolved screen leaves the viewer with nothing.

If you cannot pick four, that itself is information: either the app's value is hard to show visually, in which case text overlays have to carry more, or the preview should be shorter and sharper rather than padded to fill 30 seconds.

Making stills feel like motion

The gap between a preview that works and one that looks cheap is almost entirely about movement, and there are four techniques worth knowing.

Slow zoom, always inward. A push in reads as attention; a pull out reads as leaving. Keep it subtle — 8 to 12 percent over three or four seconds. Anything faster looks like a mistake and anything slower is invisible.

Vary the direction of the zoom target. If every still pushes into the centre, the rhythm gets mechanical. Push toward the top-left on one, the bottom-right on the next, following where the interesting content actually sits on that screen.

Cut on the beat, even without music. Holding every image for exactly 3.5 seconds is metronomic. Give the hook four seconds, the middle screens three, and the payoff four. The irregularity is barely perceptible but it stops the sequence feeling like a timer.

Let one element move within a still. If you can export two versions of a screen — a list with three items and the same list with five — a hard cut between them at the same zoom level reads as the app doing something rather than a slide changing. This is the closest a still-based preview gets to looking recorded, and it is worth the extra export.

What to avoid: spinning transitions, slide-ins, and anything with a bounce. Store previews are short and small; decorative transitions eat time and attention that the product needs.

Troubleshooting

Apple rejected the preview. Almost always duration, resolution or frame rate. Verify all three with ffprobe before uploading rather than trusting an export preset.

It looks like a slideshow. Because it is one. Add slow zoom to every still and keep transitions short. Movement is what separates a video from a carousel.

Text overlays are unreadable. Store previews play small in search results. Use large type, high contrast, few words, and hold each line long enough to read twice at a glance.

The screenshots are different sizes. Every still must match the target resolution exactly or the video jumps between frames. Normalise them first — magick mogrify -resize 1179x2556^ -gravity center -extent 1179x2556 shots/*.png.

There is a watermark. Free tiers watermark. A store preview cannot have one; this is the point where a free plan stops being enough.

The file is huge. Store previews have size limits. Raise the CRF to 20–23 — screenshots compress well and the difference is invisible at store playback size.

Colour looks shifted after export. A colour-space mismatch. Force format=yuv420p on export, which is also what most players expect.

Text overlays that survive muted autoplay

Since most previews are watched without sound, the overlays are not decoration — they are the script. Getting them wrong wastes the whole video.

Three to five words per screen. Not a sentence. "Track every subscription" works; "Screenify helps you keep track of all your recurring subscriptions in one place" does not, because nobody reads that in three seconds at store-preview size.

Say the benefit, not the feature. "Never miss a renewal" beats "Renewal notifications". The viewer is deciding whether this solves their problem, not auditing a feature list.

Position consistently. Put every overlay in the same place — usually the upper third, above the device — so the eye stops hunting. Moving overlays around the frame makes each one cost attention it should not.

Contrast harder than feels tasteful. Store previews are small and often viewed on a bright screen outdoors. Grey text on a light gradient disappears. White on a dark scrim survives.

Hold longer than reading speed. A four-word line takes about a second to read, but you should hold it three, because the viewer is also looking at the screenshot. Overlays that appear and vanish while the eye is elsewhere are wasted.

Do not translate the UI in the overlay. If the screen already says "Add expense", an overlay reading "Add an expense" says nothing. Use the overlay for what the screen cannot show — why it matters.

A quick check: mute your preview, play it once, and write down what you learned. If it is less than three things, the overlays need work rather than the visuals.

FAQ

Can I make an App Store preview from screenshots only? Yes. Apple requires app content, and screenshots of your app qualify. A real screen recording is better, but stills are allowed and far better than no preview.

How long can it be? 15 to 30 seconds. Anything outside that is rejected.

Do I need a real device, or is a Simulator fine? Simulator captures are fine and often preferable — a clean status bar and exact device dimensions. If you have a real device, recording it directly gives real motion, which beats stills.

Can I add music? Yes, if you have the rights. Most previews are watched muted, so treat audio as a bonus and carry everything visually.

How many previews can I upload? Up to three per localisation. If you have three ideas, ship three rather than cramming them into one.

Should the preview have a device frame? For the store itself, no — the preview plays inside a device frame the store draws. Frames are for previews you post on your own site or social. Check Apple's current guidance, since presentation details change.

What if my app is on iPad too? Separate previews per device family, at that family's required resolution. The same source stills can be reframed.

Can I do this on Windows? ffmpeg, yes. iMovie and Screenify Studio are macOS only. But you need a Mac for App Store Connect uploads anyway.

When to stop using stills and record instead

Stills get you a preview. They do not get you the best one, and it is worth knowing when the upgrade is worth the effort.

Record instead if the app's value is in an interaction. Drawing, dragging, gestures, real-time updates, anything where the motion is the product. A still sequence cannot show a swipe feeling good. Any app whose pitch includes the word "smooth" or "fast" needs footage.

Record instead if a transition is the selling point. If tapping an item expands it beautifully, that half-second is your best asset and a cut between two stills throws it away.

Stills are fine when the value is in the content. A budgeting app, a reader, a dashboard, a notes tool — the screens themselves carry the message and motion adds little.

Stills are also fine as version one. A preview built from screenshots today beats a perfect recorded preview that never gets made. Ship the still version, and replace it when you next have an afternoon.

If you do decide to record, an iOS Simulator gives clean output and exact device dimensions; recording a real device over USB gives real motion and real timing. Both routes are covered in turn an iPhone screen recording into an App Store preview.

The short version

Pick four screens, hold each for three to four seconds, add a slow zoom and a few words of text, and check the duration and resolution before you upload.

Scripting it every release: ffmpeg. Doing it once, quickly: iMovie. Device motion as the hook: Rotato. Stills to a spec-compliant, framed export in one pass: Screenify Studio.

Related reading: Turn an iPhone screen recording into an App Store preview · How to put a screenshot in an iPhone mockup · How to create App Store preview videos on Mac