If your product measures anything about the body — heart rate, sleep, weight, activity, glucose, respiration — users expect the readings to appear alongside all their other health data. On iOS that means writing to HealthKit, the store behind the Health app. On Android it means Health Connect, which has replaced the older Google Fit APIs as the central health data layer. Integrating makes your product part of an ecosystem instead of an isolated island, and it is a genuine purchase consideration: buyers check for it before they order.
This article is educational only. Health data carries regulatory obligations that vary by product and market; consult qualified counsel and, where relevant, regulatory specialists for your specific device.
How the architecture fits together
The typical chain has three links: the device measures and transmits to your app, usually over Bluetooth Low Energy as described in BLE app development; your app writes the measurements into the platform health store on the phone; other apps read from that store with the user's permission.
One point that surprises many teams: HealthKit and Health Connect are local databases on the handset with a permission layer, not cloud services. They do not sync your data to your servers. If your product needs cloud storage, that is a separate channel you build and secure yourself.
Apple Health (HealthKit): what matters
- Granular, per-type permissions. The user approves each data type separately, and read and write separately. Your app must function when some permissions are denied — and Apple deliberately does not tell you whether a read permission was refused, so absence of data and absence of permission look identical. Design the UI so neither case looks like a bug.
- A fixed catalog of data types. Hundreds of types exist, from heart rate to blood glucose. If your metric is proprietary and no type fits, you either map it to the closest existing type or keep it only in your own app — there is no custom type you can publish to the store.
- Metadata and provenance. Write your device as the source, with timestamps and sample intervals, so users can tell your readings apart from a phone-estimated value.
- Strict store rules. Health data may not be used for advertising, a detailed privacy policy is mandatory, and requesting health permissions without a clear user-facing purpose gets an app rejected. See publishing an app to the app stores.
Android: Health Connect, not Google Fit
The Android picture has settled. Health Connect is the central interface for health and fitness data, ships built into current devices, and the legacy Google Fit APIs are being retired. A new app should be built on Health Connect and should only consider Fit if you must support very old handsets. The model closely resembles HealthKit — a local store with per-type permissions — which makes it practical to design one abstraction layer over both platforms.
That abstraction layer is still platform-specific code underneath, even in a cross-platform app. Budget for it: the health-store bridge is one of the areas where cross-platform frameworks need native work, a tradeoff covered in native vs cross-platform app development.
Product decisions to make before writing code
- What do you write, and what do you read? Writing your own measurements is almost always correct. Reading other sources should be limited to features you actually ship — every additional permission increases user friction and review scrutiny.
- Who is the source of truth? Decide explicitly: your cloud or the phone's health store. Writing to both without a defined authority produces duplicate and conflicting records, the most common complaint in reviews of health accessories.
- What happens offline? Devices buffer readings when the phone is away. Define how backfilled samples are timestamped so a week of catch-up data does not appear as a spike today.
- How do you handle duplicates? If the user wears a watch and your device, both may write the same metric. Use stable sample identifiers so a re-sync overwrites rather than duplicates.
- Do you actually need it at launch? Integration adds testing surface. Many products ship their own display first and add platform integration in a later release.
Privacy and regulatory context
Health data is a sensitive category almost everywhere. Collect the minimum, state clearly what leaves the device, allow deletion, and encrypt in transit and at rest. The engineering requirements are covered in privacy compliance for connected products.
Separately, ask whether making health claims turns your product into a regulated device. Displaying general wellness information is treated differently from diagnosing or monitoring a condition, and the line depends on your claims as much as your hardware. Start with is my product a medical device and, if software does the interpreting, software as a medical device.
Testing that actually catches problems
Test on real handsets with real accounts that already contain data from other sources, across an OS version spread. Simulators do not reproduce permission dialogs realistically, and they never reproduce the messy reality of a user who already has three health apps writing the same metric. Also test the denial paths deliberately: refuse each permission and confirm the app stays usable.
Get the device, app, and data model designed together
Projects House develops wearable and health-adjacent products for US clients — sensing hardware, firmware, and companion app specified as one system, including how measurements are validated before they are ever written to a health store. Sensor placement and comfort decisions that affect data quality are discussed in wearable product design. Describe your product through the contact form.