When does a HealthKit app become a regulated medical app, and when do you need a HealthKit developer who knows the difference?

Most teams hire a HealthKit developer thinking the hard part is reading the data. You ask for permission, you query a sample type, you draw a chart, and it works in the demo. The hard part is the data you collected and then quietly lost, plus the prior question of whether any of it crosses into something the FDA cares about.

When does a health app become a regulated medical app? ¶

The moment you tell the user what the numbers mean about their health. A step counter that nudges you to move stays on the wellness side. The same app, told that a pattern in heart rate "may indicate" a condition, has made a medical claim, and now App Review reads it differently and your lawyer should too. The rendering code is identical on both sides; what carried the app over the line was the wording.

That distinction has legal and review consequences. The App Store Review Guidelines carve out medical apps as their own category, and apps that "could provide inaccurate data or information, or that could be used for diagnosing or treating patients" are held to a higher bar of evidence and disclosure under guideline 1.4.1.^[1]1. App Store Review Guidelines, section 1.4.1 (Physical Harm - medical apps), which sets a higher bar for apps that could be used for diagnosing or treating patients and requires regulatory clearance where applicable. Regulators draw the same line from the other side: software that is intended to diagnose, treat, or mitigate a condition is a medical device, and software that merely encourages a healthy lifestyle generally is not. The wording on your paywall, in your onboarding, and in your push copy is where that intent gets established. I have watched a single verb in a notification - "detected" instead of "logged" - turn a wellness feature into something a reviewer escalates.

I work this line out with teams as part of HealthKit and medical iOS work, because getting it wrong is expensive whichever way you miss. Overclaim and you've shipped an unregulated medical device, with the recall and the regulatory letter that implies. Underclaim and a feature people are meant to rely on reads as a toy, picks up a soft disclaimer, and quietly stops being trusted. The useful exercise is to take every screen that shows a number and ask what the user is expected to do differently because of it. That answer rarely lands the same way across the whole app; one tab can be plain logging while the next is making a claim.

Why does HealthKit data quietly go missing? ¶

Reading a sample on screen is easy. Keeping every sample is the part that fails. HealthKit hands you new data through background delivery and observer queries, and that path is fragile. The app gets suspended, a launch fails silently, an iOS update resets the observer, and samples that arrived while you weren't listening aren't there. No error gets thrown and nothing crashes. You just end up with a gap in the chart.

The mechanism that prevents this is anchoring.^[2]2. Apple's HealthKit documentation for HKAnchoredObjectQuery and HKObserverQuery - the observer signals that data changed; the anchored query returns only samples added or deleted since a persisted anchor, which is what makes gap-free background sync possible. HKObserverQuery tells you that something changed; it does not hand you the new samples, and it does not remember where you left off. The piece that remembers is HKAnchoredObjectQuery, which gives back an opaque anchor you persist and feed into the next query so it returns only what arrived since. Skip the anchor and trust the observer's wake-up as the source of truth, lose the anchor on a reinstall, or never run the anchored query because the background launch was killed first, and you get silent gaps. The samples are still in the HealthKit store; your copy of them is not. Most "missing data" bugs I'm handed turn out to be an anchor that was never made durable, not a sync that never ran.

In a habit tracker, a missing afternoon of steps is noise. In a seizure and medication app (I spent five years building Epsy, an FDA-regulated epilepsy app, at LivaNova) a missing reading is a gap in a clinical record someone may base a care decision on, and "the data was on the watch but never synced" is not an answer you want to give. How you anchor queries, how you recover after a missed window, and which device you trust when the phone and the Watch disagree become decisions with a clinical cost behind them, not just an analytics one. Reconciliation is the underrated part: when a Watch records a workout offline and the phone has already logged a partial overlap, naively unioning both double-counts, and naively deduping by timestamp throws away the more accurate source.

Is HIPAA a backend problem or does it live in the iOS app too? ¶

Both, and the half teams forget is the iOS app. Most of the findings I run into as a HIPAA iOS developer are dull and expensive at the same time: tokens parked in UserDefaults instead of the Keychain, audit logging that can't name which user accessed what, third-party SDKs that see patient data with no Business Associate Agreement behind them. Device encryption helps, but it isn't the whole story, and "HealthKit encrypts it for us" stops being true the moment the data leaves HealthKit for your own store.

The structural mistake is assuming the regulated boundary is the network call. Protected health information becomes your responsibility the instant a sample crosses out of HKHealthStore into anything you control: a SwiftData model, a cache file, a crash report, an analytics event. An analytics SDK that fingerprints the device and happens to receive a screen name like "Glucose Trend" is now processing PHI on your behalf, and that vendor either has a BAA or you have a problem. Apple reinforces this from the store side: guideline 5.1.3 forbids using HealthKit data for advertising or sharing it with third parties for that purpose, and forbids writing false or inaccurate data into HealthKit at all.^[3]3. App Store Review Guidelines, section 5.1.3 (Health and Health Research), which prohibits using HealthKit or Clinical Health Records data for advertising or sharing it with third parties for those purposes, and prohibits writing false or inaccurate data into HealthKit. Those rules bite at review time, well before any compliance audit gets near the build.

Storage choices carry the same weight. When I built SilkSilkPrivate intimate wellness trackerView app, a private intimacy tracker, the threat model meant local-only data encrypted with CryptoSwift (PBKDF2 to derive a key from the passphrase, AES to seal the store) rather than trusting file protection alone, because the sensitive case is the unlocked, in-use device, not the one sitting in a drawer. A medical app rarely gets to be local-only, but the instinct transfers: decide what the encryption is actually defending against before you reach for a framework, because "we used the Keychain" answers a different question than "what happens when this device is shared, jailbroken, or backed up to an untrusted Mac." The age-rating and sensitive-content wrangling around that build is its own story, which I wrote up in Apple's Problem with Bodies.

What changes for medical apps in iOS 27? ¶

The input surface widens, and every new input is another thing you have to validate before you trust it. In iOS 27, Visual Intelligence can write blood-pressure, glucose, and weight readings straight into HKHealthStore if your app already reads that type, surfacing a medical-device reading the user pointed their camera at as a first-class HealthKit sample.^[4]4. WWDC 2026, session 297 - Visual Intelligence can write medical-device readings (blood pressure, glucose, weight) into HealthKit via HKHealthStore for apps that already read those types. That is free input for a medical app, but it brings a provenance problem with it. A number that came from an OCR pass over a cuff display is not the same evidentiary object as one streamed from a paired BLE device, and a clinical app that treats them identically is making a claim it cannot stand behind.

The reading you accept needs a consent path and a way to record how it arrived, because HKSource and the sample's metadata are what let you later say "this glucose value was transcribed by Visual Intelligence, not measured by a cleared device." On the workout side, the same release formalises heart-rate and cycling-power zones through HKWorkoutZoneGroup and live updates via HKLiveWorkoutBuilderDelegate, with system-calculated zones the OS keeps in sync alongside custom zones your app defines before collection starts.^[5]5. WWDC 2026, session 207 - "Deliver workout insights with HealthKit workout zones," covering HKWorkoutZoneGroup, HKWorkoutZoneConfiguration, and live zone updates through HKLiveWorkoutBuilderDelegate. For a fitness app that is a feature; for anything making a physiological claim it is one more place where "whose number is this, and how was it derived" has to be answerable.

None of this is exotic. The expensive failures in this niche are mundane: an anchor that wasn't persisted, a token in the wrong store, a verb in a notification, a transcribed reading trusted like a measured one. They surface in an audit or a reviewer's letter rather than a crash log, which is exactly why they cost so much; by the time you see them, the build is already in someone's hands.

How do you tell a wellness feature from a medical one before you build it? ¶

Write the sentence the user reads, then decide. The fastest reliable test I know is to draft the exact on-screen copy for a feature (the headline, the disclaimer, the notification) before a line of it is built, and ask whether that wording tells the user something about their health or merely about their behaviour. The first reading is a claim; the second usually is not. The code to render either is identical, so the decision has to be made in language, by someone who knows which sentences trigger which obligations.

This is the work that pays for itself, because it's cheap before the build and ruinous after. Restructuring a feature from "may indicate" to "here's what you logged" is a copy change on a Tuesday if you catch it in design, and a regulatory conversation plus a re-review if you catch it in the App Store. I treat it as the first thing to settle, ahead of any HealthKit plumbing, because the plumbing differs depending on the answer: a wellness chart can tolerate the occasional dropped sample, and a clinical record cannot, so the claim you make is what sets your data-integrity budget. If you're somewhere on the wellness-to-medical spectrum and not sure which side a feature sits on, send it to me and we'll work out which side it's on before you build it - that ordering is the whole difference between a copy edit and a recall. If the build also has to clear App Review's medical and HealthKit rules cleanly, that's a related but separate exercise in App Store review readiness.