How to record an iOS Simulator demo with touch indicators

You need a video of your iOS app: for an App Store preview, a pull request, a TestFlight note or a landing page. The Simulator is right there, so you record it. Then you watch the result and notice the problem. Screens change, sheets slide up, a toggle flips, and nothing shows where the finger went. Viewers have to guess what you tapped.

This post covers the ways to record the iOS Simulator, what each one gets right, and how to get touch indicators into the video without hand-animating circles in an editor.

#Your options for recording the iOS Simulator

There are three common approaches, and they capture different things.

The command-line option is worth knowing even if you never use anything else:

xcrun simctl list devices booted                       # which devices are running
xcrun simctl io booted recordVideo --codec=h264 demo.mov   # press Control-C to stop

It records exactly what the device renders, which makes it the cleanest raw footage you can get. What it doesn't know is what happened: where you tapped, which moment was the result, and which three seconds were a spinner.

#Why touch indicators matter in an iOS demo

On a Mac demo the pointer tells the story. You see it travel to a button, click, and the screen responds. On a phone recording there is no pointer, so cause and effect disappear. A sheet appears and the viewer can't tell whether it was a tap, a swipe or a push notification.

A good touch indicator is:

• Fingertip-sized, not cursor-sized, so it reads as a touch.
• Placed exactly on the control that was tapped.
• Brief. A soft press and release, then gone, so it never hides the result.
• Consistent across every scene and every export.

Adding one by hand means finding every tap in the footage and animating a circle there, then doing it again after every retake.

#Record a booted device directly with DemoTake Agent

DemoTake Agent lists every booted iOS Simulator device as a capture target. It records the device screen itself, not the Simulator window, so the window may be covered, minimized or on another desktop while you work. Recording a device doesn't need Screen Recording permission either.

Recording devices directly is a DemoTake Agent feature. In DemoTake Studio, record the Simulator window instead and keep it visible. Blank spans where the window stopped drawing are cut automatically.

#Log taps so they render as touch indicators

DemoTake doesn't tap on devices for you. Whatever drives the app, you or a test or an agent, reports each tap with take_log_event, and DemoTake renders it as a touch indicator. New takes of a Simulator target use the touch pointer shape automatically.

There are two ways to say where the tap was. point is normalized to the device screen, from 0 to 1 with the origin at the top left:

{ "take_id": "take_01j…", "kind": "tap", "label": "Tap General", "point": { "x": 0.5, "y": 0.25 } }

Or pass device_point in device points, the coordinates your test framework already uses, and DemoTake converts it with the device's screen size:

{ "take_id": "take_01j…", "kind": "tap", "label": "Tap General", "device_point": { "x": 201, "y": 218.5 } }

On a device whose screen is 402 × 874 points, those two calls land on the same spot. "tap" is recorded as a click in the trace, so the editor, the camera and the cut suggestions treat it like any other meaningful action. Log right after each tap, give it a human label, and set redact: true for anything secret.

#Drive the device with XCUITest, simctl, idb or a computer-use agent

Anything that can operate the Simulator works, as long as it reports its taps. Pick the one you already have:

• XCUITest. Your UI tests already know every element's frame in points. Log the center of the frame as device_point right after each tap.
• simctl. xcrun simctl openurl booted myapp://settings jumps straight to a deep link, which is a clean way to set up a scene's starting state. Log a navigation event if the viewer should see it as a step.
• idb. It taps at coordinates, so log the same coordinates you sent.
• A computer-use agent. It sees the screen and taps in the Simulator window. Convert its position to the device screen and log it as point.

If you connect a coding agent to DemoTake, the workflow guide it reads tells it exactly this. Let your coding agent record the demo shows the setup.

#Check what's on screen with text recognition

Agents need to know what the device shows before and after each step. On Simulator targets, observe_state and assert_text read the device screen with text recognition. That's enough for an agent to confirm "General" is visible before tapping it, and to prove "Software Update" appeared afterwards:

{ "take_id": "take_01j…", "text": "Software Update" }

Passing assertions show up in the take's proof manifest, which matters when the video goes to a reviewer.

#Put the recording in a phone frame for 9:16

For iOS Simulator takes, DemoTake always shows the whole device screen instead of cropping it. In 9:16 exports it also draws a plain phone frame around it. In the editor, the Effects tab of the inspector has Device frame under Background: Auto (on for 9:16, off for wide outputs), On or Off. Agents use edit_apply with device_frame{mode}.

Export both at once with ⌘E. How to make a vertical 9:16 demo from a Mac app covers the rest of the vertical checklist.

#A quick checklist for iOS Simulator demos

• Use a clean device with no leftover data, and hide debug banners. xcrun simctl status_bar booted override --time 9:41 gives the status bar a tidy, fixed time.
• Seed demo data you're happy to show. Anything secret can be blurred later with Redaction.
• Give each scene one job and end it on a screen that proves something happened.
• Log every tap, with a label a viewer would understand.
• Preview the 9:16 export with the phone frame before you post it.

Download DemoTake, boot a device, and record your first Simulator take with touches.