How do you document a flow inside an iPhone app?

Why this is harder on iPhone than on a desktop

On a desktop, documentation tools work by watching your clicks. A browser extension or a desktop agent sees every click event, screenshots the page at that moment, and reads the label of the control you clicked. That is how Scribe and Tango produce a captioned guide from a single run-through.

iOS exposes no equivalent. No API lets one app observe touches in another. The sandbox that makes iPhones safe is the same sandbox that makes click-capture impossible, and no amount of engineering gets around it. Any tool claiming to capture your taps inside another iOS app is either running on a Mac watching a mirrored phone, or is describing something it does not do.

So the mobile process has to start somewhere else: with the recording.

The recording is the source of truth

A screen recording already contains every step of the flow. What it lacks is structure — it is seventeen seconds of video, not seven steps. Turning one into the other means deciding where the boundaries are.

Two properties of iOS screen recordings make that tractable:

1. They are variable frame rate. The encoder only emits a frame when pixels change, so a screen you held still for four seconds costs almost nothing to scan.
2. A step boundary is visible. The screen changing from one settled state to another settled state is the step. It can be measured from the pixels rather than inferred.

That is the whole basis for automatic step splitting, and it is why the job is possible on the phone at all.

Doing it by hand

If you only have one flow to document, the manual route is fine:

1. Screenshot each screen as you go (side button plus volume up).
2. Open a document and paste them in order.
3. Crop each one, write a caption, and draw an arrow or circle on the control.
4. Cover anything private with a filled shape — not a blur.

Budget about a minute per step, and expect to redo the whole thing when the app’s UI changes. It works, and it is what most teams do.

Doing it with Walkthru

Walkthru collapses steps 1 to 3 into one pass. You record the flow once; it cuts the recording where the screen actually changed, labels each cut by what kind of transition it was — a new screen, a scroll, a swipe, typing, a dialog, a toggle — and hands you a guide with a screenshot per step.

What it deliberately does not do is write your captions. It knows where the steps are, because that is measurable. It does not know what they mean. A plausible but wrong caption costs more to notice and correct than an empty one costs to write, so steps arrive untitled.

You then:

• Tap a frame to place a marker where the reader has to touch.
• Accept the redactions it offers. It reads each screenshot on the device and flags emails, phone numbers, card numbers, IBANs, SSNs, routing numbers and wallet addresses. It offers; you decide.
• Export a PDF, a Markdown bundle, or a sequence of annotated images.

All of it runs on the phone. There is no account and no server, so the recording — which contains whatever you had on screen — never leaves the device.

What to write in each caption

The captions are the part no tool can do for you, so they are worth doing well:

• Use the imperative. “Tap Transfer.” Not “The user should tap Transfer”, and not “The Transfer screen appears” — the reader wants an instruction, not a narration.
• Name the control the way the screen does. If the button says Send now, write Send now, capitalised the same way.
• One action per step. If a caption contains “and then”, it is two steps.
• Say what confirms success when a step’s result is not obvious. “The balance updates” tells a reader they are on track.