Touch sequences are modeled as begin, move, end, and cancel

What it is

An operating system turns a finger contact into discrete events an application can consume. The usual quartet is begin (touch begin / touchstart), move, end, and cancel. Begin marks contact establishment, move updates position, and end marks a completed lift. Cancel is a second kind of termination: the sequence was aborted rather than finished. This is a state-machine interface, not a full physical record of skin deformation or capacitive samples.

Why it happens

Controllers stream samples, but windows, widgets, and gesture recognizers cannot read that raw stream. The system encodes a continuous contact as events so buttons, scrolling, and drawing can share one lifecycle. The four types cover every outcome while contact exists: a normal lift takes the end path; a stolen or interrupted sequence takes cancel. With only begin and end, an application would still believe a finger was down when a permission dialog covered the screen or a system gesture seized the trail. Move is the ongoing position channel; without it there is no velocity estimate and no drag. Cancel is a separate class because its commit semantics invert end: end may submit, cancel must roll back the candidate.

Studying it

Instrument the app to log the full event stream, then interrupt a held press with Control Center, an incoming-call UI, a permission dialog, or a system back gesture. Independent variables include interrupt source, whether multiple fingers are down, whether the target scrolls, and whether the press had already become a drag. Dependent measures include the event-type sequence, the end-versus-cancel ratio, whether the state machine returns to idle, and whether a lift still submits. Clean lab taps almost only produce begin–end and systematically undercount the cancel path; make interruptions a repeatable experimental operation rather than waiting for incidental system events.

Where it stops holding

The four-way split is a common shape in mobile OS and Web touch models, not a law of physics. Game engines, custom drivers, or high-level gesture APIs may hand over only “pinch began / changed / ended,” so the app never sees per-contact types. Mice and some styluses travel a pointer stream whose cancel conditions differ. Mapping desktop down/up onto touch silently drops the fourth termination. Embedded resistive panels, and devices that collapse a whole contact into one command, need not expose this interface at all.

Applying it

• Implement buttons, sliders, and drawing on one machine: begin enters a candidate, move updates it, end submits, cancel rolls back.
• On a real device, hold a target and interrupt once with Control Center and once with a notification shade; confirm neither a submit nor a stuck highlight.
• Count end and cancel separately in logs; when cancel rate spikes, inspect system preemption and window focus before resizing buttons.

Related

• Same group: C2.16.2 System interruptions inject cancel into an in-flight touch sequence · C2.16.3 Unhandled cancel events leave widgets stuck in a pressed state · C2.16.4 Each multitouch contact has an independent begin-move-end lifecycle
• Nearby: C2.07 Touch-down and touch-up activation · C2.08 Touch cancellation gestures
• Search terms: touch event · touchcancel · pointer lifecycle