App gestures that start at the edge are truncated
Aliases: bezel swipe · edge exclusion · edge hot zone · truncated stroke
What it is
When a finger enters from a few millimetres inside the screen edge, the system treats that path as its own hot zone first. An app that wants the same start for a carousel, a stroke, or a map pan never gets a clean onset: edge interception delivers delayed, clipped, or cancelled events. This is spatial—the fight is in the edge band, not in the centre of the screen. A swipe that begins in the centre usually still belongs to the app. This entry is only about how that geometric strip eats app gestures. It is not about why the system wins arbitration in general, and not about how edge-to-edge displays widened the strip.
Why it happens
System Back, Control Center, and Notification Center depend on the edge as a start feature: without an edge they cannot be told apart from in-page swipes. The system therefore draws a hit band along the bezel and holds down-events that land inside it. If the person continues into a system pose, the app may never see a complete path; if they turn inward, events are forwarded later, but the first millimetres are gone. For ink and maps that need a precise onset, what is lost is the starting direction; for a carousel, what is lost is the habit of dragging the next item in from the left rim. Thick cases make people start further in and sometimes miss the band; curved screens bend the effective band onto the side, so onset is less stable. Truncation is not random recognition noise. Once the down lands in the band, the app’s time series is missing its head.
Studying it
Bin by start location: 0–5 mm from the edge, 5–15 mm, further in. Compare app completion against false system triggers. Regress the first logged coordinate’s distance to the edge.
Independent variables: millimetres from the edge at onset, swipe direction, band width, presence of a case. Dependent variables: app recognition completed, system pre-emption, length of missing path head, reports of “I swiped and nothing moved.”
A mouse dragged from the “edge” in a simulator is more precise than a finger and underestimates truncation. Real devices need left, right, and bottom edges measured separately; widths differ. Do not write “centre swipes work” as “edge gestures work.”
Where it stops holding
On bodies with hardware buttons and no edge Back, the left and right bands may be absent; truncation then lives mainly in the top pull-down and the bottom home swipe. Trackpads and mice have no screen edge. Insetting the whole pannable region until onsets start outside the band removes truncation at the cost of a narrower content area. A long swipe that begins in the content and only passes the edge later is usually not taken over mid-flight.
Applying it
- Do not make “swipe in from the left rim” the only way to see the next item; offer an in-frame next control, a pager, or a strip of thumbs.
- Keep the main onset zone for ink, crop handles, and maps off the band, or treat a stroke that fell into the band as a cancel rather than a kinked line.
- When an in-page swipe must share a direction with the system, inset the legal start region past the band and make that region visible.
- Verify by asking ten people to advance a full-width carousel or drag a full-width map with a natural onset. Slow the recording and measure down-to-edge distance. Count how many onsets landed in the system band and how many of those failed as app gestures. Use centre-start successes as a control, not as proof that the edge is fine.