Contact limits vary by device generation and cannot be assumed uniform

What it is

“Modern screens are all ten-point” is false. Inside one brand, a flagship phone, an entry tablet, a car cluster, and a wireless display can differ by more than 2× in simultaneous contacts. An app that hard-codes a three-finger gesture and a four-person whiteboard from the developer’s ten-finger phone will silently lose fingers on another shipping device. The cap is a device capability. Query or probe it; do not treat it as a platform constant.

Why it happens

Touch ICs are bought by BOM: cheaper parts ship fewer channels and a weaker MCU, so peak tracking is cut first. The OS then trims by product shape. Some tablets share a laptop driver and report a cap of five; some TV touch frames guarantee only two-finger zoom. WebViews, remote desktop, and wireless-display sinks clamp again, folding a source’s ten points into two to five on the receiver. Generational change is not monotonic: a new phone may expose fewer finger slots than its predecessor to save power or to reserve a slot for a stylus. One measurement on the developer’s unit is that IC’s number, not the product matrix’s.

Studying it

Run the same progressive-finger script across the supported matrix. List measured cap, OS version, and whether an external digitizer is attached. Independent variables are device tier, stylus attached or not, screen-mirroring on or off, and browser versus native. Dependent measures are trackable id count, three-finger gesture success, and the gap between documented nominal and measured values. Split “maximum the API claims” from “how many contacts actually report at once”: some stacks return 10 while the fifth finger is already dropping. Cover at least one entry device and one automotive or education tablet, or flagship sampling bias eats the matrix.

Where it stops holding

If the product runs on one locked SKU (a dedicated exhibit, a single industrial panel), a uniform assumption holds and probe code is surplus. If OEMs fill the query API with a fake number, the query itself is untrustworthy and runtime probing remains necessary. Emulators and cloud device farms often simulate 10, which does not match entry hardware. Writing an Android or iOS “platform default cap” into a cross-platform framework fails immediately on Linux desktop touch and on Harmony devices.

Applying it

• At launch, obtain the local cap by a progressive-finger probe or a capability query; when it is below three, replace richer gestures with visible buttons instead of waiting for users to notice.
• Test the matrix across entry, flagship, tablet, automotive, and mirrored sinks. Document gestures as “requires N simultaneous contacts,” not “supports multitouch.”
• Retest remote-desktop and casting on the sink’s cap; degrade source gestures when the far side becomes two-finger.

Related

• Same group: C2.18.1 Hardware and the OS cap how many contacts can be tracked at once · C2.18.2 Overflow contacts are dropped silently rather than signaled as errors · C2.18.3 On shared displays the contact cap bounds concurrent participants
• Nearby: C2.15 Touch sensing principles and failure conditions · C3.12 Three- and four-finger system gestures
• Search terms: device capability · multitouch fragmentation · ten-point touch