A case against TN3135 WatchOS restrictions (NWPathMonitor)

REF: TN3135

Context:

1. Stand alone watch app

2. Target platform is cellular watch

3. Phone likely (90%) out of range in a different location (although this applies equally to watch+phone too)

User story:

As a water & wind sports enthusiast who is either in-shore, near-shore or off-shore

I want to receive near-real-time wind reports on my wrist

so that I can determine ...(many varieties of facts)

My Case for lifting restrictions on NWPathMonitor, NWPath, NWPath.Status

What this is about:

1. Proactive UX (enlightening) vs. Reactive UX (disappointing)
2. Reducing unnecessary code execution proactively
3. Exactly the same purpose the tiny red x at the top center of the Watch screen serves (notifies me that the watch is offline -- probably using NWPath.Status of .unsatisfied)

What this is NOT about

1. Preflighting requests
2. UI design (although there is a UI component associated with UX - like the tiny red x ...)
3. Establishing low level connections

Watch App End User Scenario

Water & Wind sports enthusiasts are frequently in and out of cellular range.

As a kiteboarding enthusiast I am relating my personal experience. The phone is in the vehicle in the parking lot > 100 yards away while I'm standing on the beach (before I get into the water).

On shore or just off shore my watch likely has a solid connection. When 100 yards off shore watch has a decently but tenuous connection. While at 200 yards off shore watch has no connection at all.

Developer's Case

Current REACTIVE solution

My current watch app is forced to be reactive by attempting a URLSession request and capturing one of the plethora of URLError error conditions.

This action, of course, is activated through a user interaction workflow:

User interaction --> create URL --> use URLSession --> capture URLError --> determine failure cause --> notify user network data cannot be retrieved

Optimal PROACTIVE solution

Provide a simple indicator to the end user that the data cannot be retrieved. The reason is not relevant to the end user, but they know their interaction with the app is unnecessary. The app's UX has been improved by proactively precluding an unnecessary interaction and precluding unecessary code execution behind the scenes.

NWPath.Status = .unsatisfied --> UI shows "no network" type indicator --> (no user interaction - no backend requests - no code execution) --> NWPath.Status = .satisfied --> UI shows nominal status --> end user interacts normally

Rationale

Using NWPath.Status allows us as developers to fulfill some basic tenets of the Human Interface Guidelines associated with Providing Feedback

Specifically, the overview states we should communicate:

• The current status of something
• A warning about an action that can have negative consequences

And quoting about my specific use case, the guidelines continue:

... it often works well to display status information in a passive way so that people can view it when they need it.

Consider integrating status feedback into your interface.

Show people when a command can’t be carried out and help them understand why.

And finally, the guideline specifically calls out the WatchOS experience I am attempting to avoid. By proactively providing feedback we can prevent the reactive "touch --> wait & see --> then disappoint with no connection" approach.

Final Thoughts

I realize I am naive about the behind the scenes with this API. I realize that this is likely not the intended use of this API. But as a developer, I also realize users of our stuff often use it in ways we never intended.

Please allow these API features on WatchOS