On-Device vs Cloud Health Data: What's the Difference?

Health and fitness data reaches your app by one of three routes, and picking among them is an architecture decision you make early. On-device stores (Apple HealthKit, Google Health Connect) keep data on the user's phone under an OS-granted permission — there is no vendor server you can query with a token. Cloud / OAuth APIs (Fitbit, Strava, Oura, Whoop, Garmin) keep data on the provider's servers, and your backend fetches it server-to-server using OAuth tokens. Aggregators (Terra, Junction, Rook, Spike) are a single integration that fronts both of the above.

The trade-off in one line: on-device is privacy-forward and rich in first-party phone data but device-bound and platform-locked; cloud/OAuth gives you always-on server access across platforms but only for data the provider holds; aggregators buy you reach across both at the cost of a recurring fee and a third party in the data path.

The three shapes, in more depth

On-device platform stores

Apple HealthKit (iOS) and Google Health Connect (Android) are the two OS-level health stores. The operating system holds an encrypted local database on the phone. Your app requests permission per data type, and the user grants or denies it in a system dialog. You then read the data on the device. If you need it server-side, your own app uploads it to your backend — the platform runs no cloud aggregation service and exposes no server endpoint that returns a user's data in exchange for a token.

Three defining traits:

• OS permission, not OAuth — the user authorizes in a system dialog, per data type. There is no token, no refresh cycle, and no server to present a token to. (HealthKit permissions are also privacy-preserving: an app can be told nothing about read denials, and users can revoke individual data types silently.)
• Platform-locked — HealthKit is Apple-only; Health Connect is Android-only. There is no cross-platform version of either.
• No server — access requires your app to be installed and running on that specific device.

One note on the Android side: Google Health Connect is now the Android standard, and from Android 14 it ships as part of the OS. It stores data on-device, unlike the older cloud-based Google Fit, whose REST/Android APIs stopped new signups on 1 May 2024 and are being wound down toward end-of-service in late 2026 (verify the exact dates).

Cloud / OAuth APIs

Fitbit, Strava, Oura, Whoop, and Garmin store the user's data on their own servers. The user authorizes your app through OAuth — a consent flow where they log in at the provider and approve specific scopes, and your backend receives access and refresh tokens. Your server then calls the provider's REST API with the access token and can keep syncing (via polling or webhooks) even when the phone app is not open. Because the data and the auth both live in the cloud, this route is inherently cross-platform and always-on.

Aggregators

An aggregator is one integration that connects to many of the above sources on your behalf and returns their data in one normalized schema. It orchestrates the OAuth flows for cloud providers and, via mobile SDKs, can also read the on-device stores — then delivers everything to a single webhook. You trade a recurring vendor fee (and a third party in your data path, which raises HIPAA/BAA questions) for skipping the per-provider maintenance burden.

When each route applies

• Use on-device when you want the richest first-party phone data — Apple Watch metrics that only surface in HealthKit, for example — you have a native app on that platform, and you are comfortable that access is device-bound and per-platform.
• Use cloud / OAuth when you need server-side, always-on access independent of any one phone, or when the data simply lives in a provider's cloud (Strava activities, Fitbit account history).
• Use an aggregator when you want many sources — on-device and cloud, across brands — through one normalized integration and you would rather pay than build and maintain N connections.

Comparison at a glance

A concrete example

An iOS app reads today's workouts straight from HealthKit on the phone, with no server involved. A web dashboard that must show a user's runs whether or not their phone is nearby uses Strava's cloud OAuth API instead. An app that wants both — first-party phone metrics and cloud activity, across brands — reaches for an aggregator so it maintains one integration rather than many.

Where this fits

This page defines the three routes. To go deeper on the on-device pair, compare Apple HealthKit vs Google Health Connect, and to actually wire up the Apple side, follow the HealthKit integration guide. The cloud route runs on tokens — see what OAuth for health data is — and the aggregator route is covered in health-data aggregator APIs.

This is general product and engineering information, not medical advice.