How to Create a Demo Video for an App in Under an Hour

Every guide to how to create a demo video for an app lists the same six stages. Pick an outcome, script it, clean up the app, record, cut for pacing, export. The stages are right. What none of them tells you is what a stage costs, which is the only thing you actually wanted to know before you started, because the real question is whether this fits in today.

So here is the same job with a clock on it. Fifty-five minutes, budgeted per step, with five minutes of slack and a triage rule for what to drop when you go over. You will go over on one step. Knowing in advance which one to sacrifice is what keeps an hour from becoming an afternoon. At 0:55 you have one exported file of one flow, captioned, correctly sized for one destination. Not a launch film. A usable demo.

What you'll need

Three things, and no budget.

• A screen recorder. On a Mac, xcrun simctl io booted recordVideo captures the iOS Simulator with no extra software. On a physical iPhone, the built-in Screen Recording control does it. QuickTime records a tethered device.
• Any editor that can cut and add text. iMovie, CapCut, DaVinci Resolve, Descript. The cheapest one you already know beats the best one you have to learn today.
• A decision about where the video goes. This is the actual prerequisite. The destination sets the length, the shape and the effort, and choosing it at 0:50 instead of 0:00 is what turns an hour into three.

The short version

1. 0:00–0:05 — Pick the one thing. One sentence a viewer should believe at the end.
2. 0:05–0:12 — Write the tap list. Every tap and screen, in order, on one page.
3. 0:12–0:20 — Set the app's state. Real-looking data, no debug UI, notifications off.
4. 0:20–0:35 — Capture in scenes. One take per beat, not one take for the whole flow.
5. 0:35–0:50 — Cut and caption. Remove travel time, add text cards, no voiceover.
6. 0:50–0:55 — Export for the destination. One file, correct dimensions, correct length.

0:00–0:05 — Decide the one thing the video proves

Write one sentence: *by the end of this video, the viewer believes ____.* Five minutes, on paper, before anything else.

The sentence has to be about the viewer, not the app. "The viewer believes they can split a receipt with four people in under ten seconds" is a brief. "The viewer understands our expense-splitting feature" is not, because it does not tell you what to show or when to stop.

This step is five minutes because the failure it prevents is enormous. A demo without a single claim becomes a tour, a tour has no natural ending, and an unbounded video is the reason a one-hour job turns into a weekend.

Pick the destination in the same five minutes, because it caps everything downstream:

• App Store preview: 15 to 30 seconds, enforced at both ends by App Store Connect.
• Landing page: 20 to 40 seconds, looping, muted.
• Social post: 15 to 20 seconds, muted, captions burned in.
• Sending to one person: 60 to 90 seconds, and talk over it. This is the only case where a voiceover is worth the time.

0:05–0:12 — Write the tap list

Not a script. A tap list: every screen and every interaction in order, with the seconds you are giving each. Seven minutes.

0.0  Home, list already populated       hold 1.5s
1.5  Tap "New split"                    sheet rises
3.0  Type "Dinner"                      2 chars/frame, fast
4.5  Tap 4 avatars                      one per 0.3s
6.0  Tap "Split"                        result animates in
8.0  Hold on the result                 2.0s, this is the payoff

Two things make this worth seven minutes rather than zero. It forces you to notice that your flow is eleven taps when the video has room for six. And it becomes the edit — when you get to 0:35 you are matching a plan, not deciding what matters while a timeline is open, which is where hours disappear.

The rule for the list: one flow, completed. Not three features sampled. A viewer who watches one task finish understands the app. A viewer who watches three tasks start understands nothing.

0:12–0:20 — Set the app's state

Eight minutes, and this is the step everyone underestimates. It is also the step that separates a demo that looks like a product from one that looks like a debug build.

• Fill the app with believable data. Not "Test User 1" and "asdf". Real names, plausible amounts, a list with enough rows that scrolling means something. An empty state in a demo reads as an unfinished app.
• Remove the development furniture. Debug banners, TestFlight badges, placeholder images, lorem ipsum, the red "DEV" label in the nav bar.
• Silence the device. Do Not Disturb on. A notification banner landing mid-take costs you the take.
• Fix the status bar. On the Simulator, xcrun simctl status_bar booted override --time 9:41 --batteryLevel 100 --cellularBars 4 gives you a clean bar. On a device you get whatever the device has.
• Set the appearance you want. Decide light or dark before you record, not in the edit.

If you are over budget already, this is not the step to rush. Bad data is the one defect that no amount of editing fixes, because it is in every frame.

0:20–0:35 — Capture, in scenes

Fifteen minutes, and the single most useful tactic on this whole topic: record in scenes, not in one take.

One take of an eight-tap flow means one fumble costs you the whole run, and you will fumble, because performing your own app while thinking about the camera is harder than it sounds. Recording each beat separately means a mistake costs six seconds.

For the Simulator:

xcrun simctl io booted recordVideo --codec h264 beat-01.mp4
# perform one beat, then Ctrl-C
xcrun simctl io booted recordVideo --codec h264 beat-02.mp4

Three practical notes. Record H.264 rather than HEVC — HEVC drops frames on visually dense motion, and dropped frames on a scroll are visible. Start each recording a second before you touch anything and stop a second after the animation settles, so you have handles to trim into. And do each beat twice; the second take is almost always cleaner and it costs you six seconds.

If a beat needs a scroll, do it once, slowly and evenly. A scroll that stops and restarts reads as hesitation, and hesitation is the thing you cannot fix in the cut.

0:35–0:50 — Cut and caption

Fifteen minutes. Assemble in tap-list order, then do these three passes and nothing else.

1. Remove the travel. The dead frames between a tap landing and the next tap starting. This is 90% of the value of editing, and it is why a 40-second capture becomes an 18-second video.
2. Add caption cards, not subtitles. Three to five words per beat, held long enough to read, placed above the bottom fifth of the frame where platform interface elements sit. Every destination on this list autoplays muted, so the text is the narration.
3. Trim the head and tail. Start on the app already doing something. End on the result, not on a return to the home screen.

Skip the voiceover. Skip the music. Skip the intro card with your logo. Each costs more than it returns at this budget, and the first two are unusable on a muted surface anyway.

The edit is not where a demo gets good. It is where a demo gets short. Everything that makes it good happened at 0:00 and 0:12.

0:50–0:55 — Export for the destination

Five minutes, one file, using the decision you made in step one.

Export at the source resolution and let the destination downscale — scaling up to hit a required size is where soft text comes from. If the destination is the App Store, the file has to land inside 15 to 30 seconds at a device-specific resolution, and the full preview spec is worth checking before you export rather than after the upload fails.

Save the project file. You will need it in six weeks when the UI changes, and re-opening a timeline is cheaper than re-doing an hour.

When you run over: what to cut, in order

You will go over. Here is the order to sacrifice things, worst option last.

1. Cut the number of beats. Six taps become four. This is the cheapest fix and it usually improves the video, because the version that fits is the version without the beat you were unsure about.
2. Cut the second take. Ship the first take of each beat and accept one small fumble.
3. Cut the caption cards to two. One at the start naming the task, one at the end naming the result.
4. Cut the state-setting to data only. Believable data, and live with the debug banner cropped out of frame.
5. Cut the flow to a single screen. A ten-second video of one screen doing one thing beats a 40-second video of a flow you rushed.
6. Do not cut the tap list. Skipping the plan is the only option here that makes the job take longer instead of shorter.

Where this goes wrong

The app was not ready to film. You start recording and discover that reaching the interesting screen requires four setup taps, a login and a network call. That is not a video problem, it is a fixtures problem, and it is the most common reason this hour becomes three.

The flow only exists on a real device. Camera, biometrics, push notifications and payments do not work in the Simulator. If your demo needs one of them, budget an extra fifteen minutes and record on hardware.

The screen is too dense to read at thumbnail size. A dashboard that works at arm's length is unreadable in a feed. Either zoom the capture toward the region that matters or pick a simpler screen.

You recorded at the wrong orientation. Portrait capture rotated to landscape in the edit is a pillarboxed video with a small phone in it. Decide the shape before you record.

The UI changed the following week. Nothing in this hour survives a redesign. That is the real cost of manual demo videos, and it is why the second one never gets made. The input-ladder version of this guide covers the ways around it.

Taking the hour to zero

An hour is a good number for one video. It is a bad number for a video per release.

If you ship weekly, the arithmetic stops working: fifty-two hours a year on demo videos, every one of them invalidated by the next UI change. The way out is to stop treating the video as a file and start treating it as a spec you re-run.

That is what Reely does for iOS features. You describe the flow, it drives the feature in the Simulator, records it, and composites the cuts, camera moves and captions — and because it authored the run, it knows when each tap happened, so the cuts land on real interaction moments rather than eyeballed seconds. Re-running it after a UI change costs one command.

The honest bounds: Apple platforms only, and the fully generated path works from a SwiftUI mock of your feature rather than your shipping binary. If you already have a recording, it can wrap the motion design around that instead. If you want an unhurried, tool-agnostic version of this process, the seven-step product demo guide covers the same ground without a clock.

Frequently asked questions

How long does it take to make a demo video?

About an hour for one flow, one destination, if you plan first — roughly five minutes deciding, seven writing the tap list, eight preparing the app, fifteen capturing, fifteen editing and five exporting. A launch film with a voiceover, music and multiple flows is a different job that takes a day or more. The hour buys you one usable video, not a finished campaign.

Do I need a voiceover for an app demo video?

Not for anything that autoplays. App Store previews, landing page loops and social posts all play muted by default, so a voiceover reaches a minority of viewers and text cards reach everyone. The one case where narration earns its cost is a video you send to a specific person, where your voice is doing work no caption could.

What software do I need to create a demo video for an app?

Less than the tool pages suggest. A screen recorder you already have — simctl for the Simulator, iOS Screen Recording on device, QuickTime for a tethered iPhone — plus any editor that cuts clips and overlays text. iMovie is sufficient for the process above. Paid tools buy speed and polish, not capability.

Can I make a demo video before the app is finished?

Yes, and it is common. You need the screens to exist and to animate, not the backend behind them. Building the flow against local fixtures gives you something filmable well before the feature ships, and it lets you show empty states, error paths and premium tiers that would be awkward to reach in a real account.

Next

Set a timer and do the first twelve minutes right now: the one sentence, the destination, and the tap list. Those twelve minutes decide whether the remaining forty-three are enough, and they are the only part of this that cannot be recovered later.

If your app is iOS and the part you keep postponing is the capture session, Reely generates the footage from a description of the flow — free to create with, paid only when you export.