Adding Android to a HealthKit app

Adding Android to a HealthKit app

You built on Apple HealthKit, and now you need Android coverage. Here is the move: HealthKit is iOS-only and lives on-device, so there is no cloud API to point at Android. The Android counterpart is Health Connect — also an on-device store with its own permission model — and there is no single official cross-platform SDK that speaks both. So this is a real re-integration: you either build two native integrations behind your own normalization layer, or adopt an aggregator that abstracts both. The single biggest gotcha is that the two platforms are not equivalent — different data-type names, units, permission models, and background-sync behavior — so "support both" always means a mapping layer, not a flag flip.

What actually changes

Both stores are on-device, which is the one thing that stays the same. Everything around the data shape and permissions differs. Read the platform-by-platform breakdown in Apple HealthKit vs Google Health Connect; the table below is just the migration-relevant delta.

A note on that denied-read behavior: HealthKit returns empty data rather than an authorization error, so you cannot infer a user's health status from permission state, and empty results do not necessarily mean "no permission." Verify the current behavior in Apple's docs before you build logic around it.

Data-type parity and gaps

Core types overlap and map reasonably: steps, distance, heart rate, active/total calories, sleep sessions, weight, and workouts/exercise all have a counterpart on each platform. The edges are where you get hurt — naming, units, granularity, and which types each platform even defines diverge. Do not promise field-for-field parity to yourself or your users; build an explicit mapping table and flag every type that does not cleanly correspond. Verify each data type, unit, and granularity against the live docs, because these lists change.

The architecture decision: native vs aggregator

This is the call to make up front, because it shapes everything after it.

• Per-platform native — most control, no third-party dependency or recurring cost, but you build and maintain two integrations, two permission flows, two sync paths, and your own normalization schema.
• Aggregator / cross-platform layer — one integration; the provider runs an on-device SDK covering both HealthKit and Health Connect, normalizes the data, handles background sync, and delivers to your backend via API/webhooks. Trade-offs are cost, trusting a third party with the data flow, and coverage limits. Good fit when you want one backend contract.

There is no first-party Apple/Google product that does this. Community wrappers exist (for example Flutter and Kotlin Multiplatform libraries), but none is an official cross-platform SDK, and community libraries can lag OS changes — verify maintenance status before you depend on one. For the shortlist of managed options, see HealthKit alternatives.

The migration, step by step

1. Inventory your HealthKit usage. List every read/write type, its units, and everywhere you rely on background delivery via HKObserverQuery. This inventory is the map for everything below.
2. Decide native vs aggregator. Choose based on control versus speed and maintenance, and on whether you want one unified backend contract. This decision determines how much of the next steps you build yourself.
3. Map HealthKit types to Health Connect record types. Build a field-by-field table, normalizing names and units, and flag every non-parity type. Verify each mapping against the current Health Connect data-types docs.
4. Implement the Android read/sync path. Add the Health Connect client, declare paired READ/WRITE manifest permissions, and add history/background-read permissions if you need them. Remember Health Connect has no server endpoint — you sync results to your backend yourself.
5. Build a normalization layer. Have both platforms feed one internal schema so the rest of your app does not care which OS the data came from — or let the aggregator own this layer for you.
6. Implement both permission flows. Wire HealthKit's per-type sheet (with the "denied equals empty, not error" caveat) and Health Connect's paired READ/WRITE grants, plus background sync on each side.
7. Test the permission matrices on both platforms. Exercise granted, partial, and denied states, and validate unit and timezone consistency across platforms. Then ship Android alongside iOS, monitor parity, and iterate on the mapping.

Gotchas and how to keep users connected

• Neither store is a backend API. For both HealthKit and Health Connect, you read on the device and sync to your own server. There is no server-to-server read on either platform.
• Permissions do not carry over — there is nothing to carry. These are separate OS-level grants on separate devices. Android users grant Health Connect permissions fresh; that is expected, not a regression.
• The denied-read trap on iOS. Because HealthKit returns empty data instead of an error, absent data can mean "no permission" or "no data." Handle both, and do not build health inferences on permission state.
• Background sync is per-platform. HKObserverQuery on iOS and Health Connect's background-read permission on Android are two separate implementations to build and monitor.
• Community libraries lag. A cross-platform wrapper can fall behind OS changes; verify its maintenance status before depending on it.

Honest close

Adding Android is a genuine second integration plus a normalization layer, not a port — budget for two permission flows, two sync paths, and an ongoing mapping table you will revisit as both platforms evolve. Going native gives you control and no recurring cost at the price of maintenance; an aggregator trades cost and data-flow trust for one integration. Whichever you pick, verify current HealthKit and Health Connect docs before you build, since data types, permissions, and library support all shift over time.