Siri Remote navigation felt sluggish and then over-sensitive next to
native tvOS apps (issue #2006): swipes were priced at a fixed travel
per step, a single flick could glide into a second focus step, hard
lifts coasted several extrapolated steps, and rail scrolls snapped in
65-250ms where native glides.
Retuned the whole path against two hardware instrumentation passes on
an Apple TV 4K: committed-move telemetry through an experimental
UIFocusItem bridge (branch feat/tvos-native-focus-bridge), then a
dedicated native probe app logging every touch sample, pan velocity,
engine hint, focus step, and scroll tick across 101 swipe sessions on
160/230/300pt tiles. What the data showed, now encoded:
- step pricing follows geometry: one step costs the focused item's
extent along the swipe axis plus ~155pt (measured 314/391/410pt on
160/230/300pt tiles), not a fixed distance. Thresholds derive per
axis from the primary focus rect, normalized so a wide-flat control
steps vertically once the finger covers its height. Locked-focus
rows (hub rows, the TV browse rail) vend their selected card's rect
through the new LockedFocusRowNode so the row-wide focus node's
screen-sized rect never prices the step. Scopes, the player's
catch-all surfaces, and unbuilt cards fall back to a fixed 400pt.
- a lift never coasts more than one step: sessions with lift
velocities up to ~11400pt/s never produced a second coast step. The
glide is gated on a sustained drag (two consecutive same-direction
steps), cancelled by reversal pivots and new touches, so a discrete
flick moves exactly one item.
- the native 'inertia' feel is the scroll animation, not focus
physics: the engine's scrollable containers settle over ~450-900ms
of ease-out. TV rail and hub-row navigation scrolls now retarget a
500ms easeOutCubic animation per step, so drags and hold-repeats
chain into one continuous glide that catches up on release.
edde746
f357be4077