watchOS vs Wear OS: Building the App That Runs on the Watch

Two teams can write the same watch product spec and end up with almost nothing in common. The divergence is not syntax. It is who owns the workout, what keeps the process running once the wrist drops, what the glanceable surface may be, and — the one that catches teams late — which phone is on the other end.

Who owns the exercise lifecycle#

On watchOS the lifecycle belongs to HealthKit. Apple documents HKWorkoutSession as "a session that tracks a person's workout", available since watchOS 2.0. The session declares to the system that an activity is happening; HKLiveWorkoutBuilder — "a builder object that constructs a workout incrementally based on live data from an active workout session" — turns it into a stored sample during the session rather than afterwards, exposing its session, a data source that supplies live data automatically, and an elapsed time Apple documents as including pauses.

One documented constraint shapes everything above it: "Apple Watch runs one workout session at a time. If a second workout starts while your workout is running, your session ends." Your app is a guest in a single global slot.

On Wear OS 3 and later the equivalent authority is Health Services, a platform service sitting between apps and the sensors and algorithms below them. ExerciseClient is where a workout lives: managing workouts, setting exercise goals, listening for exercise state updates and delivering rapid data updates during an active exercise, over metrics Google lists as heart rate, distance, calories, elevation, floors, speed and pace. PassiveMonitoringClient covers the other case, "suited for long-lived experiences where data updates are relatively infrequent".

The shapes rhyme; the ownership does not. On watchOS the workout session is also your right to keep running; on Wear OS that is a separate API.

What keeps the app alive#

A watchOS workout session supports background execution while the device is locked, mirrors the workout to a companion iPhone, and can drive Live Activities and Siri control. Everything that is not a workout takes a different road. WKExtendedRuntimeSession is Apple's "session that continues to run your app after the user has stopped interacting" — it can keep talking to Bluetooth devices, process data, or play sounds and haptics after the screen turns off. The catch is the taxonomy: "Each app can support a single type of extended runtime session: self care, mindfulness, physical therapy, or smart alarm", selected by enabling the matching Background Modes capability. Workout is not on that list, and the session carries an expirationDate. A physical-therapy or mindfulness product therefore takes a structurally different path from a training app.

On Wear OS, Health Services is also the power story: Google says it "conserves battery by using sensor configurations from Health Services that are optimized for power efficiency" and "verifies data consistency across all applications on the same device by using standardized platform computations". Staying visible on screen is a separate mechanism, covered in Wear OS ongoing activity.

Side by side#

The glanceable surface is not the same surface#

Apple's WidgetKit builds complications for the watch face and the Smart Stack, and the update model is a timeline of data you hand to WidgetKit, optionally pushed over APNs. The engagement framing lives in widgets and complications.

Wear OS tiles are a different animal. Google describes them as "quick access to the information and actions users need to get things done", revealed by a swipe on the watch face, and built declaratively with "Jetpack's protolayout and tiles libraries" rather than Compose or Views. They render in a separate, remote environment, so data loading inside them takes its own approach. And the constraint that decides the design: "Tiles themselves cannot be scrolled." A tile is a glance with a tap target, not a screen. See Wear OS tiles.

Pairing is where the asymmetry bites#

An Apple Watch pairs with an iPhone. A Wear OS watch may be paired with an Android phone or an iOS one, and that fact deletes an API. Google documents that the Data Layer "can send messages and synchronize data only with phones that run Android or Wear OS watches. If a Wear OS device is paired with an iOS device, the Data Layer API won't work" — and draws the conclusion itself: "don't use the Data Layer API as the primary way to communicate with a network." Do network calls from the watch as you would from a phone. Google also documents that from Wear OS you cannot programmatically determine whether your phone app is installed on an iOS device, and advises a manual way for the user to open the App Store. Wear OS phone sync has it in detail.

Distribution has a switch watchOS does not have#

Wear OS apps declare com.google.android.wearable.standalone as manifest meta-data. A standalone app is, in Google's words, "a completely independent app that doesn't require a phone app for core features"; a non-standalone one depends on a phone app for a core feature such as authentication. That declaration reaches users: "Google validates the accuracy of an app's standalone status during app serving", it "affects the visibility of apps within the Play Store on untethered devices", and non-standalone apps — plus apps incorrectly designated standalone — are not available on those devices. Either way, the watch app can be installed first.

Sequencing, labelled as judgement#

None of what follows is documentation. It is our judgement, and it claims nothing about market share.

Build first for the platform your phone app already serves, the platform's native way rather than the way that ports. The reason is mechanical: the exercise lifecycle, the keep-alive grant and the glanceable surface are three separate contracts on each side, and none maps one-to-one. What travels is your domain model, your scoring and your sync protocol. What does not travel is nearly everything the watch does.

If you go to Wear OS second, settle the pairing question first. An app that assumes an Android phone is a different product from one that must also work on an iOS-paired watch, and the standalone declaration makes that a distribution decision rather than only an architecture one. Battery decides scope on both platforms — see watch app battery — and neither platform's real behavior is knowable without testing on hardware.