App Demonstration: How to Show Your App to Anyone
The phrase covers three unrelated jobs. The one that goes badly is almost always the one you prepared for as though it were a different one.
Someone has asked to see your app. What you should do next depends entirely on who asked, and the phrase gives you no help at all, because an app demonstration for an App Store listing and an app demonstration in an investor meeting share a name and almost nothing else.
Search this term and you get six video-making tools and one page of Oracle documentation about running a sample application. That spread is not a search engine failing. It is an accurate reflection of a phrase that covers three different jobs, and the reason app demos go badly is usually that someone prepared for the wrong one.
Here are the three, what each actually needs, and the checklist for the one that can fail in front of people.
The short answer
An app demonstration is any showing of an app in use, and it takes three forms: recorded, live, or handed over. A recording is watched muted and alone. A live demo happens with you narrating and can break in real time. A handed-over demo runs without you present. The preparation for each is different.
Three jobs hiding behind one phrase
Work out which one you are on before you do anything else. Everything downstream follows from it.
The recorded demonstration
Audience: strangers. You are: absent. Sound: almost certainly off.
This is the App Store preview, the video on the landing page, the clip in the launch post. It is watched by people who have not decided to care yet, usually muted, usually for less time than you would like. It has to make its argument visually and it has to make it early.
The live demonstration
Audience: specific people in a meeting. You are: talking over it. Sound: yours.
An investor pitch, a client call, a conference talk, a technical interview. You can adapt, answer, skip ahead. In exchange, it can fail while people watch — the network drops, the account is in a strange state, the notification arrives.
The handed-over demonstration
Audience: one person, alone, later. You are: not there. Sound: none.
A TestFlight build sent to a reviewer, a link to a staging build, an app someone opens after a call. Hardest of the three, because it has all the fragility of live software and none of your narration to cover it.
Most demo advice on the internet is about the first one, because the first one is the one you can sell a tool for. The second and third are where the deals and the jobs actually are.
The recorded demonstration
The short version: one claim, thirty seconds, muted, and the first three seconds decide whether the rest is watched.
Because it is asynchronous, everything has to be legible without you. That means on-screen text rather than narration, since autoplay is muted nearly everywhere a demo appears. It means starting on the thing that matters rather than on your login screen. And it means the video is a single argument, not a tour.
The production side of this — picking the flow, writing a shot list, budgeting the seconds, cutting on interactions — is a whole procedure, and the blog covers it step by step. The rest of this article is about the two forms nobody writes about.
One thing worth taking from here into the other two: write down the claim. A recorded demo without a claim becomes a feature tour. So does a live one.
The live demonstration
This is the one that can go wrong in front of people, and it goes wrong in predictable ways.
The single most common cause of a failed live app demo is depending on something you do not control at the moment you need it. Conference wifi. A staging server. A third-party API. An account whose data changed since you rehearsed. Every one of those is avoidable, and the fix is the same: demo something local and known.
The pre-flight checklist
Run this in order, the day before, not the morning of.
- Build local. Run against a local build with local or seeded data. If the demo needs a server, run the server on your machine. A network-dependent demo is a bet on someone else's uptime.
- Seed the data yourself. Real-looking names, plausible numbers, dates near today. Not
test1, not an empty state, and nothing from a real customer. - Kill every interruption. Do Not Disturb on the machine and the phone. Quit Slack and mail entirely rather than muting them. Close the tabs behind the demo — people read them.
- Set the device state. If you are demonstrating on the iOS Simulator, fix the status bar so it does not show 3:47pm and a 12% battery mid-pitch.
- Rehearse the failure. Do the flow once with the network off and see what breaks. Whatever breaks is what will break on the day.
- Have a recorded fallback. Keep a screen recording of the same flow on your machine, offline. If the live build fails, you switch to it and keep talking rather than debugging in front of your audience.
- Know your exit line. Decide in advance where the demo ends, so you stop on the result instead of trailing off into settings.
Step four is one command:
xcrun simctl status_bar booted override \
--time "9:41" --cellularBars 4 --batteryState charged --batteryLevel 100Step six is the one people skip, and it is the one that saves the meeting. A recording is not an admission of failure; it is what a professional brings.
While you are demonstrating
Narrate the intent, not the mechanics. "I'm going to create a project and share it" tells people what to watch for. "Now I'm clicking the button in the top right" tells them what they can already see.
When something breaks, say what you expected to happen, and move on. Every experienced person in that room has had a demo break. What they are actually assessing is whether you know your own software well enough to know what went wrong.
There is one more habit worth building, and it costs nothing: rehearse against the clock, out loud, once. Not in your head — out loud, with the app open, timing it. Almost every live demo runs longer than the person giving it expects, because thinking through a flow takes about a third as long as narrating it. If you have been given ten minutes and your rehearsal runs eleven, you do not have a pacing problem, you have one screen too many. Cut it before the meeting rather than rushing it during.
And decide in advance what you will skip if you run short on time. Live demos get interrupted by questions, which is a good sign and a scheduling hazard at the same time. Knowing which two screens are expendable means you can absorb three minutes of questions without losing the ending, and the ending is the part that proves the claim.
The handed-over demonstration
Someone opens a TestFlight build alone, on a Tuesday, between other things. You get one screen before they decide.
The first screen is the entire message. There is no narration, no context, no you. If your app opens on a login wall or an empty state, that is your demo. Seed the account before you send it, or ship a demo mode that populates itself.
Give them one instruction, not a tour. A single line in the TestFlight notes — "try creating a project and sharing it" — outperforms a numbered list of everything the build contains. People do the first thing you ask and rarely the fourth.
Instrument it, or you learn nothing. Without analytics on this build you will get "looks nice" and no information. With them you find out that four of six people stopped at the same screen, which is worth more than any of the feedback.
Assume they will not report bugs. They will just stop. A crash in a handed-over demo is silent, so the build you send should be the one you would ship, not the one from this morning.
There is a version of this that people underuse: send a recording alongside the build. Thirty seconds showing the intended path, attached to the same email. The people who open the build get context before they start, and the people who never get round to installing it still see the app. For a TestFlight invite going to a reviewer, a journalist or a prospective employer, that pairing does considerably better than the build alone, because installing an unfamiliar app is a real amount of friction and a video is none.
That is also the honest reason the recorded demonstration is worth making even when your actual goal is one of the other two. It is the only one of the three that you can send.
What every demonstration needs
Whichever of the three you are doing, the floor is the same:
- A claim. One sentence about what this proves. Written down, before anything else.
- A state. Seeded, plausible, populated. Every version of this failing looks the same: an empty screen where the value should be.
- A path. The specific sequence, decided in advance. Improvising the route is how a two-minute demo becomes seven.
- An ending. The moment where the claim is proven. Stop there.
If you cannot write the claim, you are not ready to demonstrate anything yet, in any of the three formats.
Where app demonstrations go wrong
Preparing for the wrong job. Bringing a polished video to a technical interview where someone wanted to watch you use the thing. Or improvising live when the audience was always going to watch it alone, later, muted.
The tour. Showing everything, because cutting features feels like hiding them. The tour is the default outcome of not writing a claim.
Demoing on someone else's network. Covered above, and it happens at every conference, every year.
An empty state. The most common single failure across all three, and always caused by skipping the setup because the setup is boring.
Assuming automation covers the live case. Worth naming because it is the limit of the tool this site sells. Reely produces the recorded demonstration — it drives an iOS feature in the Simulator and composites the reel — and that solves exactly one of the three jobs here. It does not rehearse you, it does not seed your investor demo, and it will not stop the wifi failing. A generated video is a good fallback to have on your machine during a live demo. It is not a substitute for having prepared one.
Frequently asked questions
What is an app demo?
An app demo is any showing of an app in actual use, as opposed to describing it or showing screenshots. It takes three forms: a recorded video, a live walkthrough you narrate, and a build handed to someone to try alone. The word is used for all three interchangeably, which is why people frequently prepare for the wrong one.
How long should an app demo be?
Around thirty seconds for a recorded demo on a listing or landing page, where the viewer has not committed to anything. Two to five minutes for a live demo, driven by how long your audience will stay engaged rather than how much you have. A handed-over build has no length — what matters there is how long it takes to reach something interesting.
How do you demo an app in an interview?
Run it locally with seeded data, keep a recording as an offline fallback, and narrate your intent rather than your clicks. State what you are about to show before you show it. If something breaks, say what you expected to happen and continue — interviewers are assessing whether you understand your own code, and a calm diagnosis often scores better than a flawless run.
What is the difference between a demo and a walkthrough?
A demo proves one claim as fast as possible and is aimed at someone deciding whether to care. A walkthrough teaches someone how to use a product they have already chosen, and is longer, more complete and more patient. Using a walkthrough where a demo was wanted is the most common reason a demo runs four minutes.
Where to start
Answer one question before you prepare anything: is this watched without you, narrated by you, or explored without you? That answer picks the checklist, and getting it right is most of the work.
If it turns out you need the recorded one, and your app is on Apple platforms, Reely will produce it from a flow you describe rather than one you perform. That covers the App Store preview, the landing page clip, and the fallback file you keep on your laptop for when the live demo fails. The docs show how a flow is written, and it is free to create with until you export.