Mobile app demos often lose the important action inside a very small screen. You can see a phone, a finger moves, and the next view appears, but it isn't always clear what the person selected or why the screen changed.
Before choosing a device mockup or a soundtrack, work out which interaction someone needs to understand. Then decide where the video will run. A website explanation and an App Store preview can use the same product story, but they have different production constraints and shouldn't automatically share the same export.
Choose a task that makes sense on a phone
Imagine a fictional errands app where someone adds a pickup, chooses a reminder time, and marks it complete. That's a useful mobile demonstration because the interaction has a clear beginning and end. It also gives you specific questions to answer: where does the person enter the task, when do they choose the reminder, and what confirms it was saved?
This is a planning example, not a claim about a real app or a video we've produced. For your app, choose a task you can record in the current version. A demo of a feature that only exists in design files should be identified as a concept, not presented as the experience someone gets after installing.
Avoid combining several unrelated journeys just because they're easy to capture. A home screen, an account page, and a settings page don't add up to an explanation unless the viewer can see why the person moves between them.
Decide whether this is a store preview or a website demo
Apple's app preview guidance calls for footage of the app itself, and its review guidelines describe what can appear in previews. Check those requirements before building a composition around a floating device, external scenes, or a website-style introduction. A video intended for your own landing page has a different publishing context.
For the errands example, the store version could follow the task directly inside the app. A website version might first show the situation that makes a reminder useful, then move into the interface. Keep separate briefs for those versions so an editor doesn't assume every visual choice is interchangeable.
Also check the current upload specifications for the target device and placement before recording. If the source footage doesn't fit the required frame, a late crop may remove the navigation or confirmation the demo depends on. Decide the delivery format while you can still capture the right material.
Keep taps, keyboard changes, and results understandable
On a phone, the keyboard can cover half the interface and move the control you're trying to explain. Record the whole task once before choosing your crops. Watch where the layout changes, then plan a view that keeps the field, typed value, and next action recognizable.
A subtle touch indicator can help explain a tap in a website demo, but don't let it become more noticeable than the control. For a swipe, preserve enough of the movement and destination to show what happened. A cut before the gesture finishes can make a normal interaction look like an unexplained screen change.
In our fictional app, the important result is a saved pickup with the chosen time. Stay on that state long enough to compare it with what was entered. If the keyboard disappears and you immediately cut to the logo, viewers may never learn whether the reminder was created.
Treat permission requests as part of the experience
If a feature depends on permission, decide whether the video starts with that permission already granted or shows the request. Both can be reasonable, but an instructional demo should identify the starting condition. Otherwise someone following along may encounter a system prompt that the video never acknowledges.
Apple recommends requesting notification permission in a context where people can understand its purpose. For the errands example, showing the reminder choice before the request makes the relationship clear. The film can explain why the prompt appears without suggesting that choosing a reminder guarantees the person will approve notifications.
Don't replace an actual system prompt with a fictional friendlier version. Capture the supported flow and keep its language legible, or describe that permission has already been enabled in the demonstration. Use a separate support path if declining permission changes what the person can do next.
A worked brief for the fictional errands app
The brief below is for a website demo. It would need a separate pass against store requirements before becoming an App Store preview. That distinction prevents a practical planning example from being mistaken for a submission-ready specification.
Show someone adding 'Pick up repaired headphones' in the current app. Keep the keyboard transition visible, and show the date and time they choose. If notifications are already enabled, say so briefly. Otherwise capture the real permission flow after the reminder choice. Return to the task list and hold on the saved pickup with its reminder time. Later, show the person marking that same pickup complete. Use sample account data and suppress unrelated notifications. Keep the task name consistent in every scene. End with the app's actual download destination. Do not add a notification arriving unless that behavior has been recorded or clearly labeled as an illustrative sequence.
Review the video on the device where it will be watched
A readable desktop preview can still produce tiny labels on a phone. Watch the exported draft at the intended size and check the task name, time picker, and confirmation without zooming. If you have to pause repeatedly, simplify the view or give that action more time.
Review captions against the recording, especially names and times. W3C's caption guidance notes that captions convey relevant speech and non-speech audio; automatic text still needs checking. Place them where they won't cover the keyboard suggestion, navigation, or result the viewer needs.
Finally, compare the sequence with a fresh run through the current app. If navigation or permission behavior has changed, update the affected recording before publication. The best reason to keep the demonstration to one task is that it remains both easier to follow and easier to maintain.