# Platform feasibility

Status: engineering assessment, researched 2026-09-16. This document does not certify hardware behavior or App Store acceptance. The repository scaffold is not a working TV remote yet.

## Product promise and its boundary

Wristivo is a proposed iPhone remote with an Apple Watch companion that turns deliberate wrist movements into TV navigation commands. The baseline requires a reachable paired iPhone and an active watch app. It does **not** promise continuous gesture recognition while the watch app is suspended, operation with the phone absent, or universal compatibility with every Tizen television.

The highest-risk unknown is whether real-device foreground sessions and phone wake-up latency feel sufficiently convenient for watching television. Resolve that with a small hardware prototype before investing in full screens or marketing. If the experience is unacceptable, retain a conventional watch remote and revisit the product promise rather than hiding platform restrictions.

## Verified platform facts and engineering decisions

| Topic | Verified from Apple documentation | Project decision / remaining evidence |
| --- | --- | --- |
| Motion input | Core Motion supplies accelerometer, gyroscope, and processed device-motion data; hardware/service availability must be checked. [Core Motion](https://developer.apple.com/documentation/coremotion/), [CMMotionManager](https://developer.apple.com/documentation/coremotion/cmmotionmanager) | Use public device-motion APIs, classify locally on watch, and prove recognition using physical watches. Sensor APIs do not themselves recognize a TV-navigation gesture. |
| Runtime | Ordinary watch apps can become suspended after the user lowers their wrist. Extended runtime categories serve specific activities. [Extended runtime](https://developer.apple.com/documentation/watchkit/using-extended-runtime-sessions) | Only arm while active. Immediately disarm on inactive/background transitions. Do not claim always-on or screen-off control. Never start a fake workout, audio stream, location session, or health session to keep this remote alive. |
| Direct watch WebSocket | Apple classifies `URLSessionWebSocketTask`, Network framework connections, and Bonjour browsing as low-level watch networking with restricted supported uses. Ordinary HTTP(S) requests are a different category. [TN3135](https://developer.apple.com/documentation/technotes/tn3135-low-level-networking-on-watchos), [WebSocket task](https://developer.apple.com/documentation/foundation/urlsessionwebsockettask) | No direct watch-to-TV WebSocket adapter in the baseline. API availability or success under a debugger is not evidence of a supported production path. |
| Phone relay | Activated Watch Connectivity sessions support immediate messages to reachable counterparts. A message from an active watch app can wake its companion iOS app in the background; messages can still fail. [sendMessage](https://developer.apple.com/documentation/watchconnectivity/wcsession/sendmessage(_:replyhandler:errorhandler:)), [reachability](https://developer.apple.com/documentation/watchconnectivity/wcsession/isreachable) | Watch emits commands; iPhone owns TV connection, credentials, and pairing. A wake-up is not a guarantee of an indefinitely resident phone socket. Test reconnect and deadline behavior with the phone locked and suspended. |
| Deferred transfer | Watch Connectivity also offers queued background transfers and latest-state synchronization. [WCSession](https://developer.apple.com/documentation/watchconnectivity/wcsession) | Use latest-state synchronization for selected TV and preferences. Never put button presses in deferred background transfers: delayed navigation is incorrect behavior. |
| System double tap | On supported Apple Watch hardware, watchOS 11+ lets a visible button-like control be designated the scene's primary action. [Double tap](https://developer.apple.com/documentation/watchos-apps/enabling-double-tap) | Optional Select enhancement only. Do not claim access to arbitrary finger-pinch recognition or depend on double tap on all supported watches. |
| Accessibility | AssistiveTouch can navigate ordinary accessible watch interfaces through system-managed hand gestures. [Accessible watchOS experiences](https://developer.apple.com/videos/play/wwdc2021/10223/), [gesture design](https://developer.apple.com/design/human-interface-guidelines/gestures/) | Keep native accessible buttons for every action. AssistiveTouch is a user-controlled alternative, not an app-owned gesture recognizer or an entitlement to background execution. |

## Baseline data path

```text
Apple Watch active app
  -> Core Motion samples
  -> local calibrated classifier and command gate
  -> WatchConnectivity immediate message
  -> iPhone validates command, target, freshness and duplicate status
  -> iPhone TV transport
  -> compatible TV
```

The iPhone returns a correlated result. A transport write is not proof that the TV visibly executed a command. UI and logs must distinguish local recognition, relay acceptance, transport submission, and failure; claim device execution only if the TV protocol provides adequate confirmation. Use the repository's shared contracts rather than creating another wire format.

TV transport compatibility, pairing consent, token storage, and TLS handling are separate integration gates. No motion code may embed Samsung protocol details. No TV credentials or raw motion history need to cross the watch relay.

## Session and lifecycle rules

1. Watch launches into a disarmed state. Show selected TV and phone availability.
2. User opens gesture mode, calibrates, and explicitly arms. Show persistent armed status and a large Stop control.
3. Stop sampling and invalidate pending candidates on scene inactivity, lost relay reachability, target change, sensor failure, or user stop.
4. A foreground return never replays old commands or silently re-arms. Require explicit resumption and a neutral pose.
5. If the phone cannot process a command before its contract deadline, reject it. Do not accumulate gestures while reconnecting.
6. Keep iPhone setup and local-network permission interactions in the iPhone UI. During normal watch operation, explain phone or TV disconnection clearly.

An Always On display is not a promise of continuous application execution. Hardware trials must launch from the watch Home Screen without Xcode attached: Apple explicitly notes that debugging changes suspension behavior. [Watch Connectivity sample](https://developer.apple.com/documentation/watchconnectivity/transferring-data-with-watch-connectivity)

## Physical-device feasibility gate

Record watch model, wrist/crown orientation, watchOS version, iPhone model/iOS, TV model/year/firmware, Wi-Fi topology, build commit, and whether a debugger is attached. Start with the user's devices; add at least one watch without system double tap and another TV generation before broad compatibility claims.

Initial user-reported hardware is Apple Watch Ultra 2 and iPhone 13 Pro Max, each on a recently released/latest OS whose exact version must be recorded from Settings. The TV may be a Samsung QA85Q8FAAUXZN, 85-inch non-OLED; that model identification is explicitly unconfirmed. Read the model code and firmware from the TV's Settings before choosing a compatibility fixture. The integration owner verified Xcode 27, Swift 6.4, and SDK 27 on the development Mac. **No physical-device or TV behavior has been tested.**

| Experiment | Proposed acceptance criterion; not a measured result |
| --- | --- |
| Active gesture-to-TV navigation | Recognition precision >= 98%, recall >= 90% per direction; measure separately by wrist/orientation. Detailed trial procedure is in `GESTURE-SPEC.md`. |
| Responsive control | Warm-path motion completion to visible TV action p95 <= 700 ms. Record classifier, relay, and transport timings separately. |
| Locked phone, background phone, cold reconnect | Each case documented with latency and success rate. No stale command may execute after its deadline. If reliability fails, disclose phone requirements and fix or narrow scope before release. |
| Lowered wrist, watch face, notification interruption, app switch | Sampling/dispatch cease on inactivity; zero old commands on resume. Measure actual usable session length. |
| Connection loss and retries | Zero automatic duplicate presses; no command queue drains on reconnection. Result ambiguity must not trigger a blind resend. |
| Battery | Measure a 30-minute repeated-use script and an idle/disarmed control run on each watch. Proposed target: <= 10 percentage points incremental battery loss per hour; report actual results and revise before advertising endurance. |
| Accessibility | Every remote action remains reachable with touch and VoiceOver; motion can be disabled. Test AssistiveTouch behavior with the system settings the user chooses. |

Do not equate a simulator, mock TV, or unit-test pass with completion of this gate. Phone relay wake-up and wrist suspension require physical hardware.

## Alternatives and change control

Direct watch-to-TV WebSocket is rejected for the baseline due to documented networking restrictions. A future supported HTTPS remote service would be a separate architecture with its own latency, authentication, privacy, provider-contract, and internet-dependency review; do not silently substitute a cloud service. Request an architecture decision before adding one.

Recheck cited Apple documents at the hardware spike and before submission. If a future OS introduces an applicable public remote-control runtime or network capability, evaluate it explicitly and keep the current fallback until real devices prove it.