How to Make an App Promo Video That Converts

The build is finished and the launch post goes out Thursday. Somewhere between the store metadata and the changelog sits make the video, and it has survived two weeks of triage because it is the only item you have no idea how to start.

So you search for an app promo video and get fifteen template libraries, a stock marketplace and a freelancer category. Every one of them opens the same way: pick a template, drop your screens in. They all begin one step after the hard part. None of them tell you which of three videos you are actually making, or how to get twenty clean seconds of your own app in the first place.

The short version

1. Decide where the video will play. That decision sets the rules.
2. Write to one promise, not to a feature list.
3. Capture a clean run of the app, longer than you need.
4. Cut on the interactions and caption everything, because it plays muted.
5. Render each destination's canvas from that same take.
6. Ship the App Store version separately — it obeys different rules.

A promo video is not a demo, and it is not an App Store preview

The three terms get used interchangeably on almost every page that ranks for this topic, and the confusion is expensive, because two of the three are regulated.

A promo video is short, emotive and one-idea. It exists to make someone want the thing. Twenty to forty seconds, muted autoplay, no narration required, one promise landed hard. Launch posts, paid social, the hero slot on a landing page.

A demo video teaches. It walks a viewer through a workflow, usually longer, usually feature by feature, and it assumes the viewer has already decided to pay attention. Onboarding, docs, sales calls.

An App Store preview is neither: it is a store asset with rules attached. Apple's App Previews page states that previews "demonstrate the features, functionality, and user interface of your app using footage captured on device," and that they "must show only content within the app itself" — no filming fingers on a screen, no over-the-shoulder shots (checked August 2026). Each one runs up to 30 seconds, and you get up to three per language.

The mockup promo you build from a template — a floating phone on a gradient, a hand entering frame, kinetic type over a still — is a fine launch-post video and is not a legal App Store preview.

Google Play works the opposite way. The promo video there is a linked YouTube URL rather than an uploaded file, it can run up to two minutes, and promotional framing and calls to action are allowed. So one asset does not cover all three surfaces, and the constraint runs in one direction: the store version is the hardest to satisfy, so shoot for it and cut down.

Step 1: Pick the surface before you write anything

Write the destination at the top of the page before the script. Each one hands you a different brief.

The App Store. Up to 30 seconds, autoplays muted in the search results, and must be device footage of the app running. This is the most constrained and usually the most valuable, because it plays to people who are already one tap from installing.

Google Play. A YouTube link, up to two minutes, promotional content permitted. It does not autoplay — a viewer has to press play — so the thumbnail does part of the work the first second does on iOS.

Everything else. Landing page hero, launch post, X, LinkedIn, Reels, Product Hunt. No rules and the least patient audience. Assume vertical, assume muted, assume the viewer leaves at four seconds unless something has already happened.

If you only make one, make the App Store version. It is the only one with an approval process, and everything else can be cut from it.

Step 2: Write to one promise, not to a feature list

The reason most app promo videos fail is not production quality. It is that they try to cover four features in thirty seconds and land none of them. Pick the single thing your app does that a competitor's screenshot cannot claim, and spend the whole video on it.

A twenty-second budget, in beats:

0.0–2.5s   The promise. One line of text, one image. What changes for the viewer.
2.5–14.0s  The thing working. Real app, real motion, two or three interactions.
14.0–17.5s The payoff. The result state — the saved file, the finished list, the export.
17.5–20.0s The ask. App name, icon, "Download on the App Store".

One rule does most of the work: the app has to appear inside the first three seconds. A logo animation spends your only guaranteed viewing time on something the viewer did not search for.

A second feature is a second video. Two twenty-second videos cost less to make, and less to watch, than one forty-second video nobody finishes.

Step 3: Get a clean take of your app

This is the step every template library skips, and it is the one that eats your Wednesday. You need continuous footage of your own app behaving perfectly: right data, right device, right orientation, no fumbled tap, no notification banner, no half-loaded image.

A checklist that survives contact with a real launch:

1. Seed the data first. Empty states and Lorem ipsum read as unfinished. Populate the account the way you wish a real one looked.
2. Kill the interruptions. Do Not Disturb on, notifications off, battery and clock in a state you are willing to publish.
3. One device, one orientation. Mixing a 6.7-inch capture with a 6.1-inch one means re-shooting the whole thing later.
4. Tap slowly and deliberately. Faster than you think is right always reads as frantic once it is cut.
5. Record two minutes for twenty seconds of usable footage. Retakes are cheap while the environment is still set up and expensive tomorrow.

Recording the Simulator or the device

For an iOS app the Simulator is usually the better source: no hands in frame, no reflections, exact device dimensions, and a one-line capture.

xcrun simctl io booted recordVideo --codec h264 promo-raw.mov

A physical device gives you real performance and real camera or sensor behaviour, which matters if the feature you are promoting depends on either. Everything else is easier in the Simulator.

The honest cost of this step is that the take is perishable. Change the onboarding copy, reorder a tab bar, ship a new empty state, and you are setting the environment up again.

A hand-performed recording has a shelf life measured in releases, and the bill arrives on the day you least want to re-shoot: right before the next launch.

If the app is not ready to film

Screenshot animators exist for exactly this. Tools like Previewed and the other screenshot-driven preview makers take stills and build motion around them — 3D device rotation, kinetic type, transitions. The output can look expensive, and it cannot show your app moving, because there is no motion inside a still image to extract. Fine for a store slideshow; thin for "here is the thing working."

Step 4: Cut it for a muted autoplay

Assume no sound. Assume the viewer is scrolling. Four edits carry almost all of the difference between a video that reads and one that does not.

Cut on the interaction, not near it. The frame where the sheet starts to present is the cut point. A cut 200 milliseconds late reads as lag, and viewers blame the app rather than the editor.

Zoom toward what was tapped. A phone-sized screen inside a 9:16 frame is small. Pushing in on the control being used tells the viewer where to look without a callout arrow.

Delete the dead air. The gaps between taps — the reaching, the reconsidering — are half of a raw recording. Hard-cut them out and the same twenty seconds carries twice as much.

Caption every beat. Sound is off, so the captions are the script. One line, seven words or fewer, on screen for at least 1.2 seconds, positioned clear of the device bezel and clear of the platform's own UI overlays at the bottom of a vertical frame.

Step 5: Render every canvas from the same take

You need the same twenty seconds in three shapes: device-native portrait for the App Store, 9:16 for Reels, TikTok and Shorts, and 16:9 for the landing page and YouTube. The mistake is producing one and letterboxing it into the others, which wastes a third of the frame on black bars in the exact places attention is highest.

The way out is to treat the recording and the presentation as separate things. The capture is a file. The framing, camera moves, captions and canvas are a description of what to do with that file — and if that description is written down rather than performed in a timeline, re-rendering at a new aspect ratio is a parameter change, not a second edit session. Reely stores that description as JSON and re-renders each canvas from it; the format and composition options are documented.

Practical version, whatever tool you use: keep the master recording, keep the edit as a project file, and export the three canvases in one sitting. Do not throw the source away after the first export.

Where this goes wrong

The ninety-second feature tour. It is a demo wearing a promo's title. If your video has a "and it also does" in it, split it.

The template promo submitted as a preview. Rejected under the device-footage rule, usually a week before launch.

The caption that lands after the tap. Timed by eye against a scrubber, it drifts by a few frames per cut, and by the end of the video the text is describing the previous screen.

The video that only exists as an MP4. Six weeks later the UI has changed, the project file is gone, and the cheapest option is to shoot it again from scratch.

One canvas, letterboxed everywhere. A 16:9 export pillarboxed into a vertical feed shows a stamp-sized app in a black field.

Doing it without the manual work

Most tools in this category are motion-design layers: you bring footage or screenshots, they add the polish. A smaller group produces the footage itself by driving the app rather than asking you to perform it.

Reely takes the second route on Apple platforms. You can bring screenshots, bring a screen recording you already made, or bring nothing — in which case an agent rebuilds the feature as a working SwiftUI mock, drives it in the iOS Simulator by mutating the real navigation and state objects, and films the result. The app's own animations play, so what lands in the file is a real NavigationStack push, not an imitation of one.

The mechanical consequence matters more than the convenience. Because the run was authored rather than performed, reely run writes a timeline.json sidecar of labeled interaction marks beside the recording, and the composition references those labels instead of timestamps. A caption is pinned to the tap event, so re-recording after a UI change moves the caption with the tap rather than leaving it 200 milliseconds late.

Where it is the wrong tool: it covers Apple platforms only — no Android, no web app. And on footage you uploaded yourself there is no sidecar, so you are timing by eye like everyone else. The sidecar only exists when the tool made the recording.

Frequently asked questions

How long should an app promo video be?

Between 20 and 30 seconds for most uses. Apple caps App Store previews at 30 seconds, so building to that length gives you one asset that fits every surface. Google Play permits up to two minutes, but longer rarely helps: watch-through drops sharply after the first fifteen seconds, and a promo that needs ninety seconds is usually a demo in disguise.

Can I use my app promo video as my App Store preview?

Only if it is made of footage captured on the device. Apple's App Previews guidance requires previews to show the app's own interface, recorded on device, with no shots of people handling a phone (checked August 2026). A template promo built from mockups, stock footage or animated screenshots does not qualify. Build the store cut first, then reuse it elsewhere.

How much does an app promo video cost?

The spread is enormous. Production agencies quote roughly $600 to $5,000 for a sixty-second app promo, per pricing pages such as advids.co, while gigs on Fiverr and Kwork start near $10 (checked August 2026). What you are buying at the top of that range is scripting and motion design, not footage of your app — most vendors still ask you to supply the recording.

Which format should I export in?

H.264 in an MP4 container covers every destination. Export three canvases from one master: device-native portrait for the App Store, 1080×1920 for Reels, TikTok and Shorts, and 1920×1080 for your landing page and YouTube. Match the source frame rate, usually 30 or 60fps, and keep the master file so you can re-render rather than re-shoot.

Do I need a voiceover or background music?

No voiceover. Almost every view of a promo happens with sound off, so anything carried only by narration is lost. Add a music bed for the surfaces that do play audio, and make sure the video works without it. Captions do the narration's job, and they keep working in a muted autoplay, which is where most of your views happen.

What to do this week

Pick the surface first, because it sets every other decision. Get one clean take of the feature you are proudest of, longer than you need. Then cut it for a muted viewer and render each canvas from that same file.

If the take itself is the part you keep postponing, use a tool that produces it for you instead of asking you to perform it — download Reely for Mac and describe the flow rather than recording it.