App Preview Video Captured From the Product Itself

What Apple will and will not accept: An App Store preview must be captured from the app running on a device. Motion graphics, actors, stock footage and animated logo sequences are the standard reason a preview is rejected, and the guidance on this has not softened. You get up to three previews per localisation, fifteen to thirty seconds each, and the first autoplays muted in search results. Google Play takes a YouTube-hosted trailer that does not autoplay in search and does play with sound when tapped. These are two different films. I do not deliver one file for both and I will argue against anyone who offers to. The first three seconds carry the whole thing: Muted autoplay in a search result means no voiceover, no title card, no logo. The opening frame has to be the app doing the single thing the user came for. In practice the script is written backwards from that one action and everything else is cut. For a medtech app it is usually a reading being taken or a result being read. For a utility app it is a bill or a consumption curve. It is never onboarding, and the number of previews that open on a login screen suggests this is not obvious. Capture, which is where the work actually sits: Device capture at the correct resolution and frame rate for every required display size, with the app in a demo state real enough to be honest and controlled enough to be repeatable. Building that state, seeded accounts, plausible data, deterministic timings, takes longer than the edit and is the part production shops skip. It is why their previews look like a screen recording of a bug. Patient and customer data: I do not film real patient records, real meter readings tied to a real address, or any screen carrying a live identifier, and I will not accept a client-supplied capture that does. The demo dataset is constructed for the shoot and signed off by your data protection lead before capture begins. This has cost me a project and I would make the same call again. Captions and claim risk: Every on-screen word in a preview is labelling for a regulated device. Captions are drafted against your claim boundary and approved before the edit is locked, not after, because removing a phrase later means recapturing the footage underneath it. That sequencing is the difference between one shoot and two. Poster frame and localisation: The poster frame is what a user sees before the video loads and in every context where it does not autoplay, so it is chosen deliberately rather than inherited from frame one. Localised previews are recaptured against the localised build rather than subtitled over English UI, in any market where the interface language differs. Subtitling over the wrong UI reads as a foreign product, which in these categories is the trust problem you were trying to solve. Not included: Brand film, launch advertising, paid social cutdowns, screenshot design, and store copy. Also excluded: any preview for an app whose interface is not stable enough to capture. If a redesign lands in six weeks the film is waste and I will say so before invoicing. Who should not buy this: Anyone expecting a sizzle reel. Anyone who wants the video to carry the value proposition through narration, because on the surface that matters the sound is off. And anyone commissioning a preview before the store page problem has been diagnosed. A preview is rarely the constraint, and I would rather tell you that than take the production fee.