2026-08-31
App Store and Google Play app video rules in 2026 (and how to cut a 15–30 second preview from your screen capture without re-encoding it)
Every audience this series has met so far was trying to fit a video through someone else's slot — a 25MB attachment, a 20MB Discord message, a 15-second Etsy listing. This one is for the person who just finished building an app and now has to make the store listing: both major app stores want a video of your app in action, and they want it in ways so different they barely share a noun. Apple wants an actual video file, inside a hard 15-to-30-second window, in a specific codec, at specific pixel sizes. Google Play won't take your file at all — it wants a YouTube URL. What both roads start from is the same raw material: a long, rambling screen capture of you poking through your own app, with maybe twenty-five good seconds somewhere in the middle. Here are the two stores' actual rules, from their own documentation — and how to cut those seconds out on your own machine without re-encoding the one kind of footage that re-encoding visibly hurts.
Apple's rules: a real file, a hard window
Apple's requirements live on the app preview specifications page in App Store Connect Help, and they are unusually exact. An app preview must run between 15 and 30 seconds — that's a floor and a ceiling, not a suggestion. You can have up to three previews; the file must be .mov, .m4v, or .mp4; video encoded as H.264 or ProRes 422 (HQ only); frame rate at most 30 fps; file size at most 500MB; and the resolution must come from Apple's own table — 886×1920 portrait for the current crop of 6.9", 6.5", and 6.1" iPhones, 1080×1920 for the old 5.5" class, 750×1334 for 4.7". The spec even defines where the default poster frame sits: 5 seconds in. Apple's companion guidance page adds the content rules: previews "must show only content within the app itself" — no hands, no over-the-shoulder shots of a device — and Apple's recommended capture route is refreshingly low-tech: "Capture app footage from the device using QuickTime Player on macOS simply by connecting your device to a Mac," at the native UI resolution rather than zoomed.
Google Play's rules: no file at all
Google Play's version of the same feature, per Google's own preview-assets page, is not an upload. The promo video field takes a YouTube URL — a single video's URL, "not a YouTube playlist or channel URL." The video's privacy must be public or unlisted (not private), it must be embeddable, it can't be age-restricted, and you're told to disable ads on it so Google Play doesn't show someone else's pre-roll in front of your app. There's no stated length ceiling — but there is a soft one hiding in the same document: "only the first 30 seconds autoplays." And the video won't display on your listing at all unless you've also provided a feature graphic (a 1024×500 JPEG or 24-bit PNG). So the two stores' paperwork could hardly differ more — a strict file spec versus a YouTube link — and yet both converge on the same editorial fact: you get about 30 seconds of attention, and Apple will reject, while Play will simply stop autoplaying, anything longer.
Why this particular cut should be a stream copy
A screen capture of an app is the footage re-encoding hurts most visibly. It's full of the things lossy video encoders are worst at preserving: thin 1-pixel strokes, small crisp text, hard edges between flat colors. Run a capture through a re-encode and the label text in your own settings screen comes out faintly smeared — in a video whose entire job is to make the app look sharp. NearVid's trim never touches an encoder: it's a stream copy, the video and audio data between your chosen start and end copied through byte-for-byte, so the 25 seconds you keep are pixel-identical to the capture QuickTime handed you, and the operation finishes in seconds because the work is closer to a file copy than to video processing. It also runs entirely in your browser tab — nothing uploads, which matters less for privacy here than everywhere else in this series and more for iteration speed: you will not cut this video once. You'll cut it, watch it, wince, and cut it again. One convenient accident of arithmetic: NearVid's per-file limit on desktop is 500MB — exactly Apple's own ceiling for the finished preview file, so any capture that could ever become a legal app preview fits. (On phones and low-memory devices NearVid's cap drops to 50MB; listing prep is a desktop job anyway, since that's where QuickTime and your emulator live.)
The keyframe detail that actually bites here
One honest mechanic matters more in this post than anywhere else in the series. NearVid's trim takes typed start and end times, and because a lossless cut can only begin on a keyframe, the exported clip may start a moment earlier than the second you typed — the same tradeoff described in the still-frame post. Everywhere else in this series that's a cosmetic wrinkle. Here it can be a rejection: Apple's 30-second ceiling applies to the file's real duration, so if you type a 29.5-second window and the nearest keyframe sits two seconds before your start, you're holding a 31.5-second file. The practical rule: aim for the middle of Apple's window — cut something like 25 seconds — then check the exported clip's actual duration in your player before it goes anywhere near App Store Connect. If it came out long, move the typed start a little later and cut again; a stream copy is cheap enough that re-cutting is a ten-second loop, not a render queue.
The WebM wrinkle, from the Android side
If your app is Android-first there's a good chance your raw capture isn't an MP4 at all: per Google's own Android Studio documentation, the Android Emulator's screen recorder saves to WebM (or animated GIF). For the Play listing that's no obstacle — the video's going to YouTube, which takes WebM happily, and NearVid's trim stream-copies WebM the same as anything else. But the moment the same app has an iOS build, that capture hits Apple's format list — .mov, .m4v, .mp4, H.264 or ProRes — and a WebM is none of those. NearVid's "Convert to MP4" card covers exactly this gap: it re-encodes to H.264 MP4 in the browser using WebCodecs, the same no-upload pipeline described in the WebM-won't-play post. Trim first, convert the short clip second — and mind the honesty section below, because this is the one step here that is a re-encode, and the card only appears at all in browsers whose WebCodecs H.264 support checks out.
Screenshots from the same capture
Google Play's page also sets the screenshot rules: at least two, JPEG or 24-bit PNG, every dimension between 320px and 3840px. If the perfect screenshot moment is already in your capture — the animation mid-flight, the empty state you can't easily reproduce — NearVid's frame extraction pulls that exact frame (not the nearest keyframe) as a JPG at the capture's own resolution, which for any modern device capture lands comfortably inside Play's bounds. For Apple's screenshot slots, which want specific per-device sizes just like previews do, the same caveat applies as everywhere in this post: NearVid extracts at source resolution and doesn't resize, so capture at the size you need.
What NearVid doesn't do here
The usual honesty section, and this post needs it more than most. NearVid does not resize video — Apple's resolution table (886×1920 and friends) has to be satisfied by the capture itself, which is why Apple's advice to record the device natively via QuickTime is the advice to follow. It does not change frame rate — Apple caps previews at 30 fps, and if you recorded at 60, NearVid's trim keeps 60; record at 30, or that's an editor's job. It won't merge takes, add the text overlays, touch hotspots, or dissolve transitions Apple explicitly permits — Apple's own page points at iMovie and Final Cut Pro for that layer, and NearVid is a trimmer and converter, not an editor. It doesn't upload anywhere: not to YouTube for the Play listing, not to App Store Connect — it hands you a clean local file and the rest of the paperwork is yours. And the MP4 convert card is WebCodecs-gated, so on a browser without solid H.264 encode support the trim will work but the WebM-to-MP4 step won't appear.
The honest summary
Per each store's own documentation — an Apple app preview is a real file: 15 to 30 seconds, hard-bounded, .mov/.m4v/.mp4, H.264 or ProRes 422 (HQ), at most 30 fps and 500MB, at exact per-device resolutions, up to three per language, showing only in-app content. Google Play takes no file: a public-or-unlisted, embeddable, ad-free YouTube URL, displayed only once a 1024×500 feature graphic exists, autoplaying only its first 30 seconds. Both start from the same over-long screen capture, and the first move is the same one this series always reaches: a lossless, on-device trim that keeps the good 25 seconds pixel-identical — aimed at the middle of Apple's window, because a keyframe-snapped start can lengthen the clip, and duration is the one spec Apple hard-rejects on. Re-encode only where a store's format list forces it — which, concretely, is the Android-emulator WebM meeting Apple's MP4-shaped door.