App Store Preview Video: Specs, Sizes and Requirements

The build is signed and uploaded. App Store Connect shows an empty App Preview slot beside your screenshots, and the file you exported this morning bounces with a line about the wrong resolution. Nothing tells you which number was wrong.

The specs themselves are all published. Apple lists every accepted resolution, the codec, the bit rate, the audio configuration and the duration bounds on one page. What no guide publishes is the awkward part of shipping an App Store app preview. No iPhone produces a recording at the resolution Apple accepts, so every upload involves resampling — and one resampling decision that most guides get wrong.

This is the spec sheet plus that decision. Every number below comes from Apple's app preview specifications page in the App Store Connect Help, read on 6 August 2026.

The short answer

An app preview is a 15-to-30-second video of your app running, uploaded per device size class and per language. Current iPhones accept 886 x 1920 portrait; iPads accept 1200 x 1600; Mac and Apple TV accept 1920 x 1080. Files must be H.264 or ProRes 422 HQ, 30 fps maximum, under 500 MB.

What an App Store app preview actually is

An app preview is a short video of your own app in use, hosted by Apple on your product page rather than embedded from YouTube. It plays inside App Store search results as well as on the listing, it can be reused in Apple Ads, and it autoplays.

Two behaviours shape everything you produce. Previews autoplay with the sound muted by default. Apple's own guidance is to "consider using copy to add additional context to your footage," which is a polite way of saying the audio track will not be heard. And if a user has turned autoplay off, the App Store shows a still instead: the poster frame, which defaults to the five-second mark unless you pick another.

Previews are optional. Screenshots are not. A listing with no preview is valid; a listing with a preview and no screenshots is not. That ordering matters when you are deciding where to spend a launch afternoon.

Every accepted resolution, by device slot

Apple accepts a fixed pixel size per size class, and App Store Connect refuses anything else before your file ever reaches review. These are the app store preview video dimensions as published on 6 August 2026.

iPhone

• 6.9-inch, 6.5-inch, 6.3-inch and 6.1-inch. 886 x 1920 portrait, 1920 x 886 landscape. One accepted size covers all four classes, which is why most apps upload exactly one iPhone preview.
• 5.5-inch. 1080 x 1920 portrait, 1920 x 1080 landscape. The plus-size iPhone 6 through 8 generation.
• 4.7-inch. 750 x 1334 portrait, 1334 x 750 landscape.
• 4-inch. 1080 x 1920 portrait, 1920 x 1080 landscape.
• 3.5-inch. Not supported at all.

iPad

• 13-inch, 11-inch and 10.5-inch. 1200 x 1600 portrait, 1600 x 1200 landscape.
• 12.9-inch (2nd generation). 1200 x 1600 or 900 x 1200 portrait, and the landscape equivalents.
• 9.7-inch. 900 x 1200 portrait, 1200 x 900 landscape.

Mac, Apple TV and Apple Vision Pro

• Mac. 1920 x 1080, landscape only.
• Apple TV. 1920 x 1080, landscape only.
• Apple Vision Pro. 3840 x 2160, landscape only.

You do not have to fill every slot. Apple scales an unfilled class down from a larger one: leave the 6.1-inch iPhone slot empty and it plays the 6.5-inch file, leave the 11-inch iPad empty and it plays the 13-inch file. Uploading one iPhone preview and one iPad preview covers the whole matrix.

What does not carry over is language. Previews attach to a localisation, not to the app, so a file uploaded under English does not appear on your German or Japanese product page. If you ship five localisations and want a preview on each, that is five uploads of the same file — or five different files, which is the better answer if your on-screen text is localised.

The rest of the file spec

• Duration. Minimum 15 seconds, maximum 30. App Store Connect rejects a 14-second file as firmly as it rejects a 31-second one.
• Count. Up to three previews per language your app supports.
• File size. 500 MB maximum.
• Poster frame. Defaults to five seconds in. Changing it after approval requires resubmission, so choose it before you submit.
• H.264. Target bit rate 10 to 12 Mbps VBR, progressive, up to High Profile Level 4.0, 30 fps maximum. Extensions .mov, .m4v or .mp4.
• ProRes 422 (HQ only). Roughly 220 Mbps VBR, progressive, no external references, 30 fps maximum, .mov only.
• Audio. Stereo, 256 kbps AAC (or PCM for ProRes), 44.1 kHz or 48 kHz sample rate, all tracks enabled. Either one track carrying two-channel stereo, or two tracks carrying one channel each.
• Orientation. Portrait or landscape on iPhone and iPad. Landscape only on Mac, Apple TV and Vision Pro.

Previews autoplay muted. Whatever your audio track does, the story has to land with the sound off — which is why on-screen text and clear motion do more work here than a voiceover.

Why no iPhone recording is already 886 x 1920

Here is the thing every spec list leaves out. Divide the accepted iPhone portrait size and you get 1920 ÷ 886 = 2.1670. Now divide the device resolutions Apple lists on the same page:

• A 6.9-inch iPhone at 1320 x 2868 gives 2868 ÷ 1320 = 2.1727.
• A 6.3-inch iPhone at 1179 x 2556 gives 2556 ÷ 1179 = 2.1679.
• A 6.1-inch iPhone at 1170 x 2532 gives 2532 ÷ 1170 = 2.1641.

None of them equal 2.1670. Apple has never explained where 886 came from, and the practical effect is that a native recording never maps cleanly onto the slot. Scale a 1320 x 2868 capture down to 886 pixels wide and you land at 1925 tall: five rows too many. Scale a 1170 x 2532 capture the same way and you land at 1917: three rows short.

Five pixels sounds like nothing. It is the whole problem, because it forces a choice that App Store Connect cares about a great deal.

A centre crop takes those five rows off the top and bottom of the frame, which on an iPhone capture means two or three pixels of the status bar area and two or three from the home indicator. Nothing readable lives there. The same crop applied horizontally would be a different conversation, and that is the case to watch when your source is wider than the target rather than taller.

You can crop the overflow, losing five rows out of 1925 — about a quarter of one percent of the frame height, invisible in practice. Or you can fit and pad, scaling the whole frame until it sits inside 886 x 1920 and filling the leftover with black bars.

Almost every ffmpeg recipe circulating for this task pads. That recipe is old, it is widely copied, and it produces a file that Apple has a documented habit of rejecting.

How to export a preview that App Store Connect accepts

Six steps, from a running build to an uploadable file.

1. Pick the source with the largest native frame. A 6.9-inch iPhone or its Simulator gives you 1320 x 2868 to crop from. Starting from a smaller device means upscaling, and upscaled UI text is the first thing a reviewer sees.
2. Clean the status bar before recording. Carrier names, a half-empty battery and a stray notification badge all read as sloppy, and Apple's demo standard has been 9:41 with full signal since 2007.
3. Record the take. The Simulator writes a file at exactly the device's native pixel size, which is what you want as a crop source.
4. Trim to between 15 and 30 seconds. Aim for 20 to 25 so the trim survives a re-cut without falling under the floor.
5. Cover and crop to the slot resolution. Scale so the frame covers 886 x 1920, then cut the overflow. Never pad.
6. Encode to Apple's H.264 numbers — High Profile, Level 4.0, 10 to 12 Mbps, 30 fps, stereo AAC at 256 kbps.

Steps two and three, if you are recording an iOS app demo from the Simulator:

xcrun simctl status_bar booted override \
  --time "9:41" --batteryState charged --batteryLevel 100 \
  --cellularBars 4 --wifiBars 3 --operatorName ""

xcrun simctl io booted recordVideo --codec h264 take.mov

Then steps five and six, in one pass:

# 6.9" / 6.5" / 6.3" / 6.1" iPhone slot — 886 x 1920
ffmpeg -i take.mov \
  -vf "scale=886:1920:force_original_aspect_ratio=increase,crop=886:1920,fps=30" \
  -c:v libx264 -profile:v high -level 4.0 -pix_fmt yuv420p \
  -b:v 11M -maxrate 12M -bufsize 24M \
  -c:a aac -b:a 256k -ar 48000 -ac 2 \
  preview-iphone.mp4

The load-bearing token is increase. It scales the source until it covers the target box, and crop then removes the overflow from the centre. The recipe you will find on most blogs uses force_original_aspect_ratio=decrease followed by pad=886:1920:(ow-iw)/2:(oh-ih)/2:color=black, which does the opposite: it shrinks the frame to fit and paints bars into the gap. Swap 886:1920 for 1200:1600 and you have the iPad command.

Check the result before you upload, because App Store Connect will only tell you that something is wrong, not what:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,r_frame_rate,codec_name,profile,level \
  -show_entries format=duration,size -of default=noprint_wrappers=1 \
  preview-iphone.mp4

You are looking for width=886, height=1920, a frame rate at or under 30, codec_name=h264, profile=High, level=40, a duration between 15 and 30, and a size under 500 MB. Every one of those maps to a bounce you would otherwise discover on upload day.

What Apple rejects, and the guideline it cites

Two kinds of rejection exist, and they arrive at different times.

Technical bounces happen at upload, before a human sees the file. The causes are the spec, restated: a resolution that is not the exact accepted size for that slot, a duration under 15 or over 30 seconds, a file over 500 MB, a frame rate over 30, an unsupported container, or an audio configuration that is not stereo with all tracks enabled.

Content rejections happen in review and cite Guideline 2.3.4, Accurate Metadata. Apple's public guidance is blunt: app previews "demonstrate the features, functionality, and user interface of your app using footage captured on device," and "App previews must show only content within the app itself. Don't film people interacting with a device, such as an over-the-shoulder angle or fingers tapping the screen."

In practice, developers report two 2.3.4 rejections repeatedly on Apple's own forums. One thread from 2020 that developers were still adding to in 2024 quotes the rejection verbatim: "Your app preview includes content that does not sufficiently reflect the app in use. Specifically, your preview: Includes device images and/or device frames." A more recent thread quotes a closely related one: "The app preview includes framing around the video screen capture."

That second phrasing is why padding matters.

Black bars are framing. A bezel is framing. A phone rendered on a coloured background with the app playing inside it is framing twice over.

Apple applies this inconsistently. The same composition is accepted for one build and rejected for the next, and developers on that thread report exactly that. The asymmetry is not in your favour: a rejected preview costs you a review cycle, and review cycles during a launch week are the expensive kind.

Also disallowed: specific prices, seasonal references that will date the video, and anything not appropriate for all ages.

Where a composited mockup reel belongs instead

This is the part worth being honest about, because it applies to the tool I work on.

Reely composites finished product videos — a phone in a padded canvas, camera moves that zoom toward each interaction, captions, a brand theme pulled from the app's own icon. Its output canvas is device-native portrait, 1080 x 1920, or 1920 x 1080. Against the slot table above, that means:

• 1920 x 1080 matches exactly what Mac and Apple TV accept, and the 5.5-inch and 4-inch iPhone landscape slots.
• 1080 x 1920 matches exactly the 5.5-inch and 4-inch iPhone portrait slots — and not the 886 x 1920 that every current iPhone wants. Cover-and-crop from 1080 to 886 discards 18% of the frame width, which on a composited canvas eats the padding and starts clipping the device.
• Neither 886 x 1920 nor 1200 x 1600 is a Reely output. Nothing here scales to the modern iPhone or the iPad slot without a resize step.

And the composited look, which is the point of the tool, is the exact thing that draws a 2.3.4 framing rejection.

So the honest split is by destination. For the App Store slot, take the raw full-bleed recording: reely run --no-effects writes a plain trimmed capture of the driven flow at the Simulator's native resolution, which is the best crop source you can get. For the landing page, the launch post, the Product Hunt embed and everything on social, use the composited reel, where a device frame is an asset rather than a liability. The FlowSpec and composition reference in Reely's docs covers both paths, and the broader category of tools that generate app demo footage rather than record it all face the same split.

One limit worth stating plainly: this workflow is Apple-platform only. There is no Android or web equivalent here, and the App Store preview slot is not the place to discover that.

Frequently asked questions

How long can an App Store preview video be?

Between 15 and 30 seconds. Both bounds are hard: App Store Connect rejects a 14-second file and a 31-second file at upload, before review. Twenty to twenty-five seconds is the practical sweet spot, because it leaves room to re-trim after feedback without dropping under the minimum and forcing a re-export from the original take.

How many app previews can you have per app?

Up to three per language your app supports, per device size class. Most apps ship one, because a single iPhone file at 886 x 1920 covers the 6.9-inch through 6.1-inch classes and Apple scales unfilled slots down from larger ones. Add a second only if it shows a genuinely different flow rather than a re-cut of the first.

What is the difference between an app preview and a screenshot?

A screenshot is a still image and is required; an app preview is a 15-to-30-second video and is optional. They also have separate size tables — screenshots use full device pixel dimensions, previews use their own accepted resolutions such as 886 x 1920. Previews autoplay in search results, which is the main reason to produce one.

Can you record an App Store preview in the iOS Simulator?

Yes. Apple's guidance says footage must be captured on device, and Simulator recordings are widely used and accepted in practice. The Simulator writes at the device's exact native pixel size, gives you a controllable status bar, and needs no cable. Confirm any animation that depends on real hardware behaves the same before you submit.

Getting the take before you get the file right

The spec is the easy half. The hard half is the take: fifteen to thirty seconds of your app doing one thing cleanly, with no fumbled tap and no loading spinner in the middle, re-recordable when the UI changes next sprint.

If you want that take to be repeatable rather than a fifteenth attempt at a clean run, download Reely for Mac. It drives the feature in the Simulator from a spec file and records the result, so the next re-record is a command rather than an afternoon. Then crop, encode, upload.