Getting Apple Health Data Into Your Backend

Open Wearables Team · May 5, 2026 · 7 min read

Key Takeaways

There is no server-side Apple Health API; your iOS app must read HealthKit data on device and upload it to your backend
The full pipeline requires HealthKit entitlement, permission handling, query logic, background delivery, and a backend endpoint
Observer queries combined with enableBackgroundDelivery let your app sync new data without the user opening it
Change token patterns are not available in HealthKit; track sync position using timestamps stored locally
Open Wearables provides an iOS SDK that handles the full pipeline including permissions, background sync and normalized upload

Introduction

For developers who primarily work in backend systems, Apple Health integration involves a context switch that is easy to underestimate. The challenge is not the data model or the metrics HealthKit exposes. The challenge is that everything you would normally handle server-side has to be implemented client-side in Swift, embedded in an iOS app that must handle background execution constraints, permission complexity and upload reliability.

This guide covers the complete pipeline from HealthKit to your backend: what you need to build at each layer, the implementation patterns that work reliably in production, the edge cases that trip up most implementations, and how Open Wearables removes most of this work for teams building multi-provider health applications.

What You Are Building

The pipeline from HealthKit to your backend has five distinct layers, each with its own implementation requirements.

First, your iOS app needs the HealthKit entitlement, which requires an Apple Developer Program membership and explicit enablement in the Xcode project capabilities. Without this entitlement, all HealthKit API calls fail silently at runtime.

Second, you need the permission request flow. HealthKit permissions are granted per data type. You must specify which types you want to read, present the system permission sheet to the user, and handle partial grants gracefully since users can approve some types and deny others.

Third, you need query logic for each data type you want to sync. HealthKit queries are asynchronous, type-specific and require specifying predicates to filter by date range. Reading heart rate data uses different sample types than reading sleep records or workout objects.

Fourth, you need background delivery. Observer queries combined with enableBackgroundDelivery allow iOS to wake your app when new HealthKit data arrives, even when the app is not in the foreground. This is the mechanism that makes automatic sync possible without requiring users to open the app.

Fifth, you need reliable upload to your backend. The background wake window is limited. Upload logic must be fast, handle network failures gracefully, and track sync position so you never re-upload data that has already been sent.

Permission Request Strategy

The HealthKit permission sheet presents all requested data types to the user at once. How you structure this request significantly affects authorization rates.

Request permissions at the moment they are contextually relevant, not automatically at app launch. A user who has just completed onboarding and understands what your app does is far more likely to grant permissions than a user who sees a permissions sheet the first time they open the app before they have any context.

Explain why you need each type before triggering the system sheet. HealthKit provides a NSHealthShareUsageDescription key in your Info.plist for a general explanation, but in-app explanations tailored to your specific use case are more effective. "We read your sleep data to calculate recovery recommendations" is more compelling than the generic message many apps display.

Request only the data types your product actually uses. Each type in the permission sheet is another thing the user has to evaluate and potentially reject. Over-requesting permissions reduces authorization rates and erodes user trust.

Observer Queries and Background Delivery

The observer query is the mechanism that makes background sync work. You register an observer for a specific HealthKit sample type, and iOS wakes your app when new samples of that type are added to the HealthKit store, even when the app is backgrounded or not running.

The critical pairing is HKObserverQuery with enableBackgroundDelivery. The observer query alone only fires when the app is active. Enabling background delivery tells iOS to wake the app in the background when new data arrives. The frequency parameter (immediate, hourly, daily) controls how often background delivery can occur. For most health data types, hourly or daily is appropriate. For workout completion events where you want near-real-time sync, immediate delivery is reasonable.

When your observer fires, you have limited execution time. Query for new samples since your last sync timestamp, serialize the results, and upload to your backend in a single batch. Store the sync timestamp locally using UserDefaults after a successful upload so the next observer fire knows where to resume.

Upload Architecture

The upload from device to backend needs to be reliable in unreliable network conditions. Users sync HealthKit data at unpredictable times including right after a workout when they may have intermittent connectivity.

Use URLSession with a background session configuration for uploads. Background URLSession can complete uploads even after your app is suspended, which is important for the limited execution window of background delivery. The session delegate handles completion events, including failures, which your app can receive the next time it is active.

On the backend, design your endpoint to accept batch payloads and process them idempotently. HealthKit samples have unique identifiers (UUID) that you should include in your upload payload. Your backend can use these as idempotency keys to handle duplicate uploads gracefully, which will happen when a user's network connection drops mid-upload and the SDK retries.

Common Edge Cases

Multiple sources for the same data type. HealthKit aggregates data from Apple Watch, iPhone, and third-party apps. A user who has both Apple Watch and a Whoop might have heart rate data in HealthKit from both devices. Decide how to handle source priority in your normalization layer. Using HKSource metadata on samples lets you filter by device type if you need to.

Missing Apple Watch. Many HealthKit data types require Apple Watch. iPhone-only users will have step count and manually entered data but not continuous heart rate, sleep staging or SpO2. Build your app to degrade gracefully and show what is available rather than displaying empty states for types that require hardware the user does not have.

Permission revocation. Users can revoke HealthKit permissions in iOS Settings without your app knowing. Your next query for a revoked type returns empty data rather than an error. If a user's data drops to zero unexpectedly after previously syncing successfully, surface a prompt to check permissions.

Large historical datasets. A user with five years of Apple Watch heart rate data has millions of samples. For initial backfill, process in time-window chunks (one week at a time) rather than querying the entire history at once to avoid memory pressure on the device.

Open Wearables

Open Wearables provides an iOS SDK that handles the entire pipeline: HealthKit entitlement configuration guidance, permission request UI, observer query setup, background delivery configuration, batch upload to your Open Wearables backend, and sync position tracking. On the server side, Apple Health data is normalized to the same schema as Garmin, Whoop and Oura data.

For multi-provider products, this means you do not need to maintain a custom iOS sync implementation alongside your backend. The SDK handles the iOS complexity; Open Wearables handles the server-side normalization.

FAQ

Does background delivery work reliably?

Background delivery works reliably in normal conditions but is subject to iOS background execution constraints. Aggressive battery optimization on some devices, low power mode, and certain system conditions can delay or prevent background wake. The integration should be designed with the expectation that background delivery is best-effort, not guaranteed.

How do I handle the case where a user installs the app on a new phone?

The user needs to re-grant HealthKit permissions on the new phone. Historical HealthKit data is restored from iCloud backup if the user has iCloud Health backup enabled, but you cannot assume this. Plan for the possibility that a returning user on a new device has no historical HealthKit data available.

Can I read HealthKit data from a SwiftUI app?

Yes. HealthKit works with both UIKit and SwiftUI. The API is the same regardless of which framework your app uses.

What is the Apple Review process for HealthKit?

Apps that request HealthKit permissions must have a primary purpose related to health, fitness or medical use. Apple reviews HealthKit usage during App Store review and rejects apps that request health permissions without a clear health-related use case.

Can I use HealthKit in an Expo or React Native app?

HealthKit access from cross-platform frameworks requires a native module. There are third-party packages for both React Native and Expo that wrap HealthKit, but they vary in maintenance quality and feature coverage. For production use, native Swift with the Open Wearables SDK is the more reliable path.