AppMatic Tech integrates Apple HealthKit, Android Health Connect, and the Google Health API into wearable companion apps built with Swift, Kotlin, Flutter, and Laravel back ends, choosing the platform by where the data must live. The Ahmedabad, India team has shipped 330+ products, including six BLE device integrations.
Teams often treat these three as interchangeable "health APIs". They are not: two are on-device stores and one is a cloud API, and picking the wrong one means a server that cannot read data or a phone app that cannot work offline.
Key takeaways
| Point | Detail |
|---|---|
| HealthKit is iOS only | An on-device store, with no cloud access to a user's data. |
| Health Connect is Android only | An on-device store shared between apps, with per-type permissions. |
| Google Health API is cloud | The Fitbit Web API rebuilt on Google infrastructure, using Google OAuth 2.0. |
| Legacy APIs are ending | The Fitbit Web API is being deprecated in September 2026, and Google Fit APIs are supported until the end of 2026. |
| Plan for reconnection | OAuth changes mean users reconnect accounts during migration. |
How do the three platforms compare?
| Apple HealthKit | Android Health Connect | Google Health API | |
|---|---|---|---|
| Platform | iOS and watchOS | Android | Cloud, any server or web app |
| Where data lives | On the device | On the device | Google cloud |
| Access from a back end | No, the app must upload | No, the app must upload | Yes, with user OAuth consent |
| Sign-in | Device permission prompt | Device permission prompt | Google OAuth 2.0 |
| Typical data | Steps, heart rate, sleep, workouts | Steps, heart rate, sleep, exercise | Fitbit and Google device data |
| Works offline | Yes | Yes | No |
A server can never read a user's HealthKit or Health Connect data directly. The app reads it on the phone and uploads what the product needs, with the user's permission.
Which platform fits which product?
- A BLE wearable with its own app. The device sends readings to the phone. The app stores them locally and writes selected types to HealthKit and Health Connect so users see them beside other apps. No Google cloud API is needed.
- An app that enriches insights with phone data. The app reads steps or sleep from HealthKit or Health Connect to combine with device readings. Only on-device stores are involved.
- A coaching or analytics platform reading Fitbit data. A back end needs data without the phone open, which requires the Google Health API and Google OAuth 2.0.
- A multi-brand platform. The app reads on-device stores on each OS and adds cloud APIs, such as Google's or a vendor's, for devices that sync only to their own cloud.
Google's migration guidance splits the choice in the same way: Health Connect for mobile-first apps reading aggregated on-device data, and the Google Health API for fitness tracker companion apps and web platforms that need cloud access.
How do permissions differ?
All three use granular, per-data-type consent, and an app must work when users decline some types.
- HealthKit asks separately for read and write per type. For privacy, the system does not tell an app whether read permission was denied, so an empty result can mean "no data" or "no permission", and the UI must handle both.
- Health Connect shows a permission screen listing requested types, and by default apps can read only data recorded after the user grants access plus a limited historical window, so the first sync after install may look sparse.
- Google Health API uses OAuth scopes per data type, with consent reviewed by Google for sensitive scopes.
AppMatic Tech writes a permission matrix at design time that maps each product feature to the data types it needs, and designs a degraded state for every feature when a type is declined.
How should reads and writes be designed?
Two rules prevent most production bugs.
- Pick a source of truth per data type. If the app writes heart rate to Health Connect and later reads aggregated heart rate back, it counts its own records again. Tag written records with the app's source and exclude that source on read, or read only from the device store.
- Treat the phone as a buffer, not an archive. Store every reading locally first, sync to the platform and back end later, and make uploads idempotent so a retry cannot create duplicates.
Background delivery also differs. iOS lets an app register for background updates to specific types, while Android relies on scheduled work and, on newer releases, a background read permission, so freshness expectations must be set per platform.
What does migration from Fitbit and Google Fit involve?
| Legacy API | Status | Move to |
|---|---|---|
| Fitbit Web API | Being deprecated in September 2026 | Google Health API for cloud reads |
| Google Fit APIs | Supported until the end of 2026 | Health Connect on device, Google Health API in the cloud |
The migration checklist AppMatic Tech uses:
- Inventory every place the app and the back end call the old APIs, including forgotten scheduled jobs and analytics exports.
- Map each data type to its new equivalent and note gaps.
- Implement Google OAuth 2.0 and plan a reconnection prompt, because existing tokens do not carry over.
- Backfill history where the new API allows and tell users where it does not.
- Run old and new in parallel and compare totals before switching off the legacy path.
The migration context is also covered in wearable companion app development.
How should a cross-platform app structure the integration?
AppMatic Tech defines the product's own health data model first, then writes one adapter per platform that maps records into it. On Flutter, each adapter sits behind a platform channel or a maintained plugin, and on native builds each adapter is a Swift or Kotlin module behind the same interface. Business logic, trends, and AI insights read from the app's own model and never from a platform type directly, so adding a new source, such as a vendor cloud API, touches one module.
The BLE side of the same pipeline, including queueing, reconnection, and background capture, is covered in BLE background sync for wearables on iOS and Android and BLE mobile app development cost and timeline.
Health platform integration, the Google Health API migration, and AI coaching layers on wearable data are part of the wearable app development service, and regulated clinical use cases are handled under healthcare app development. Scoping starts at contact@appmatictech.com.
Sources
| Claim used in this article | Source |
|---|---|
| Legacy Fitbit Web API deprecated in September 2026 | Fitbit developer site |
| Google Health API uses Google OAuth 2.0 | Google Health API |
| Google Fit APIs supported until end of 2026; platform choice by app type | Android Developers, Google Fit migration guide |
| HealthKit on-device data store and authorization model | Apple Developer, HealthKit |
| Health Connect permissions and data access | Android Developers, Health Connect |
Frequently Asked Questions
- What is the difference between HealthKit and Health Connect?
- HealthKit is Apple's on-device health data store for iOS and watchOS, and Health Connect is Android's on-device equivalent. Both let apps read and write data types such as steps, heart rate, and sleep with per-type user permission. Neither is a cloud API, so a server-side integration needs a separate path such as the Google Health API or a vendor cloud.
- Do wearable apps need the Google Health API?
- Only when a back end or web platform must read Fitbit or Google device data in the cloud. Google's migration guidance recommends Health Connect for mobile-first apps reading on-device data and the Google Health API for companion apps and web platforms that need OAuth-based cloud access. The legacy Fitbit Web API is being deprecated in September 2026.
- Can one codebase handle HealthKit and Health Connect?
- Yes, with an abstraction layer. AppMatic Tech uses Flutter or a shared Kotlin and Swift interface that defines the app's own data model, then maps each platform's record types into it. The permission flows, available data types, and background behaviour still differ per platform and are tested separately.
- Why do wearable apps double count steps or heart rate?
- Double counting happens when an app writes its data to HealthKit or Health Connect and then reads aggregated totals back, counting its own records again. AppMatic Tech tags every written record with its source and excludes its own source identifier when reading, or chooses one platform as the source of truth for each data type.
- Does health platform integration add cost to a wearable app?
- Yes. Permission flows, two-way sync, account reconnection, and platform review are scoped as additions to a wearable companion build. AppMatic Tech prices wearable companion apps from $15,000 for a single-platform MVP, with health platform integration and the Google Health API migration quoted as separate line items in the scope.