Turn an iPhone Recording into an App Store Preview

The recording exists. You used the iOS Control Center recorder, or captured a Simulator, and now it has to become an App Store preview — which means Apple's exact resolution, a 15-to-30-second runtime, and content that survives being watched muted in a search result.

Most of the work is not editing. It is meeting a spec, and the rejections almost always come from the same four places.

What Apple requires

Check the current requirements in App Store Connect before exporting, because Apple revises them. As of writing, the constants are:

• Length: 15 to 30 seconds. Not 14, not 31.
• Content: captured or rendered app footage. Not a lifestyle ad.
• Resolution and frame rate: device-family specific, usually 30 fps.
• Up to three previews per localisation.
• Audio optional — and mostly irrelevant, since previews autoplay muted.

The two that catch people out are length and resolution. A Control Center recording is whatever length you recorded and whatever resolution your phone is, and neither is guaranteed to match what the store wants.

Quick comparison

First: which recording should you use?

Three sources, and they are not equal.

Control Center recording on a real device. Easiest to get. Downsides: it captures your real status bar — actual time, battery and carrier — and includes the swipe-up and stop-recording moments. Real motion and real timing, which is its advantage.

iOS Simulator capture. Clean status bar (9:41, full battery, full signal), exact device dimensions, no fingers in the way. This is what Apple's own marketing material looks like. Downside: Simulator animations can run at a different pace to a real device, and anything involving the camera, sensors or real network conditions cannot be shown.

Real device recorded over USB from a Mac. The best of both: real device behaviour, but captured to your Mac at full quality with no on-device UI in the way. Requires a tool that supports it.

If you already have a Control Center recording and it looks fine, use it. If you are recording fresh and the app does not need real hardware, use a Simulator.

Method 1: ffmpeg

The most direct route to spec compliance, because you specify the spec exactly.

Step 1 — check what you actually have:

ffprobe -v error -select_streams v \
  -show_entries stream=width,height,r_frame_rate \
  -show_entries format=duration -of default=nw=1 recording.mov

Step 2 — trim to the right window. -ss is the start, -t is the duration:

ffmpeg -ss 00:00:04 -t 00:00:22 -i recording.mov -c copy trimmed.mov

Twenty-two seconds sits comfortably inside 15–30 with room to adjust.

Step 3 — conform resolution and frame rate:

ffmpeg -i trimmed.mov \
  -vf "scale=1080:1920:force_original_aspect_ratio=decrease,\
pad=1080:1920:(ow-iw)/2:(oh-ih)/2,fps=30,format=yuv420p" \
  -c:v libx264 -crf 18 -movflags +faststart preview.mp4

Replace 1080:1920 with the resolution Apple requires for your device family. The pad filter prevents distortion if the source ratio differs — though a mismatch usually means you recorded on the wrong device.

Step 4 — verify before uploading:

ffprobe -v error -select_streams v \
  -show_entries stream=width,height,r_frame_rate \
  -show_entries format=duration -of default=nw=1 preview.mp4

Duration between 15 and 30, resolution and frame rate matching the requirement. Confirm all three; do not trust the export preset.

Good for: exact control, free, scriptable for future releases.

Bad for: no preview while you work, and trimming by timecode means guessing then checking.

Method 2: Screenify Studio

Relevant here for two reasons: it records iOS directly, and it has an App Store Preview export mode that targets Apple's spec.

If you still need to record: it captures the iOS Simulator with zero-bezel output straight from the framebuffer, with a Clean Status Bar toggle that overrides to 9:41 with full battery and signal. It also records a real iPhone or iPad over USB, with a live mirror window while you record.

If the recording exists: open it from the welcome screen — Open Media takes MP4, MOV and M4V.

Step 1 — open or record the footage.

Step 2 — trim to the segment worth showing. Cut the swipe-up at the start and the stop-recording tap at the end.

Step 3 — place zoom on the two or three moments that matter. On an imported file you place these manually; on a recording made in the app, auto-zoom follows the taps for you.

Step 4 — add text overlays for the muted viewer.

Step 5 — add touch indicators if the recording came from a touchscreen and has no visible pointer. You place tap ripples on the preview at the playhead, and they render in the export.

Step 6 — export via App Store Preview, which produces the resolution, frame rate and format Apple expects for the device family.

Good for: covering the whole path, including the two things that are awkward elsewhere — a clean status bar and visible taps.

Bad for: macOS only, and a free-plan export carries a watermark, which the store will not accept. Shipping needs the paid plan.

Method 3: iMovie

Free and already installed.

Step 1 — import the recording into a new project.

Step 2 — trim on the timeline, watching the duration readout stay inside 15–30 seconds.

Step 3 — add titles for muted viewing.

Step 4 — export at the highest quality available.

Step 5 — verify with ffprobe, and convert if the resolution does not match Apple's requirement. This is the likely outcome: iMovie's presets are built around common video sizes, not App Store specs.

Good for: free, familiar, fine for a simple trim.

Bad for: the export step almost always needs a conversion pass afterwards, which means two encodes.

Method 4: Final Cut Pro

Worth it only if you already own it.

Step 1 — new project with a custom format matching Apple's required resolution and 30 fps exactly. Setting this at project level means the timeline is correct from the start.

Step 2 — import, trim, and add titles.

Step 3 — use the built-in duration readout to land inside the window.

Step 4 — export with a custom setting matching the project format.

Good for: precision, and no conversion pass because the project was correct from the beginning.

Bad for: overkill unless it is already part of your workflow.

Cutting 30 seconds out of a two-minute recording

Recording is easy; choosing what survives is the hard part. Most people record a full walkthrough and then try to speed it up, which never works — a fast-forwarded demo reads as panic.

Find the one moment that sells the app. Watch your recording once and note the timestamp where someone unfamiliar would understand the point. That moment is your anchor, and everything is built around it rather than leading up to it.

Start after the setup. Whatever it took to get to an interesting state — logging in, creating an item, navigating three screens deep — cut all of it. Begin in the middle of use. A preview that opens on a populated screen has already communicated more than one that opens on a login form.

Cut every wait. Loading spinners, network delays, animations that take a beat too long. On replay these feel three times longer than they did live. Cut them out entirely rather than trimming them shorter.

Keep the transitions. The moments where the UI moves — a sheet sliding up, a list reordering, a detail view expanding — are the parts that make an app feel real. Those are worth their seconds; navigation between them is not.

End on a resolved state. Task complete, item saved, result visible. Ending mid-scroll leaves the viewer with nothing to take away.

Then cut ten percent more. Whatever you land on, there is almost always another two or three seconds of slack. Twenty-five tight seconds beats thirty loose ones.

A practical check: play your cut with the sound off and ask what someone learns. If the answer takes more than one sentence, you are showing too much.

The taps problem, and why it matters more than it sounds

An iOS screen recording has no cursor. There is no pointer to follow, and by default no indication of where a finger touched. The result is a video where the interface changes for no visible reason.

On a real device you compensate without noticing, because you were the one touching it. A viewer cannot. They see a list, then a detail view, with nothing connecting the two. Over fifteen seconds of a preview, that adds up to a video that feels like it is skipping.

Three ways to handle it:

Add tap indicators in post. A small ripple at the touch point, placed at the right moment on the timeline. This is the cleanest solution and it is what most polished previews use, though it requires a tool that supports placing them.

Design the cut around visible cause and effect. If you cannot add indicators, favour interactions where the UI itself telegraphs what happened — a sheet sliding up from the bottom edge reads as intentional in a way an instant screen swap does not.

Use motion rather than jumps. Scrolling, dragging and swiping are legible without an indicator because the content moves continuously with the finger. Taps are the problem case specifically because they are instantaneous.

What not to do: film your hand over the phone. It reads as a low-budget unboxing video and Apple's guidance is for app content, not a person using a device.

Troubleshooting

Rejected for wrong dimensions. The most common rejection. Your recording is your device's native resolution, which may not be what Apple wants for that device family. Check the requirement, then conform with the scale filter above.

Rejected for length. Verify with ffprobe, not the editor's readout — rounding differences at the boundary have caused real rejections at 30.04 seconds.

The status bar shows real time and battery. Not fixable after recording. Either re-record on a Simulator with a clean status bar, or crop the status bar out — which changes your dimensions and means re-conforming.

Taps are invisible. iOS recordings have no cursor and, by default, no touch indicators. Viewers see the UI change with no visible cause. Either add tap indicators in a tool that supports them, or accept that the video is less clear than it should be.

The video looks soft. Re-encoding a compressed recording compounds loss. Trim with -c copy first — a lossless cut — then do exactly one quality encode.

Colour looks washed out. iOS records in HDR on newer devices, and a naive conversion flattens it. Force format=yuv420p and consider a tone-map filter if the difference is severe.

The file is too large. Raise CRF to 20–23. App previews are watched small; the difference is invisible and the file can halve.

Portrait video shows black side bars. You are padding a portrait clip into a landscape frame. Use the portrait resolution for that device family — Apple has separate requirements per orientation.

Simulator or real device: choosing deliberately

Both produce acceptable previews and they fail in different ways, so the choice should follow the app rather than convenience.

Record on a Simulator when the app is self-contained. A notes app, a calculator, a reader, a planner. You get a clean status bar, exact device dimensions, no thumb obscuring the screen, and the ability to re-record a take in seconds without picking up a phone. Apple's own material is largely captured this way, which is part of why Simulator footage reads as "official".

The catch is that a Simulator is not a phone. Animations can run at a different pace, scrolling physics feel slightly off, and anything touching real hardware — camera, GPS, Bluetooth, biometrics, push notifications, poor network — either does not work or does not behave realistically. If your app's value depends on any of those, Simulator footage will quietly misrepresent it.

Record a real device when the hardware is part of the product. Anything using the camera, anything location-based, anything where real-world latency matters. The footage is honest, and honest is worth more than clean.

The cost is the status bar showing your actual time and battery, plus the recording start and stop being visible. Recording over USB from a Mac avoids the on-device UI, which is the main reason that route exists.

A middle path that works well: record the hardware-dependent moment on a real device and everything else on a Simulator, then cut between them. Colour and timing usually match closely enough that nobody notices, and you get a clean status bar for most of the runtime.

One thing to check either way: record on the device family whose preview slot you are filling. A capture from a smaller phone scaled up to a larger family's resolution looks soft, and Apple's slots are per family for exactly this reason.

FAQ

Can I use a Control Center recording for an App Store preview? Yes, if you conform it to the required resolution and length, and the real status bar does not bother you. A Simulator capture usually looks cleaner.

Do I need a Mac? For App Store Connect uploads, yes. ffmpeg runs anywhere, but you will be on a Mac for the submission regardless.

How do I get the clean 9:41 status bar? Record from an iOS Simulator with a status bar override. Real devices show real values, and there is no reliable way to fake it afterwards.

Can I show taps in the video? Only if your tool adds indicators. iOS does not record them. Screenify Studio places tap ripples that render in the export.

How many previews should I make? Up to three per localisation. If you have three distinct stories, make three — each one is another chance to match what a browser is looking for.

Should the preview have a device frame? Not for the store, which draws its own frame. Framed versions are for your website and social posts.

What about iPad? A separate preview at that family's resolution. The same source can often be reframed rather than re-recorded, depending on how the layout adapts.

Can I add music? Yes if you own the rights, but previews are watched muted. Carry everything visually.

A pre-upload checklist

Run this before every submission. It takes two minutes and it is cheaper than a rejection round trip.

• Duration between 15 and 30 seconds, confirmed with ffprobe rather than an editor readout.
• Resolution and frame rate match the current requirement for that device family.
• No watermark anywhere in the frame, including one a free-tier export may have added.
• Status bar is clean, or you have accepted the real one deliberately.
• No recording UI — no swipe-up, no red status pill, no stop-recording tap at the end.
• Nothing identifiable in the content — no real customer names, no real email addresses, no internal URLs visible in a share sheet.
• First two seconds carry something. If the opening is a blank screen loading, cut deeper.
• Watched muted, it still communicates. Play it silent once and check.
• Text overlays are readable at store size, not just in your editor.
• Ends on a resolved state, not mid-scroll.

The last three are the ones that pass technical review and still fail with the person browsing. Apple's checks are mechanical; a viewer's are not.

The short version

Three things get you accepted: duration inside 15–30 seconds, resolution matching the device family, and content that reads muted. Verify the first two with ffprobe before every upload.

Already have a recording and want it fast: ffmpeg. Still need to record, and want a clean status bar and visible taps: Screenify Studio. You own Final Cut: use it.

Related reading: Turn app screenshots into an App Store preview video · How to create App Store preview videos on Mac · Add a device frame to a video you already recorded