When continuation fails, the reason must be stated

What it is

The mail icon was on the left of the Dock a moment ago and is gone; or a tap spins and nothing opens. There is no way to tell whether Bluetooth is off, the two devices are on different accounts, the target is missing the app, or this kind of content cannot be handed over. Continuation failure needs a reason: the failure has to become an actionable sentence, not a missing control or an endless wait. Silent absence is read as “this feature comes and goes,” and next time nobody will count on it. The reason is about how to repair a failed attempt. It is not about how fine-grained the state payload is, and not about where the entry usually lives.

Why it happens

Continuation sits on a long chain: same identity, near-field or network reachability, a receiving app on both sides, Bluetooth or an equivalent discovery radio on, and the OS not excluding that app from handoff. Any broken link often looks the same from outside—no entry, or a tap that does nothing. Seeing only that last symptom, people explain it as unreliability and do not go turn Bluetooth on. An actionable failure names the link they can change: “both devices need the same account,” “this computer does not have the app,” “Bluetooth is off; continuation uses it to find nearby devices.” “Unable to continue” with no link named is as useless as silence, because nobody knows which switch to touch. Timing matters: an explanation at the moment of the tap beats a later “send failed” toast on the source.

Studying it

On a pair that already continues successfully, break one link at a time (Bluetooth off, different account, app uninstalled on the target, out of near-field range) and watch what the system shows and what people do next.

Independent variables: failure type, presence of a reason, whether the reason points to an action, whether the copy appears on the source or the target. Dependent variables: rate of repairing the actual condition, time to repair, rate of blaming “the feature is broken” rather than a missing condition, willingness to try continuation again.

Rendering every failure as the same spinner yields a near-zero spontaneous repair rate—that is the baseline worth measuring. Asking “why do you think it didn’t connect” exposes attribution better than satisfaction scores. In the lab, people are prompted to hunt through settings; in the wild, an icon that simply vanishes often ends the investigation before it starts.

Where it stops holding

When policy forbids handoff (managed devices, an app that declares the activity non-continuable), a detailed reason can become an attack surface; a policy-level “this device does not allow continuation” is enough. If someone has never succeeded and holds no expectation, omitting the entry need not raise an error, or “your device doesn’t support this” becomes daily noise. Transient timeouts deserve a retry, not the full condition list. Once a reason points at a settings pane, the jump must land on that item; a jargon sentence with no matching switch is the same as no reason.

Applying it

• Write one reason per failure that names a condition the person can change; do not use a vanishing entry or an infinite spinner as the only feedback.
• Put the copy on the device being looked at: a dead target entry explains itself on the target; a source that cannot send explains itself on the source.
• Deep-link the remedy: same-account failure opens the account pane, a missing app offers install, Bluetooth off opens the wireless settings.
• Verify on a pair that already does Handoff by turning Bluetooth off, switching one account, and uninstalling the computer-side app. Each failure must show a reason that names the link actually broken; the three cases must not share a single “can’t connect right now.”

Related

• Within the group: K8.01.1 Continuation must keep task state, not merely open the same page · K8.01.2 The continuation entry must be findable on the target device
• Adjacent: K8.05 Pairing and discovery · K1.12 Platform differences in permission models
• Search terms: continuation failure · Handoff · error explanation