The most useful sentence in the documentation is a prohibition. Do not call `isReachable()` as a preflight for a request that already has a fallback: reachability can change after the check, and its first value during a cold start may still be unknown [18]. Send the message and let `replyFailed()` select the replicated state [18]. Failure is an ordinary branch, because the other side may be asleep, out of range, or running an older build that does not know the message path [17].
Three transports exist because a watch spends much of its life asleep [23][1]. `putData()` is for state that should converge when the watch next wakes [13]. Each data path holds only the latest value, so two rapid writes can arrive as one update, which is correct for a step count and wrong for a queue of events [14]. `sendMessage()` assumes both applications are awake and the caller needs an answer now [16]. `transferFile()` carries files and large payloads that can arrive later [19].
The platform split is where the engineering shows. Wear OS reuses the existing Android port [11]. watchOS gets a separate Core Graphics renderer, because it has no UIKit view hierarchy, no OpenGL ES and no Metal [11], and the runtime sits inside a SwiftUI shell running its own ParparVM translation rooted at the watch entry point [12]. That is a second rendering path and a second translation root in one repository, which is where I would put the test budget.
The tooling anticipates the obvious mistake. Watch > Launch Watch App runs the watch beside the phone in separate processes connected through the desktop bridge, so `sendMessage()` and `putData()` take the same asynchronous route the code expects on a device [20]. Both processes are up in that configuration, so I would not count the bridge as coverage for the `replyFailed()` branch. Four skins ship: Apple Watch 41 mm and 45 mm, plus round and square Wear [21][2]. Testing the round skin even when the first target is Apple Watch catches layouts that depend on rectangular corners [21].
For the UI itself, `CN.isWatch()` selects the form-factor-specific branch, and a `watch` theme override changes styling without forking the rest of the theme [22].
What would have to be true for this to transfer to your project: you already ship a Codename One phone application [1], and the watch screen you want is a separate application with its own startup sequence rather than another form in the phone process [25]. On the packaging gap, the build logs that no companion Wear artifact was produced instead of quietly implying otherwise [7]. A build that reports what it did not make is rarer than it should be.
