How do on-watch workouts and health data, and networking directly or through the iPhone, work on watchOS?

Workouts are the watch’s flagship use of a long-running session. An app starts an HKWorkoutSession with an HKLiveWorkoutBuilder (the pair created from an HKHealthStore and an HKWorkoutConfiguration): the session keeps the app running in the foreground and the screen state managed while the workout is active, the builder collects samples (heart rate, active energy, distance) from the watch’s sensors with HKLiveWorkoutDataSource, delegates deliver live statistics for the UI, and ending the session and calling finishWorkout() saves an HKWorkout to HealthKit, where it appears in Fitness and syncs to the iPhone. WorkoutKit (watchOS 10) adds planned workouts (WorkoutPlan, custom intervals and goals, previewed and scheduled to the Workout app) and builds on the same session model. Related pieces: HKHealthStore authorization on the watch (the same per-type model as on iPhone, with the usage strings in the watch app), CMMotionManager and CMPedometer for motion data, HKObserverQuery with background delivery for non-workout data, an extended runtime session (categories such as mindfulness, self care and smart alarm) when you need foreground-like time without a workout, and Core Location for outdoor workouts (GPS on the watch). Constraints: a workout session requires the right capability and background mode (workout-processing), uses a lot of energy (sensors, screen), must handle interruptions (a phone call, a low-battery stop) and must save partial data safely, since the session can be ended by the system; stream results to the iPhone with Watch Connectivity or save to HealthKit and let it sync.

Networking on the watch. Since watchOS 6 an independent watch app can use URLSession directly: the watch uses Wi-Fi, cellular (cellular models) or the paired iPhone’s connection (Bluetooth proxy) as available, and the system picks the route; you cannot choose it, but you can set allowsConstrainedNetworkAccess and waiting for connectivity, and background URLSession tasks continue and wake the app when finished. Design for slow, intermittent and metered connectivity: small payloads (compact JSON or binary), caching with sensible freshness, timeouts and retries with backoff, and a clear offline state; avoid long-lived sockets (the app is suspended), and do not poll. Do not make the watch app depend on the iPhone for data unless it is a companion by design; for the paired iPhone path use Watch Connectivity as an accelerator (settings, a latest-state update) with a server as the source of truth. Authentication should work without typing: sign in on the iPhone and pass a token through the shared Keychain or Watch Connectivity (a short-lived token, never a password), or use a device code. Test on a real watch with and without the phone, on Wi-Fi only and on cellular, and in airplane mode with Wi-Fi back on, since the simulator’s networking hides these paths.