The most common reply to the last post was some version of: “Fine, but I have eleven features and a 30-second slot.” That is a different problem from bad recording technique. You can nail lighting, audio, and pacing and still ship a demo nobody finishes, because the demo is a list instead of an argument.
Short answer: To showcase app features when you have too many, cut to the one feature that solves the viewer’s problem plus at most two supporting features, then record the whole thing as a single continuous take on your iPhone. DemoScope handles this on iOS with a face cam overlay, touch indicators, and a teleprompter, and Pro is a $19.99 one-time purchase.
Feature tours lose to feature arguments
A feature tour says “here is what the app has.” A feature argument says “here is the thing you cannot currently do, and here is the app doing it.” The second one holds attention because there is a question open in the viewer’s head the entire time.
Practically, that means picking one hero feature and treating everything else as evidence. The earlier post on how to showcase app features: 7 proven strategies for demo videos that convert covers the ordering logic in more depth. This follow-up is about what to do with the features that lose the vote.
The three-question cut list
Run every feature on your list through these. A feature that fails two of three does not belong in the demo.
- Does it change the outcome, or just the experience? Outcome features (the app does something the viewer cannot do today) stay. Polish features (dark mode, haptics, a nice settings screen) go.
- Can a stranger understand it in under eight seconds of screen time? If explaining it requires setup, it needs its own video, not a slot in this one.
- Would removing it make the remaining demo confusing? If yes, keep it, but demote it to a two-second pass on the way to something else.
Everything that gets cut is not wasted. It becomes a standalone 40-second clip you record later, which is a much better use of the feature than a rushed cameo.
Match the feature type to the recording mode
Different feature types need different capture. DemoScope has two recording modes on iOS, and picking the wrong one is the most common cause of a re-record.
| Feature type | What the viewer needs to see | Recommended DemoScope mode |
|---|---|---|
| Core in-app flow (signup, checkout, main loop) | Exact taps and screen states | In-app recording, touch indicators on |
| Feature that leaves your app (share sheet, Files, Safari, Shortcuts) | Continuity across apps | External PiP mode |
| Onboarding or setup walkthrough | Steady narration, no stumbles | In-app recording with the teleprompter |
| A toggle whose effect is subtle | Cause and effect in one shot | In-app recording, toggle then immediately show the changed state |
The trade-off is real and worth stating plainly: External PiP mode records your whole phone with a floating face cam across every app, but it gives up touch indicators, the teleprompter, and the DemoScope HUD, because iOS routes that capture through a Broadcast Extension. Tools in External PiP mode are limited to Camera, PiP Border, and Text on screen. So if a feature’s whole point is a precise tap sequence inside your app, record it in-app.
What goes wrong on the third take
Recording daily teaches you that the failure modes are boring and repeatable. Storage is the big one: a device-native-resolution MP4 fills a phone faster than you expect, and the recording that dies at second 52 is always the good one. Clear space before you start, not after.
Mic routing is second. If AirPods are connected, your audio comes from AirPods, and it will sound like a phone call. Disconnect Bluetooth before recording, or commit to it and stay consistent.
Third is the face cam eating the UI. The camera bubble in DemoScope is draggable to any corner, resizable by pinching, and available as a circle, square, vertical rectangle, or horizontal rectangle. Park it in a corner where nothing important happens, then rehearse the flow once before hitting record. More on the delivery side of this in the mobile-first recording strategy most developers miss and in the mobile recording setup that actually converts users.
When cutting features is not the fix
Sometimes the demo is short and still dull. That is a delivery problem, not a triage problem, and no amount of cutting saves it. If your voice sounds like you are reading a changelog, the fix is pacing and presence, which going from code to demo without looking like a robot gets into. Also worth being honest: DemoScope does not edit video. There is no trimming, no captions, no cloud hosting. Recordings export as MP4 to your camera roll, so a one-take-with-a-cut-list workflow is the one it rewards.
Cut to three features, record one clean take, and keep the rest for their own videos. DemoScope runs on iPhone and iPad on iOS 14 or later if you want touch indicators and a face cam without a subscription attached.
Frequently Asked Questions
How many features should an app demo video show?
One hero feature and up to two supporting features. Beyond three, viewers stop tracking what the app is for and start skimming, and the demo becomes a list rather than a reason to download.
How do I record a feature that opens another app on my iPhone?
Use External PiP mode in DemoScope, which activates a system-wide floating face cam and sends DemoScope to the background so you can navigate to any app while recording. The trade-off is that touch indicators and the teleprompter are not available in External PiP mode.
Can I trim the extra features out of my demo afterward?
Not in DemoScope. DemoScope has no video editing, so recordings save to your camera roll as MP4 (H.264) exactly as captured. That is why the cut list matters before you press record rather than after.
Is DemoScope a subscription?
No. DemoScope Pro is a $19.99 one-time purchase that removes the watermark and unlocks all features. A free tier exists with watermarked recordings if you want to test the workflow first.