Setup and teardown latency of a borrowed connection directly affects usability

What it is

The first stroke is already on the glass while Sidecar still says “Connecting,” and the line appears seconds later. Afterward, “Disconnect” spins before the tablet’s own home screen comes back. Setup and teardown latency decide whether the borrow is usable: too slow to start, people assume the pen is broken and reach for the mouse; too slow to release, they are stuck in a state that is neither computer display nor tablet. Latency here is how long the doors take to open and close, not how to fall back after a drop. The second of Bluetooth-keyboard reconnect after wake is setup latency too.

Why it happens

A borrow session walks discovery, auth, a video or event channel, and capability negotiation (pressure, hover, keyboard layout). Any of those queued, and the pen is already down. Handwriting and pointing are intolerant of end-to-end delay: past a few tens to about a hundred milliseconds, nib and ink separate, and people slow down, press harder, or drop fine work. Setup latency sits before the first stroke and is usually longer, because it is handshake, not steady-state transport. Teardown costs as well: the channel must stop, focus must return, the source must rebuild its own desktop. If teardown only finishes in the background while the UI still says “lent out,” people mash disconnect and turn one exit into several re-entries. Usability here is a time budget: time until the first stroke works, time until the source is itself again—not average bandwidth.

Where it stops holding

An always-on borrow (a tablet that is a sidecar all day) amortizes setup across the day; delay is mostly the morning’s first connect. Extremely short borrows (one confirmation code, one signature) are the harshest on setup; two extra seconds and a local keyboard wins. A wired dock or a vendor high-bandwidth path can make setup negligible; ordinary Bluetooth and a crowded 2.4 GHz room cannot promise lab Sidecar numbers. Teardown stretches when the source is busy (an unsaved local draft still on the tablet); local access to that draft should beat a pretty dismiss animation.

Applying it

• Before the first stroke or key, show a closable setup state: “connecting the pen to the computer.” On timeout, fail and leave local input working; do not pour strokes into an invisible buffer.
• Treat steady-state lag separately: predict ink locally and reconcile with the far side, so every stroke is not still gated on handshake after the session is up.
• Return the source to its own desktop within a second or two of release. If cleanup must continue in the background, local apps must already be tappable.
• Verify from cold start: time from invoking Sidecar to a visible first stroke, and from a sleeping Bluetooth keyboard to the first character. If either is long enough that people switch to the local trackpad, shorten the handshake or offer “use local now, switch when connected.” After disconnect, open a local app on the tablet home screen immediately and confirm it is not still inside a peripheral ghost.

Related

• Within the group: K8.08.1 One device's input (keyboard, stylus) can be borrowed by a nearby device · K8.08.2 Input borrowing needs a clear owner so devices do not fight over input · K8.08.4 Borrowed input depends on network and pairing; a drop needs a clear fallback
• Adjacent: K8.05 Pairing and discovery · K3.02 Pen and touch together
• Search terms: Sidecar latency · connection setup · input lag