Can a Web App Read Apple Health?

No.

There is no HealthKit in Safari, no Apple Health REST API, and no OAuth endpoint a browser can call for a user’s Health app [1]. A Next.js coaching product, a GLP-1 companion that lives on the web, and a PWA added to the home screen all sit on the same side of that line.

Capacitor does not move the line. It hides it. Official Capacitor health plugins document that they are not available on web and reject in the browser [2] [3]. They work on iOS because the project has become an iOS app: HealthKit capability, usage strings, App Store. The JavaScript you wrote is a UI. The entitlement is native.

This is the stack table, then the two architectures that actually ship. The broader consent map is four authorization models. What happens after you add HealthKit to that binary is App Store rejection.

What people try

The interesting rows are the middle ones, because they are how web teams talk themselves into “we shipped HealthKit” without booking App Review.

Why the web has no surface

HealthKit’s job is to keep health samples on the device, behind a permission sheet Apple draws, in a store other apps can write to and the user can inspect in the Health app [1]. Apple’s privacy model for that store includes an asymmetry we keep repeating because it is easy to forget: the system will not tell your app whether a read was denied, because telling you would leak the denial [4]. Extending that store to fetch() from an origin you control would punch through the model.

There is also no secret REST door. Apple syncs Health data across a person’s own devices. That is not an API for you. Guideline 5.1.3(ii) separately says apps “may not store personal health information in iCloud” [5], which is a review rule about your use of iCloud, not a description of Apple’s own sync. Neither fact produces a Bearer token.

Clinical Health Records (FHIR, after the user connects a health system in the Health app) are still HealthKit types, still on-device, still behind a tighter usage string (NSHealthClinicalHealthRecordsUsageDescription). They are not a web EHR pull.

Capacitor, Ionic, and the “it’s just JavaScript” mistake

Ionic’s @capacitor/health-fitness and Capawesome’s @capawesome-team/capacitor-health are explicit: not available on web [2] [3]. The iOS path requires:

• the HealthKit capability (com.apple.developer.healthkit)
• background delivery if you want observer-query wakes (com.apple.developer.healthkit.background-delivery) [6]
• NSHealthShareUsageDescription / NSHealthUpdateUsageDescription
• on Android, Health Connect permissions in the manifest, because those cannot be requested the way Capacitor plugin config is read [2]

Capawesome’s own FAQ: “There is no web API for health data, so all methods reject with an unimplemented error on the web” [3]. Perfood’s older HealthKit plugin notes the same empty-array behaviour as native HealthKit when the user has denied read: you will not know [7]. The plugin also does not add the HealthKit capability for you. After npx cap sync, open the iOS project in Xcode and enable HealthKit (and Background Delivery, if you need it) on the target [6]. Testing in the browser, or in Expo Go, is testing a host that never received that entitlement.

Once that binary exists, App Review applies in full. Guideline 2.5.1: HealthKit must be used for health and fitness purposes and integrate with the Health app. 5.1.2(vi) and 5.1.3(i): no marketing, advertising, or use-based data mining on that data, including by third parties [5]. A Capacitor app does not get a lighter 5.1.3 because the screens are React. See the rejection field guide.

Android is the same shape

Health Connect is on the phone. Permissions are runtime, declared in the manifest and again in the Play Console Health apps form [8] [9]. A Chrome tab cannot call it.

The cloud-shaped thing on Google’s side is the Google Health API: OAuth 2.0, Restricted scopes, documented against Fitbit devices, Pixel watches, and manual entries [10]. It is a reasonable web backend integration for those sources. It is not Health Connect, and it is not a Galaxy Watch that only wrote into Health Connect on the handset.

So a “web-only, both platforms” product has no on-device health store on either side.

Two architectures that ship

A. Native reader, existing web product

Keep the coaching UI on the web. Ship a small iOS app (and, if you care about Android on-device data, an Android app) whose job is the reader, not the product. The sequence is boring and specific:

1. HealthKit capability in Xcode (the Capacitor plugin does not flip this for you), usage strings, background-delivery entitlement if you will sync while backgrounded [6].
2. A priming screen, then requestAuthorization. Treat empty reads as ambiguous [4].
3. Incremental cursor, persisted: HKAnchoredObjectQuery on iOS (HealthKit has no change-token API; the anchor is the cursor). On Android, getChangesToken / getChanges — and those tokens expire on the order of a month, which is a different clock from Health Connect’s 30-day history permission [14].
4. Persist samples locally first. POST batches to the backend you already have, with each sample’s UUID as an idempotency key. Background delivery retries; a 500 from your API must not duplicate the night.
5. Register observer queries at launch. Call the observer completion handler on every path, including errors, before you wait on the network. Hold that handler open across a POST and HealthKit will back off; fail it three times and iOS stops waking you [15]. Upload with a background URLSession.

Capacitor is one way to keep your web components inside that reader. Swift/Kotlin is another. React Native, Flutter, and Expo prebuild are others. The architectural decision is “we have a native binary,” not which UI kit it uses. Expo Go is not that binary: it is a prebuilt host without your HealthKit entitlement. npx expo prebuild (or a bare workflow) is.

This is the only way an Apple Watch–only user ever appears in your database. Watch samples are HealthKit samples [11].

B. Cloud wearables only

Your web app runs OAuth against Oura, WHOOP, Withings, Fitbit-via-Google, Garmin-if-you-are-in. No App Store. No HealthKit sheet. No Apple Watch. No phone steps. You are building for the subset of users who own a cloud-connected wearable and whose vendor will still admit you. Garmin’s Connect Developer Program is paused for new applicants. Oura starts at ten users [12]. WHOOP requires App approval beyond ten members [13].

That is a real product for a real audience. It is not “we support Apple Health.”

The decision

If a majority of your users are on iPhone, and you want Watch or even phone-motion data, you need a native surface. The web app can remain the product. It cannot remain the only binary.

If you are unwilling to ship iOS, cut Apple Health from the spec in writing, including in sales. Then the OAuth subset is the product, with the partner-program risk that implies.

A layer such as Sahha does not create a browser HealthKit. It still has to run an SDK on the device for the on-device stores. What it changes is whether you write the query, the background delivery, the upload, and the schema. The platform constraint is Apple’s.