The standalone function set when the phone is out of range must be defined in advance

What it is

A watch will leave the phone’s Bluetooth or network: a run with the phone in a locker, a metro cut, a trip wearing only the watch. Which functions remain fully usable then must be written as a list at design time, not left for each button to fail after the drop. Timers, alarms, downloaded music, near-field payment, GNSS tracks usually belong on the list. Live threads, texts the phone must send, cloud search usually do not. This entry is about drawing that disconnected capability boundary in advance. It is not about handoff animation, and not about how watch and phone divide labor while connected.

Why it happens

While connected, the watch can throw hard compute and networking to the phone, and the UI looks as if everything taps through. Disconnect cuts that borrow. Controls that “would succeed” become “spin, then fail.” If failures look different—some grey out, some time out, some go silent—people cannot form a model of “what this watch can do alone,” and will gamble when it matters (outside a door, on a track). A predefined standalone set reverses the model: the default-usable set keeps the same look and the same path after disconnect; anything off the set is marked “needs the phone” in one shared way, before a tap. The set must also be testable: airplane mode or the phone powered off, every item on the list still completes its main path.

Where it stops holding

A cellular watch splits “away from the phone” from “away from the network.” Without the phone but with cellular, some messaging can remain; search may still die. The list has to be three columns—no phone / no network / neither—not a single “offline.” Law and payment networks will turn near-field off in some regions; the standalone set is not one global table. During sport, GNSS may run while map tiles were never downloaded: the track can be logged, the road cannot be read. That is half-standalone and should be written “log yes, navigate no,” not marked as full navigation. User-downloadable packs (playlists, map regions) make the set depend on a personal library. The product must say “standalone only if downloaded,” and mark that before the download is missing.

Applying it

• Write three columns: still works without the phone, still works without the network, requires the phone. Accept each column on real tasks, not on an API permission sheet.
• Entries not in the standalone set become untappable after disconnect, with one line “needs the phone.” Do not leave the original button to hit a timeout.
• Functions in the standalone set must not pop “continue on the phone” after disconnect; that path is gone, and the prompt sends people to an empty pocket.
• Verify by powering the phone off or using airplane mode and walking the main path of every listed item. On-list items must succeed once; off-list items must declare the dependency before a tap. Any item that fails only after disconnect, or any standalone function that calls the phone back, means the list was not defined in advance.

Related

• Within the group: K4.07.1 The watch takes glances and light confirms; the phone takes deep work and heavy input · K4.07.2 Handoff should fire on task complexity, not a fixed rule · K4.07.3 After handoff the watch must show that it has already transferred
• Adjacent: K8.05 Pairing and Discovery · K8.03 Division of Capability across Devices · K4.08 Battery Constraints on Interaction Frequency
• Search terms: standalone watch · disconnected capability · companion independence