Each multitouch contact has an independent begin-move-end lifecycle

What it is

Under multitouch the system assigns each contact a stable pointer id (touch identifier) and lets that id walk begin–move–end (or cancel) on its own. Two fingers are not “two coordinates inside one touch event”; they are two parallel lifecycles. Lifting one finger ends only that stream; the other may keep moving. Treating all fingers as a single “touch present / touch absent” bit tears down a still-held finger when another leaves mid-gesture.

Why it happens

The capacitive controller tracks contact blobs separately. The OS binds later samples back to the same blob via the identifier until the blob vanishes or is canceled. Application gestures often need relative motion of two fingers, but the implementation should still keep per-id position history and combine it inside the recognizer. When a system gesture steals one finger, typically only that id receives cancel; the other should keep its move stream. If “contact count went from 2 to 1” is treated as end, a pinch dies when the user deliberately continues as a one-finger drag—or, conversely, a stale coordinate from a canceled id still shifts the zoom origin.

Studying it

Log every identifier from appearance to disappearance while participants: press two fingers then lift one first; hold one then plant a second; move two fingers while the system steals one. Independent variables are plant order, lift order, and whether the canceled finger was primary or secondary. Dependent measures are whether each id received a paired terminator, the transform the recognizer emits after a missing finger, and whether the remaining finger can still scroll. Looking only at “multitouch gesture success” disguises lifecycle bugs as recognition-rate problems.

Where it stops holding

Independent contacts do not mean independent gestures. The system may still award the whole set to one recognizer, so canceling one finger voids the group. When hardware merges two fingers into one blob, the app sees a single id and no amount of lifecycle hygiene yields two fingers. On the Web, touches and changedTouches differ: the latter holds only contacts whose state changed this frame, and using the wrong set treats an unchanging finger as gone. A new finger past the device cap never receives an id, so it has no independent lifecycle to speak of.

Applying it

• Store each finger’s origin, last position, and velocity in a map keyed by pointer id; on termination delete only that key.
• After a pinch or rotate loses a finger, branch explicitly: degrade to one-finger pan, freeze the transform, or abort the gesture—never keep using a deleted id’s coordinates.
• On device, record two-finger lifts that are not simultaneous and a finger stolen by a system gesture; check the log that every id ended or canceled.

Related

• Same group: C2.16.1 Touch sequences are modeled as begin, move, end, and cancel · 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
• Nearby: C2.18 Multitouch contact limits · C2.19 Contact merging and splitting
• Search terms: pointer id · multitouch lifecycle · changedTouches