App previews
and promo videos.
Apple wants 15 to 30 seconds captured inside your app. Google wants a YouTube link and will accept anything. The two formats look similar in a listing and are almost nothing alike in practice. Here are the specs, the capture rules, and an honest answer on whether to bother.
The two formats are not the same thing
Apple calls it an app preview. It plays automatically, muted, at the top of your product page, and it must be captured from the app itself. Google calls it a promo video. It is hosted on YouTube, the user taps to play it, and it can be any footage you like including live action and motion graphics.
That difference drives everything else. Apple is showing people your app running. Google is showing people an advert. Reusing one as the other rarely works.
App preview, Apple
Captured in-app| Property | Requirement |
|---|---|
| Length | 15 to 30 seconds |
| Count | Up to 3 per device size, per locale |
| Resolution | Matches the device screenshot size |
| Format | .mov, .m4v or .mp4 |
| Frame rate | 30 fps recommended |
| Audio | Optional, plays muted by default |
Promo video, Google Play
YouTube hosted| Property | Requirement |
|---|---|
| Length | 30 seconds to 2 minutes recommended |
| Count | One, a YouTube URL |
| Hosting | Public or unlisted YouTube video |
| Ads | Must be disabled on the video |
| Content | Any footage, not restricted to in-app capture |
The first three seconds decide it
Apple's preview autoplays muted while the user is still deciding whether to scroll. There is no title card budget and no room for a logo animation. Open on the app doing the thing it is for. Splash screens and studio idents are the most common way indies waste the only seconds they get.
Because it plays muted, anything conveyed by voiceover is lost to most viewers. If a moment needs explaining, use an on-screen caption sized like a screenshot headline, large enough to read at product-page scale.
Capturing footage that passes review
Apple requires the preview to be captured from the app running on a device or simulator. Screen recordings of a prototype, After Effects mockups of a UI that does not exist, or footage of a different app all draw rejections under the accuracy guideline. You may add captions, transitions, music and a short end card, but the substance must be real.
Use xcrun simctl io booted recordVideo preview.mov for simulator capture at native resolution, or record on hardware and trim. Match the resolution to the device screenshot size for that slot: a 6.9 inch preview is 1290 by 2796, the same as the screenshot.
Is a video worth making
Honestly, often not, and the case is weaker than the effort suggests. A preview competes for the same attention as your first screenshot and can push screenshots down the page. Apple's own Product Page Optimization exists partly because the answer varies so much by category.
It is usually worth it when the app is motion-dependent, a game, a drawing tool, anything where the appeal is in how it moves. It is usually not worth it for utilities and reference apps, where a static screenshot communicates the same thing faster.
If you are unsure, ship without one, then test adding it. That is exactly the kind of large, plausible change that store listing experiments can actually measure.
Mistakes that cost a review cycle
- Device frames inside an Apple preview. The footage must be the screen content, not a composited mockup of a phone.
- Ads left enabled on the YouTube video for Play. It is an automatic rejection and easy to miss.
- Showing another platform. An Android device in an App Store preview breaks the same rule that catches screenshots.
- Music you do not have rights to. Both stores act on rights complaints, and YouTube will flag it before Google does.
- A preview that outlives the UI. Redesign the app and the video is instantly a lie. Budget for re-recording.