App preview videos: hitting App Store and Play specs without a reshoot

Apple wants a file, Google wants a link#

The phrase "app preview video" hides a split that decides your whole workflow before you record a single frame. The App Store takes an uploaded video file with strict, device-specific specifications. Google Play takes no file at all: its promotional video is a YouTube URL you paste into the listing, and Google streams it from there. Same intent, two different deliverables. One is a rendering job with a hard target resolution; the other is a publishing job that lives on YouTube. Get the difference wrong and you will spend an afternoon exporting a flawless H.264 file for a store that only ever wanted a link.

The rest of this page is the exact numbers for each, collapsed into one table you can author against, plus the rule that makes both of them a recording problem rather than a filming one: the footage has to come off the real app.

Apple's app preview spec, number by number#

An App Store app preview is an uploaded video with narrow tolerances. Per Apple's App Store Connect reference, each preview runs 15 to 30 seconds, tops out at 500 MB, and ships as .mov, .m4v, or .mp4¹. The video track is H.264 High Profile up to Level 4.0 at a 10 to 12 Mbps target, or ProRes 422 HQ, and either way the frame rate is capped at 30 fps. You get up to three previews per localization, and the store lifts a poster frame from the 5-second mark by default.

The resolution is the part that trips people up, because it is fixed per device family and it is not your phone's native resolution. For the modern iPhone class — the 6.9-inch, 6.5-inch, 6.3-inch, and 6.1-inch displays — the accepted portrait resolution is 886 x 1920, or 1920 x 886 in landscape¹. That is smaller than the grid the phone actually paints: a 6.9-inch iPhone 16 Pro Max renders at 1320 x 2868 physical pixels⁵. So a raw screen capture off the device is the wrong size, and hitting the spec means exporting to an exact 886 x 1920 frame, not uploading whatever the recorder handed you.

Google Play's promo video: a YouTube URL, not an upload#

Google Play inverts nearly every one of those constraints. There is no file to encode and no resolution to hit, because you do not upload a video at all. In the Play Developer API, a store listing's promotional video is a single field described simply as the "URL of a promotional YouTube video for the app"⁴. You paste a YouTube link, Google embeds it, and the encoding, hosting, and playback are YouTube's problem rather than yours. There is no container to pick, no H.264 profile to match, and no 886 x 1920 to export to, because none of those numbers are yours to set.

That same API models a listing as a per-language object: the title, the descriptions, and that one video field all hang off a language BCP-47 tag⁴. So you get one promo video per localized listing, not a stack of device-specific cuts. A Play promo video is really a short YouTube video with a job. Everything that decides a click still has to land early, because it plays inline on the listing, but it inherits whatever quality YouTube serves rather than a codec you controlled.

One cross-store table to author against#

Here is the whole thing side by side. If you ship one product to both stores, this is the sheet that keeps you from encoding for the wrong target.

The single largest difference is the first row, and it cascades. On Apple you own the render and every pixel of the frame; on Google you own a YouTube upload and a link. Which container and codec to target is a live decision for the App Store file and a non-question for Play. Same with aspect ratio and orientation: Apple hard-codes it per device, Google inherits it from the YouTube video you point at.

"Captured on device" means you cannot fake the footage#

Apple narrows what the pixels may show harder than any resolution number does. App Store Review Guideline 2.3.4 says previews "may only use video screen captures of the app itself"³. Apple's App Previews page is blunter still: previews "demonstrate the features, functionality, and user interface of your app using footage captured on device," and you must "stay within the app," with no filming of "people interacting with a device, such as an over-the-shoulder angle or fingers tapping the screen"². Google's control is lighter because the asset is a link to a YouTube video, but the intent is the same: the preview should be the app, doing what the app does.

That one rule kills the shortcut a lot of marketing video takes. You cannot composite an App Store preview from stock clips, and a synthetic text-to-video render of an imagined interface is precisely what "screen captures of the app itself" forbids. The preview has to be the real UI doing real things, recorded off the running app. That constraint is what turns an app preview from a filming task into a capture task, and it is also why guideline 2.3 tells you to keep metadata "up-to-date with new versions": the store expects the footage to match the app people will actually download³.

The reshoot tax: previews times locales times every release#

Now multiply. Apple gives you up to three previews per localization¹. Localize the listing into five languages and you have authored, at the ceiling, fifteen App Store preview slots — fifteen separate 15-to-30-second cuts, each captured off the app, each landed on 886 x 1920. Add the Play promo video for each localized listing on top. That is the true surface area of "an app preview video," and none of it is a one-time cost, because guideline 2.3 asks you to keep it current and the footage rule means a single redesigned screen invalidates every clip that showed it.

A live-filmed preview has no cheap fix here. Because the footage came off a person driving the app in real time, one changed screen desyncs the cursor path, the timing, and the narration, so the honest response to a UI change is to shoot the whole cut again, times fifteen. This is the same staleness that quietly dates every product demo, except the App Store enforces it as a metadata-accuracy rule rather than leaving it to your conscience.

Hitting 886 by 1920 without shooting it twice#

The way out is the one that makes any product demo cheap to keep current: stop performing the capture and start replaying it. If the path through the app is a written script — open this screen, tap this control, wait for that result — then the capture is deterministic, and replaying the same flow yields the same footage every run. A UI change becomes a diff to the script and a re-render, not a fifteen-cut reshoot, and the multi-cut math above stops compounding: the localized set becomes a render matrix off one recording instead of fifteen separate shoots.

The exact tool depends on what the app is. For a native iOS build, the iOS Simulator records its own screen to a video file and the Android emulator has an equivalent, so you can drive a scripted run and export at the store's target size. For an app with a web surface — a PWA, a responsive web build, an embedded web view — a deterministic browser engine can pin the viewport and re-render on change; that is what our own tool, aidemo, does, with the honest limits that it captures a browser only (it will not record a native iOS binary), its storyboards are authored in code by a coding agent rather than dragged on a timeline, and there is no GUI editor. Whichever you reach for, the point is structural. Because the accepted resolution is a fixed number and the footage must come off the real app, the reliable way to land 886 x 1920 in H.264 is to make the capture reproducible, so the second time you need it costs a render instead of a shoot.

Sources#

1. Apple — App preview specifications (App Store Connect Help)
2. Apple — App Previews (Apple Developer)
3. Apple — App Store Review Guidelines (2.3 Accurate Metadata)
4. Google — Play Developer API, Listing resource (edits.listings)
5. Use Your Loaf — iPhone 16 screen sizes

FAQ#

What size and format does an App Store preview video need to be?#

Each app preview runs 15 to 30 seconds, stays under 500 MB, and uploads as .mov, .m4v, or .mp4 encoded in H.264 High Profile up to Level 4.0 (or ProRes 422 HQ), at a maximum of 30 fps. You may submit up to three previews per language. Resolution is fixed per device family: the modern iPhone class (6.9, 6.5, 6.3, and 6.1 inch) takes 886 x 1920 portrait, which is smaller than the phone's native pixel grid, so you export down to that exact frame rather than uploading a raw capture.

Can I use the same recording for the App Store and Google Play?#

The content can be the same, but the delivery cannot. Apple needs an uploaded H.264 file at a fixed device resolution (886 x 1920 for the modern iPhone class); Google Play needs only a YouTube URL, so it inherits YouTube's encoding and there is nothing for you to export. Plan one recording, export the file for Apple, and publish the same cut to YouTube for the Google link. Because Apple caps a preview at 30 seconds, a single tight cut can comfortably feed both stores.

Does an app preview have to be recorded on a real device?#

It has to be genuine app footage. Apple's Review Guideline 2.3.4 allows only screen captures of the app itself, and its App Previews page requires footage "captured on device" with no fingers or device frames in shot. In practice that means a screen recording from a device, from the iOS Simulator or Android emulator, or from the app's real web surface — not stock clips and not synthetic text-to-video of a UI that does not exist.