An app preview is the strictest video a team makes for its app. Apple fixes the length, the pixel size, the frame rate and what the footage may show, and the clip plays on the product page, where people decide whether to install.
The same recording usually has to serve a landing page, a launch post and the store listing, and those cuts pull in different directions. A site hero wants a device frame and a zoom into the tapped button. The store cut wants the plain screen at native sharpness, captions that read without sound and a runtime of 30 seconds or less.
Apple’s rules and file specs come first, then the capture, edit, export and upload. We build CoAnimator, an agentic animation studio where a coding agent assembles the video from a description while a live stage shows the result. The edit and export steps use it, and Apple’s requirements apply to any editor.
An app preview plays before anyone reads the listing
Apple’s term is app preview, and teams also search for it as an app promo video, an app store preview video or a mobile app promo video. A preview autoplays on the product page and in search results, and Apple’s creative guidance states previews play muted by default. The first seconds have to make sense on a silent screen.
A listing holds up to three previews per device size and language, always ahead of the screenshots. Visitors with autoplay turned off see the poster frame, a single still chosen from the video, so that one frame has to represent the whole clip. A preview whose aspect ratio differs from the screenshots moves to a section called A Closer Look, and iMessage apps cannot have previews.
The rest of this guide follows Kitchenly, a made-up meal-planning app, through a 24-second preview from capture to upload.
A preview pays off when the value sits in a sequence
Admiral Media’s September 2026 review of the top 50 free apps in each of 20 US categories found a preview on 12.2% of the 1,000 apps. Games led at 28% and finance and books sat at 4%. The numbers show how unevenly teams use previews, not whether previews work.
Proof of lift is thin. A 20 to 40 percent install gain circulates widely, and one ASO review traces it to a single anecdotal vendor claim with no published method. Apple publishes no typical lift, but product page optimization lets a team test up to three alternative versions of icons, screenshots or previews against the live page. Apple’s tech talk recommends changing one asset at a time and waiting for statistical significance.
A useful rule of thumb separates the two formats. A screenshot shows one state of the app, while a preview shows what happens between states. Kitchenly’s best moment is a recipe swap followed by the shopping list updating, which a still cannot show, so it suits a preview. A single-screen utility has no such sequence. Treat the rule as a starting guess and let the test decide.
Apple’s rules change how footage gets shot
Apple’s guidance asks for footage from inside the app, with no film of people interacting with a device and no fingers tapping the screen. Content must suit all ages, and music, brands and other protected material need marketing rights in every territory. Touch hotspots are allowed, and Apple prefers the native UI resolution to zooming in.
| Habit in a social cut | What the store cut does instead |
|---|---|
| A hand holding the phone | Shows the screen alone, with a touch hotspot graphic where a tap needs showing |
| A punch-in zoom on a button | Keeps the interface at the sharpness it was recorded, as Apple recommends |
| Whip or glitch transitions | Uses simple dissolves or fades, with nothing implying a feature the app lacks |
| “New for spring” text or a price | Leaves out seasonal references, dates and prices, since they age fast and vary by region |
| Trending audio | Uses music and sound the team has marketing rights to in every territory |
A preview showing a feature behind an in-app purchase, a subscription or a login must say so, either in the footage or on the end frame. On-screen copy must be legible and stay up long enough to read.
Apple’s page does not mention device frames, but it asks for content within the app itself, and a bezel sits outside the app. The store cut skips the frame. Demo data deserves the same care, because a Kitchenly demo account whose menu reads “New for spring” breaks the dated-reference rule before any editing starts.
Accepted sizes depend on the device class
Apple lists two sizes for each display class, the device’s own resolution and the accepted resolution for uploads, and asks for the accepted one. An iPhone 17 Pro Max screen is 1320 × 2868, so a raw capture has to be scaled or cropped to 886 × 1920.
| Display class | Example devices | Portrait | Landscape |
|---|---|---|---|
| iPhone Duo, Dynamic Island and Face ID, large and medium displays | iPhone 17 Pro Max, iPhone Air, iPhone 16, iPhone 14 Plus, iPhone 13, iPhone XR | 886 × 1920 | 1920 × 886 |
| iPhone with Home Button, large display (5.5-inch) and 4-inch display | iPhone 8 Plus, iPhone 7 Plus, iPhone SE (1st generation) | 1080 × 1920 | 1920 × 1080 |
| iPhone with Home Button, medium display (4.7-inch) | iPhone 8, iPhone SE (2nd and 3rd generation) | 750 × 1334 | 1334 × 750 |
| iPad 13-inch, 12.9-inch, 11-inch and 10.5-inch | iPad Pro, iPad Air, iPad mini (A17 Pro), iPad (A16) | 1200 × 1600 | 1600 × 1200 |
| iPad 9.7-inch | iPad Air 2, iPad (6th generation), iPad mini 4 | 900 × 1200 | 1200 × 900 |
| Mac and Apple TV | Any Mac, Apple TV | Not available | 1920 × 1080 |
| Apple Vision Pro | Apple Vision Pro | Not available | 3840 × 2160 |
Apple groups iPhones by display class rather than screen diagonal, so a 6.9-inch Pro Max and a smaller Pro model share one size. iPhone and iPad previews can be portrait or landscape and rotate on playback, while Mac, Apple TV and Vision Pro previews must be landscape. When the interface looks the same across sizes, uploading the largest size is enough, and App Store Connect scales it down for the rest.
The file itself has limits too. H.264 previews can be .mov, .m4v or .mp4 at 10 to 12 Mbps, progressive, up to High Profile Level 4.0. ProRes 422 HQ must be .mov at roughly 220 Mbps. Both share a ceiling of 500MB, a runtime of 15 to 30 seconds and 30 fps or less. Audio is optional, and when present it is stereo at 44.1 or 48 kHz, AAC at 256 kbps for H.264 or PCM or AAC for ProRes, with all tracks enabled.
ProRes fills the 500MB cap quickly, since 220 Mbps reaches it near the 18-second mark. H.264 is the practical choice for Kitchenly’s 24 seconds. Apple revises the table as hardware ships, so check the specification page on the day of export.
Capture on a real device first
Apple’s guidance names QuickTime Player on a Mac, which records the screen of an iPhone or iPad connected by cable. The iPhone’s built-in screen recording followed by an AirDrop to the Mac is a second route. A device recording can run at 60 fps, above Apple’s ceiling, so the frame rate gets corrected at export.
Set up the device before pressing record. Use a demo account with realistic data. Switch on Do Not Disturb so no banner crosses the frame. Charge the phone, because a 12% battery icon sits in every frame. Rehearse one path of about 20 seconds, then record each scene as its own take with a few seconds of margin on both ends.
CoAnimator does not record device screens. Its documentation lists no desktop screen recorder, and its screen capture plugin captures websites rather than phone screens. A raw screen recording is material for the edit, so record with QuickTime or the phone, bring the file in and edit the footage by describing the look.
Build the store cut in CoAnimator
CoAnimator sits between the capture and the upload. It turns a recording into a finished cut. Describe the scenes, captions and pacing to a connected coding agent, watch the cut take shape on the live stage and render an MP4 on the computer. The project stays as editable files, so a new caption or a fresh recording means a re-render rather than a rebuild. The upload itself still happens in App Store Connect.
Drag the capture into the media panel to start. CoAnimator’s app promo videos workflow follows the same path and produces several cuts from one recording, including a portrait store preview. Its marketing cuts use device frames, so the store cut needs a brief telling the agent to leave them out.
The Kitchenly brief reads as follows.
Build the App Store preview for Kitchenly from kitchenly-capture.mov. Portrait, 24 seconds, 30 fps, no audio. Show the app screen alone, with no device frame, no zoom and no hands. Scene 1, 0 to 6 seconds. The week planner fills with dinners. Caption “Plan the week in one view”. Scene 2, 6 to 14 seconds. Tap a recipe, swap an ingredient and watch the shopping list update. Caption “Swap an ingredient and the list follows”. Scene 3, 14 to 21 seconds. Share the list with a partner. Caption “Share the list in one tap”. Scene 4, 21 to 24 seconds. Closing frame with the app name and a one-line note about the subscription behind recipe packs. Use simple dissolves between scenes. Keep every caption inside the central 886 pixels of the frame, in large type, on screen for at least three seconds.
The 24-second runtime leaves six seconds under Apple’s limit for a late trim. The captions stay in the central 886 pixels because the export gets cropped to that width. Scene two starts at 6 seconds, so Apple’s default poster frame at 5 seconds lands on the finished planner. The closing note discloses the subscription without naming a price.
Play the render on a phone before upload. Captions that look fine on a desktop preview can be too small at actual size, and a dissolve can hide a tap the viewer needed to see.
Captions carry the message with sound off
Read each caption aloud once at an unhurried pace. When the reading outlasts the time on screen, shorten the caption. Each Kitchenly caption runs five to seven words and holds for three seconds or more.
A caption works best when it names the result. “Tap the plus button” repeats what a touch hotspot already shows, while “Swap an ingredient and the list follows” tells the viewer what they get. Audio stays optional, and any music or voiceover needs cleared rights. The Kitchenly cut ships without audio, which removes both the licensing check and an encoding risk.
Export at an accepted size and verify it
CoAnimator exports MP4 with three resolution presets measured on the short side, up to 4K, and keeps the project’s aspect ratio. Frame rate accepts any custom value from 1 to 240. The documentation lists no field for exact pixel dimensions, and 886 × 1920 is not a preset. A 9:16 project at the 1080p preset comes out at 1080 × 1920, which Apple accepts for older 5.5-inch and 4-inch iPhones but not for current ones.
The reliable path to 886 × 1920 is therefore a crop. Keep the project at 9:16 with the recording at full height, then trim the sides after export. Current iPhone screens, per Apple’s own device resolutions, land within about three pixels of the 886:1920 shape, so the 97 pixels cut from each side hold empty margin.
ffmpeg -i kitchenly-1080x1920.mp4 -vf "crop=886:1920" -r 30 -c:v libx264 -profile:v high -level 4.0 -pix_fmt yuv420p -b:v 11M -an -movflags +faststart kitchenly-886x1920.mp4Swap -an for -c:a aac -b:a 256k -ar 48000 -ac 2 when the preview carries audio. The re-encode adds one generation of compression, a small cost at 11 Mbps on interface footage. CoAnimator needs FFmpeg and FFprobe for rendering. When the terminal cannot find them, the CLI docs describe pointing FFMPEG_PATH and FFPROBE_PATH at them.

Once the file is cropped, read it back before upload with ffprobe, the inspection tool that ships with FFmpeg.
ffprobe -v error -show_entries stream=codec_name,width,height,r_frame_rate:format=duration,size -of default=nw=1 kitchenly-886x1920.mp4The output should show codec_name=h264, width=886, height=1920, r_frame_rate=30/1, a duration between 15 and 30 seconds and a size well under 500MB. A project aiming at 24 seconds can export at 24.07 or 31, so measure the file itself. For repeat runs, the coa render command in the command line tool offers the same export choices once the coa command is installed from Settings.
Upload the file and set the poster frame
App Store Connect handles previews beside screenshots. Uploading and picking the poster frame take five steps.
- Open the app in App Store Connect and select the version under the platform.
- In the App Preview and Screenshots section, choose the device size and add the file.
- Wait for processing, which Apple says can take up to a day.
- Click View All Sizes in Media Manager, select the device tab, hover over the preview and click Edit Poster Frame.
- Move to the frame, click Set Poster Frame, then click Done.
Poster frames are editable while the app is in Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected or Developer Rejected status. The Account Holder, Admin, App Manager and Marketing roles can make the change. After a version is approved, a new poster frame needs a new submission and a new preview needs a new version. Upload a day before the submission is due. Add localized previews the same way, since a language without its own preview falls back to the next best one. Apple’s upload guide and poster frame page hold the full conditions.
Most pre-submission checks read straight off the file
Reading a value is more reliable than judging by eye, so each check below points to where the answer shows up.
| Check | Where to read it |
|---|---|
| Runtime between 15 and 30 seconds | duration in the ffprobe output |
| Pixel size matches Apple’s table | width and height in the ffprobe output |
| H.264 or ProRes 422 HQ, 30 fps or less, under 500MB | codec_name, r_frame_rate and size in the ffprobe output |
| Audio stereo with all tracks enabled | Stream list from ffprobe -show_streams, then playback on a phone |
| Nothing but app content on screen | A frame-by-frame scrub, including the demo data |
| No dates, seasons or prices | The same scrub, plus every caption |
| Purchase, subscription or login disclosed | The closing frame or the footage itself |
| Poster frame chosen on purpose | Media Manager in App Store Connect |
One recording feeds the other cuts
The store preview uses a slice of what the recording offers. A site hero can place the capture in a device scene with the device mockup tool. A product demo video can add the zooms and narration the store cut leaves out. A launch video reuses the same footage under its own length and format rules.
A cinematic demo from Rege, built with the 3D mockup skill, shows the kind of framed cut a site hero can use.
Loading post from X…
A cut with narration can take captions from the Auto Captions tool, which transcribes locally and exports SRT, VTT or burned-in captions. The store preview skips it, since its captions are written text.
A redesign needs a new recording and a re-render
Because the project is made of editable files, a new capture can replace the old recording and the same scenes re-render. The brief has to describe moments rather than timestamps for this to hold up. “The shopping list updates after the swap” survives a new layout, while “tap the third icon at 0:09” does not. Apple adds its own constraint, since an approved preview changes when a new app version ships.
Limits to plan around
The studio does not capture device screens, and its export settings have no exact-pixel field, so the crop and the ffprobe check cover those gaps. The crop discards anything outside the central band, which suits a layout planned for it. The coding agent composes the video from the brief, and a plausible result can still carry a dated caption or a transition implying a feature. Apple judges compliance, and no export setting guarantees approval.
Local rendering does not settle where a connected coding agent or service processes data. Teams with strict rules about unreleased builds should review the agent’s data path before handing it confidential footage.
FAQs
Can I record the preview in the iOS Simulator?
Apple’s guidance refers to footage captured on the device and does not mention the Simulator. Real hardware is the safe default, and Simulator footage is a fallback for sizes a team cannot test physically.
Can I reuse a social media ad as the preview?
Rarely without changes. Ads tend to carry hands, dated offers, prices or zooms, which Apple’s guidance rules out or discourages, so rebuild the cut from the raw capture.
How long should the preview be?
Apple allows 15 to 30 seconds and names no ideal length. Three or four scenes of five to seven seconds each, with captions held at least three seconds, land near 24 seconds.
Can the same preview run in Apple Ads?
Apple’s guidance notes app previews can be used in Apple Ads. Ad placements can carry their own size and format requirements, so check them before reusing the file.
Do I need new previews for every new iPhone?
Not always. When accepted resolutions are missing for a class, Apple serves a scaled preview from a neighboring class, such as the Face ID large-display preview for Dynamic Island large displays.
A preview belongs in the release routine
Apple adds display classes as hardware ships, and an approved version gets a new preview through a new release. Re-checking the preview with every version keeps it from drifting out of spec.
A short routine fits that cadence. Record a fresh 20-second path, re-render the project, run the ffprobe check and compare the result with Apple’s table on the day of export. Teams that keep the capture and the brief can finish it in an afternoon. To run the routine on a real app, try the workflow on a recording of your own with a brief like Kitchenly’s.
