How to Make an App Demo Video (Without Recording One)

You shipped the feature on Tuesday. It works, it looks right, and now it owes you an app demo video for the App Store listing, the launch post and the top of your landing page. That is the part nobody put on the sprint board. Get the app into the right state, perform the flow without fumbling, fumble anyway, start over, then open an editor you touch four times a year.

This guide is five steps. The second one is a fork rather than an instruction, because "where does the footage come from" has three real answers and the guides on page one only ever give you the middle one. What you end up with is a 20 to 40 second file, framed in a device, cut on the moments where something actually happened, and exported once per place you plan to post it.

What you'll need

A Mac, plus the iOS Simulator or a device on a cable. The Simulator is easier to stage and easier to script. A device gives you real scroll physics and real thermals.

One flow you can describe in a single sentence. "Create a project and rename it." If it takes two sentences, it is two videos.

Twenty to forty seconds of screen time. That is the whole budget. Plan against it before you shoot rather than after.

Somewhere for the video to go. The App Store listing, a launch post, a changelog entry, a landing page hero. The destination sets the aspect ratio and the length, so decide it now.

You do not need a video editor licence, a designer, a microphone, or a budget. Every step below is doable with the tooling already on a developer's Mac.

The short version

1. Pick one flow and write down every tap in order, before you touch a recorder.
2. Decide where the footage comes from: screenshots you already have, a screen recording you make, or a run produced from the flow itself.
3. Stage the app — seeded data, a clean status bar, notifications off, keyboard behaviour settled.
4. Capture or produce twenty to forty seconds covering the tap list and nothing else.
5. Frame the screen in a device, then cut and zoom so every move lands on an interaction instead of on a timecode, caption each beat, and export one file per surface.

Step 1: Pick one flow and write down every tap

The failure mode this prevents is the feature dump: a video that shows eleven things and leaves the viewer able to describe none of them. Pick one problem, one action, one result. Everything else is a second video.

Then write the tap list. Literally, in a text file, before you open anything that records:

1. App opens on the project list.
2. Tap New project.
3. Type "Harbour" into the name field.
4. Tap Save.
5. The new project appears at the top of the list.
6. Tap it, and the detail screen pushes in.

Five to nine lines is the right size. Under five and there is not enough motion to carry twenty seconds; over nine and the video is running so fast that no beat reads.

The rule that makes this worth writing down: anything not on the list does not go in the video. No settings screen you happen to pass through, no toast you forgot to suppress, no back-navigation to fix a wrong turn. The list is the shot list, and the edit is the list.

Step 2: Decide where the footage comes from

This is the fork. Every step-by-step guide on the first page of results answers it the same way — record your screen — and then moves on. There are three routes, and they differ in what the finished video can show and in how precisely it can be cut.

Screenshots you already have. The lowest-friction start, and the reason it is popular: you have them already, because the App Store made you make them. A tool animates around the stills — pans, 3D device moves, kinetic captions. The output can look genuinely good. It also never shows your app moving, which viewers read as a slideshow even when they cannot say why. Use this when the app is not runnable on your machine today.

A screen recording you make yourself. The middle route, and the one every incumbent guide assumes. Works with any stack: SwiftUI, React Native, Expo, Flutter, a web view in a shell. You get your real app, in motion, at real timing. The cost is the one you already know — you have to nail a clean take, and you have to nail it again in six weeks when the UI changes.

A run produced from the flow itself. Instead of capturing footage, you generate it: the flow you wrote in Step 1 is rebuilt as a working mock, driven programmatically, and filmed. This route is the one nobody on page one describes, and it is worth understanding even if you never use it, because it changes what the editing software knows about your video. It is also the route with the sharpest constraint, covered further down.

If the category itself is new to you, the tool landscape sorts by exactly this question — what an AI app demo video generator actually films is the shortest way to place any given product on the list.

Step 3: Set the stage before anything rolls

Staging is where most of the actual work lives, and every guide reduces it to "prepare clean demo data" as though that were a checkbox.

Seed the data by hand. Real names, plausible dates, no Test 1 / Test 2 / asdf. An empty list reads as an unfinished app; a list of lorem ipsum reads as a mockup.

Fix the status bar. The Simulator will happily record 4:17 PM, 43% battery and one bar of signal. Apple's own marketing convention is 9:41, full battery, full signal, and the Simulator has a command for it:

xcrun simctl status_bar booted override \
  --time "9:41" --batteryState charged --batteryLevel 100 \
  --wifiBars 3 --cellularBars 4 --operatorName ""

Kill the interruptions. Notification banners, the keyboard's predictive bar, autocorrect underlines, a debug overlay you forgot was on. Any of them will land in the middle of your best beat.

Decide the locale. If the launch post is going out in English, record in English. Switching afterwards means recording again.

Here is the honest limit: some states cannot be staged at all. A paid tier you have not built the receipt flow for, a network error you cannot reliably trigger, an empty state that only exists for a brand-new account, a screen that appears after a backend call that takes eight seconds on a good day. Those are the states most worth showing and the hardest to capture, and they are the reason the third route in Step 2 exists.

Step 4: Get the footage

For a Simulator capture, one command does it:

xcrun simctl io booted recordVideo --codec h264 demo.mov

Run the flow, then stop with Control-C. Two things about that file. It carries no audio track at all, so if you want any, you are adding it later. And the Simulator writes variable-frame-rate video, which some editors handle badly — transcoding to a constant frame rate before you edit saves an afternoon of hunting a stutter that is not in your app.

Perform the flow slower than feels natural. Leave a full second of stillness before the first tap and after the last one; you will cut into that padding later, and having it is the difference between a clean top and a video that starts mid-gesture. Do three takes. Keep the one where you did not hesitate.

On the produced-footage route the mechanics are different in a way that matters downstream. Because a program drove the flow rather than a hand, it can write down when each step happened — a sidecar file of labeled events beside the recording, one entry per tap, with the moment the action fired and the moment its animation settled. That file is the input to Step 5.

Step 5: Cut, caption and export

Cut against the interaction, not the clock

Here is the thing no guide on page one says out loud. A cut, a zoom or a caption is supposed to land on the moment something happened in the app. When you edit a recording, you find that moment by scrubbing until it looks right, and "looks right" in a timeline is reliably a few frames late. That lag is most of what separates a demo that feels produced from one that feels edited.

A demo feels amateur not because the zoom is ugly, but because it arrives after the tap instead of with it.

Two ways to solve it. If you are editing a recording by hand, step through frame by frame at the moment of each tap and set your keyframe on the frame where the pressed state appears, not where you first noticed the change. Auto-zoom tools help here by watching the cursor or the touch, which is the mental model a side-by-side with Screen Studio walks through in more depth.

If the footage was produced rather than captured, the marks already exist and the edit references them by name instead of by timecode:

{
  "id": "zoom-to-save",
  "type": "camera",
  "atMark": "save-project",
  "targetZoom": 1.35,
  "curve": "easeInOut"
}

The practical payoff is not the first render. It is the fifth: change the flow, re-run it, and every dependent move retimes itself, because the edit was never pinned to a second in the first place.

Keep the moves sparse either way. One zoom per beat at most, held long enough to read, and a hard cut through any stretch where nothing is happening. Dead air is the single most common reason a twenty-second video feels like a minute.

Caption every beat

Most people watch with the sound off, in a feed, without ever tapping unmute. Captions are not an accessibility afterthought here; they are the primary narration channel.

One caption per beat, matched to the tap list from Step 1. Present tense, naming the action rather than the screen: "Rename it inline" beats "The rename screen." Four to seven words. Put them in the lower third and leave them up for at least a second and a half — a caption that flashes is worse than no caption.

Export one file per surface

The requirements genuinely differ, so export once per destination:

• App Store preview. Apple's spec is 15 to 30 seconds, portrait or landscape at the device's native resolution, up to three previews per localisation. Note that Apple's guidance is that previews show the app as captured on a device, so treat any generated or heavily composited video as a marketing asset first and check the current App Store Review Guidelines before you submit one.
• Social. 9:16, under 30 seconds, captions burned in, the first frame legible as a thumbnail.
• Landing page and README. 16:9, muted autoplay, looping. This is the one that can run to 40 seconds, because the viewer chose to be there.

Export three files from one edit. Re-cutting the same flow three times is how a half-day job becomes a two-day job.

Where this goes wrong

The feature dump. Eleven features, twelve seconds each, no through-line. Cut to one flow and make the other ten their own videos.

The three-minute cut. A launch post gets a few seconds of attention, not a few minutes. If the flow genuinely needs three minutes, what it needs is a written walkthrough with a short video at the top.

Keeping a fumbled take because re-recording is annoying. The hesitation is visible. Viewers read it as the app being slow, not as you being unsure.

Captioning the screen instead of the action. "Project settings" tells the viewer where they are. "Rename it without leaving the list" tells them why they should care.

Recording audio nobody hears. A voiceover is worth it for a tutorial and close to worthless for a 20-second launch clip on a muted feed. Spend the time on captions.

The UI changes and the footage dies with it. This is the expensive one, and it is structural rather than a mistake. Any edit built on a recording is invalidated by a redesign, because you cannot re-render a recording. The only way out is for the video to be a spec that regenerates rather than a file that was captured.

Skipping the recording session entirely

Reely is built around that last problem. You describe the flow, an agent rebuilds it as a working SwiftUI mock inside Reely's own scaffold, drives it in the Simulator and films the run — so the footage is produced rather than captured, and the marks from Step 4 exist automatically. The edit itself is JSON you can diff, version and re-run. The FlowSpec and CompositionSpec reference documents both files.

Say the constraint plainly: on that route, the app in the video is a reconstruction of your feature, not your shipping binary. If you need frame-accurate fidelity to the exact build in review, record the real thing and use Reely at the second rung, where it wraps the motion design around footage you supply from any stack.

What the reconstruction buys is the set of shots the other two routes cannot reach. Perfect demo data. A paid tier that is not wired up yet. An error state, an empty state, a locale, a screen that is still a sketch. Text typing itself into a real field rather than a text layer sliding over a rectangle of video. And when the UI changes, you re-run the spec instead of clearing an afternoon to re-shoot.

The tradeoff to weigh: the rebuild route needs SwiftUI, while the other two routes work with any stack. Creating is free; exporting is the paid step.

Frequently asked questions

How long should an app demo video be?

Twenty to forty seconds for a launch post or a landing page, and 15 to 30 seconds for an App Store preview, which is Apple's published limit. Longer only for a tutorial, where the viewer arrived wanting detail. The practical test is whether a stranger can describe what your app does after ten seconds. If not, the problem is the flow, not the runtime.

Can I record a demo video on the iOS Simulator instead of a real device?

Yes, and for marketing footage it is usually easier: xcrun simctl io booted recordVideo needs no cable, no screen-recording toolbar and no device wrangling, and simctl status_bar override gives you a clean 9:41 status bar. The caveats are that Simulator captures carry no audio and use a variable frame rate. App Store previews are a separate question — check the current App Store Review Guidelines before submitting Simulator footage.

Do I need a voiceover for an app demo video?

For a 20-to-40-second launch clip, no. Most views happen muted in a feed, so on-screen captions do the narration work and cost far less to produce and revise. A voiceover earns its place in a longer walkthrough or a sales demo, where you are explaining reasoning rather than showing a flow. Write the captions first either way; a script that works silently works narrated.

Can I make a demo video for an app I haven't finished building?

Yes, with either of two routes. Animate static screenshots or mockups of the unbuilt screens, which reads as a slideshow but ships today. Or rebuild the flow as a runnable mock and film that, which shows real motion at the cost of the video being a reconstruction. Both are legitimate for a waitlist or a teaser; neither is honest to present as a capture of shipping software.

Next

Start at Step 1 and write the tap list. It takes five minutes and it decides everything downstream, including which of the three routes in Step 2 you actually need.

Then pick your rung. Screenshots on disk, a recording you are willing to make, or nothing at all. If it is the third one and you build with SwiftUI, download Reely for Mac and let the agent produce the footage — creating is free, so you can find out whether the reconstruction route works for your feature before you decide anything.