App preview videos are one of those parts of App Store Connect that look straightforward in the docs and get complicated the first time you actually try to ship one. We've uploaded enough of them across our own releases at Olnesta Ltd to have a working sense of where the friction really is, and it's usually not where a first-time submitter expects.
The short version: previews have to be captured from the real app, sized correctly for each device family, kept under thirty seconds, and structured so the opening moments do the work. Everything else follows from those four constraints.
Real footage, not a pitch
Apple expects a preview to reflect what's actually in the app. That means captured gameplay or captured UI from the build you're shipping, not a motion graphics reel that shows an idealized version of the product. Staged UI, mocked-up screens, or footage from a different build is a rejection risk on its own, separate from anything else about the submission.
In practice this rules out a few things that tempt every team at some point: rendering a fake home screen in a design tool because the real one isn't quite ready, splicing in a feature that only exists on an internal branch, or cutting from a real capture to a promotional shot of a device in someone's hand. You can add short text overlays and a soundtrack, and light editing between real captures is fine, but the frames of the app itself need to be the app itself.
The honest reason this matters, beyond the review guideline, is that a preview built from real footage ages with the product. When you ship the next update, you re-record from the new build and you're done. A preview built out of custom motion graphics has to be rebuilt by whoever made it every time the UI shifts, and that person is often not available on the week you need them.
Sizing and the per-device-family requirement
Previews are uploaded per device family, and each one needs to be sized and oriented for the device it's shown on. You can't take a single iPhone capture and have it stand in for iPad; App Store Connect wants a preview built for that surface, at the resolution and orientation it expects. If your app supports iPhone and iPad, plan on a separate capture pass for each.
You're allowed up to three previews per localization, each under thirty seconds. Three is a ceiling, not a target. One well-cut preview outperforms three loose ones, and every additional preview is another asset to re-render the next time the UI changes. For most of our releases we ship one per device family per locale and revisit whether a second is worth it only when there's a genuinely distinct mode or surface worth showing.
Capture is easiest done through the built-in screen recording on a real device, or via QuickTime with a device tethered to a Mac. The Simulator can work in a pinch but tends to produce footage that doesn't quite match a real device's frame timing, and it's the sort of small mismatch a reviewer might notice on a marginal call.
The first few seconds
The part of the spec that gets underweighted is what happens before anyone taps. On the product page, the first preview autoplays muted. Whatever is on screen in those opening seconds is what most viewers will ever see of the video, and it has to make sense with no sound and no context.
What this means concretely: don't open on a splash screen, don't open on a logo, don't open on an empty state that only makes sense once you know what the app does. Open on the app doing the thing it does, framed so a stranger can tell what they're looking at. If there's a headline moment in the preview, put it near the start rather than saving it for a reveal at second twenty five, because most people won't get to second twenty five.
We've found it useful to watch our own preview muted, on a phone, on the actual product page in TestFlight-adjacent conditions, before signing off. It's a different experience from watching the edit in a video tool with sound on, and problems that were invisible in the edit tend to be obvious there.
What this means for the next release
Treat the preview as part of the build, not part of the marketing. Record from the shipping build, size for each device family you support, keep it under thirty seconds with the strongest frames up front, and accept that you'll re-record when the UI changes enough to matter. That's most of what there is to it, and most of the rejections and awkward resubmissions we've seen come from bending one of those points rather than from anything more exotic.