Wear OS Fitness App Anatomy: Standalone or Not (2026)

A Wear OS fitness app is not the phone app rendered small. Before any of the interesting work — an exercise session, a tile, a heart rate readout — there is one architectural decision that determines who can even install the thing: is this app standalone or not? It is expressed as a single manifest value, and Google checks the claim.

The two definitions, as Google writes them#

Google's documentation defines a standalone app as "a completely independent app that doesn't require a phone app for core features. Although 'Open on phone' prompts are acceptable, the app must provide alternative means for users to complete an app function—such as a shortlink or QR code—without depending on a tethered phone."

A non-standalone app is "a dependent app that requires an app on a phone or another device for core features… when they can't easily provide an alternative means—such as a QR code or shortlink—for completing a core app function, such as authentication."

Read the standalone definition closely, because the concession in the middle is the part teams miss. An "Open on phone" prompt does not disqualify you. The bar is that a user with no reachable phone app still has a route through — a shortlink, a QR code, something. Standalone is about the absence of a dead end, not the absence of a phone.

One meta-data value in the manifest#

The declaration is a meta-data entry named com.google.android.wearable.standalone, set to true or false in the watch app's manifest. That is the whole mechanism, which is exactly why it gets set carelessly.

Google also documents a detail that surprises people who assume the platform enforces the dependency they declared: "Even if the value of com.google.android.wearable.standalone is false, the watch app can be installed before the phone app is installed."

So false is a description of your app's needs, not an install-order guarantee. Your watch app can and will boot on a wrist with nothing on the other end. It needs a coherent first-run state for that case — an explanation of what is missing and a way to fix it — whichever value you declared.

What the Play Store does with the value#

This is where the flag stops being metadata and starts being distribution. Google's documentation states that "Google validates the accuracy of an app's standalone status during app serving. This value affects the visibility of apps within the Play Store on untethered devices… Non-standalone apps—as well as apps that developers incorrectly designate as 'standalone'—aren't available to users on these untethered devices."

Both directions of error cost you the same users:

The flag is a claim that gets validated, so the useful question is not "which value do we want" but "which claim can we actually support". We have not verified how that validation is performed or what a developer sees when it fails; confirm the current behavior in Play Console documentation before you plan around it.

The iOS blind spot#

A Wear OS watch can be paired to an iPhone, and that pairing removes a capability check you would otherwise reach for. Google's documentation is explicit: "From Wear OS, you cannot programmatically determine whether your phone app is installed on an iOS device. As a best practice, provide a mechanism to the user to manually trigger the opening of the App Store."

The design consequence is that you cannot gate the watch UI on a question the platform will not answer. Show the manual affordance — a control the user taps to open the App Store — rather than branching on a detection you do not have. The same pairing also takes away the phone transport entirely, which is covered in Wear OS phone sync and is the single most consequential fact on this cluster.

Authentication is what forces the question#

Most of a fitness app can live on the wrist. The exercise loop runs through Health Services on the watch itself (Wear OS exercise tracking). A glanceable surface is local (Wear OS tiles). Local history is a database on the watch. Network calls work from the watch as they do from a phone.

Sign-in is the exception, and it is the one Google's own definition reaches for as its example of a core function that makes an app dependent. This is our judgement rather than a documented rule: decide the authentication story first, because it decides the flag, and the flag decides who can install you.

The routes we see teams take, all of them requiring your own testing on real hardware:

• A code the user types on the watch. Painful on a wrist keyboard, workable with voice input, and it keeps you standalone.
• A QR code or shortlink shown on the watch. Named in Google's definitions as an acceptable alternative means, and it is the cheapest way to stay standalone without a wrist keyboard.
• A device-code style flow. The watch displays a short code, the user completes sign-in on any browser, the watch polls your backend. Also standalone, because nothing depends on a paired phone.
• "Open on phone" as the only path. This is what makes an app non-standalone, and it is a legitimate choice — but make it deliberately, knowing it removes you from untethered devices.

The rest of the app#

Once the shape is settled, the pieces are: the exercise session and its data, keeping the app visible while a workout runs (owned by Wear OS Ongoing Activity), glanceable surfaces (tiles here, widgets and complications on the engagement side), and whatever sensors the watch does not contain, which come in over BLE the same way they would on a phone.

One platform rule that catches Wear OS teams because they read it as phone-only: on Android 13 and later, POST_NOTIFICATIONS is a runtime permission for Android apps, and a Wear OS app is an Android app. If your workout experience depends on a notification appearing, it depends on a permission the user can decline.

For how the same decision looks on the other platform, watch platform differences sets the two side by side.