Maya is 28 and has been trying to understand whether her dizzy spells could be related to POTS. After one episode, she scrolls through her Apple Watch heart-rate graph and sees 142 BPM, then 58 BPM, then 131 BPM again. The numbers are real, but they don't answer the questions she needs to discuss with a cardiologist: Was the rise connected to standing? How long did it last? Was she exercising, recovering, dehydrated, or asleep beforehand?
That gap sits at the center of Apple Health integration. Apple devices can collect a large amount of biometric information, but raw measurements rarely explain themselves. Useful monitoring requires a second layer that adds timing, context, pattern detection, and a format another person can review.
What Apple Health Integration Really Means
Apple Health integration isn't a single switch or isolated feature. It describes the permission-based and technical connections that let approved apps read from, and in some cases write to, the Health app's underlying data store. That ecosystem includes the Health app on iPhone, the HealthKit framework, sensors on iPhone and Apple Watch, and third-party apps that request specific access.
Apple introduced HealthKit at WWDC on June 2, 2014, then launched the Health app publicly with iOS 8 on September 17, 2014. Apple later described the Health app and Apple Watch, released in 2015, as parts of a broader platform that has expanded continuously across iPhone, iPad, Apple Watch, and compatible apps in Apple's Health Report. That history matters because developers aren't connecting to a brand-new experiment. They're building on a long-running health data layer.
For Maya, the important distinction is simple:
- The Apple Watch captures or contributes measurements.
- HealthKit organizes those measurements securely on the device.
- The Health app gives her a place to view sources and control permissions.
- A specialized app can interpret selected records and turn them into episodes, trends, or reports.
The Health app may show that her heart rate changed. An analysis app can ask whether those changes form a meaningful pattern.
Raw measurements are only the starting point
A heart-rate value has meaning only alongside its surrounding details. The time of the reading, whether the person was moving, the preceding baseline, the length of the elevation, and related symptoms can change how someone interprets it.
That doesn't mean an app can diagnose a condition from a graph. It means integration can reduce the manual work involved in assembling a coherent history. Instead of asking Maya to remember every episode, a read-only app can inspect permitted HealthKit samples, identify patterns, and present the results for her review.
Practical rule: Apple Health stores the evidence. A responsible app should explain the pattern without pretending the pattern is a diagnosis.
How HealthKit and the Health App Work Together
Think of the system as a library. The Health app is the front desk, where you view your account, review sources, and decide which information an app may access. HealthKit is the library stack and catalog underneath, providing the framework that stores and structures health samples from approved apps and devices.
The analogy helps separate two things people often treat as interchangeable. Opening the Health app doesn't mean every other app can see everything displayed there. Each app must request particular data types, and iOS presents those requests for the user to approve or decline.
The data model behind the graphs
HealthKit doesn't treat heart rate as one undifferentiated line. It stores typed samples, such as heart rate, step count, sleep analysis, or workout data. A sample can carry a start time, an end time, a source device, and additional metadata.
That structure lets an app ask focused questions. It might request heart-rate samples within a time window, identify which device recorded them, or compare readings with workout intervals. The app doesn't receive permission to wander through the entire vault just because it was allowed to read one category.
Permission is part of the architecture
Apple describes HealthKit data as stored on-device and encrypted so that only the user's passcode, Touch ID, or Face ID can access it. Apple also states that Health app metrics are computed entirely on-device from sensor inputs on Apple Watch and iPhone, as detailed in its Health privacy white paper.
An app therefore needs two kinds of permission decisions. First, it must declare the data categories it wants to use. Then the user decides which requested categories to allow. Those decisions can be reviewed or withdrawn later in Health settings.
Read and write are different permissions
Read access lets an app inspect selected existing samples. Write access lets it add permitted samples to HealthKit. An app may request one, the other, or both.
This distinction becomes important when evaluating trust. A monitoring app that only needs existing heart-rate records doesn't need write access to analyze them. The narrower the request, the easier it is for the user to understand what the app can do.
What Data Apps Can Read and Why Read-Only Matters
HealthKit can expose many categories of health information, but availability depends on the device, the source, the user's permissions, and the way an app requests access. A heart-rate monitoring app might request heart rate, heart-rate variability, resting heart rate, workouts, or compatible ECG records. Another app could focus on sleep, steps, respiratory rate, blood oxygen, or clinical records where those records are available.
Permissions are granular. You may allow an app to read heart rate while denying sleep data, and the app can't inspect a category you haven't approved. The same principle applies to writing. An app that can write one type of record doesn't automatically gain permission to write every other type.
| Data Type | Read | Write |
|---|---|---|
| Heart rate | Yes | Possible with permission |
| Heart-rate variability | Yes | Possible with permission |
| Resting heart rate | Yes | Possible with permission |
| ECG recordings | Where supported and authorized | Limited by the data type and app capability |
| Blood oxygen | Where supported and authorized | Possible only where HealthKit permits the type |
| Sleep analysis and stages | Yes, where available | Possible with permission |
| Steps | Yes | Possible with permission |
| Workouts | Yes | Possible with permission |
| Respiratory rate | Yes, where available | Possible with permission |
| Clinical records | Where available and authorized | Depends on the record type and framework support |
Why narrower access improves confidence
Read-only design creates a meaningful boundary. An app with read-only access can analyze existing records, but it can't add samples that make a dashboard look more complete or alter a log to fit an interpretation. It also can't record a condition the user never entered.
That boundary matters for POTS and dysautonomia monitoring because the quality of the conclusion depends on the integrity of the underlying timeline. If an app changes the source data, a later review becomes harder to trust. A read-only workflow keeps the original record in Apple Health while placing interpretation in a separate layer.
A useful question: Does the app need to write anything, or does it only need to understand what Apple Health already contains?
Read-only doesn't make an app automatically accurate or clinically appropriate. It does make the data flow easier to explain. The app reads approved samples, performs its stated analysis, and gives the user control over what happens next.
Setting Up Apple Health Integration Step by Step
The setup begins when an app such as Cardiogram asks for access to Apple Health. The system permission sheet lists the categories the app wants to read or write. Don't approve the request automatically. Review each category and grant only what matches the app's purpose.
Start with the system permission sheet
For heart-rate pattern analysis, the relevant requests may include:
- Heart rate, which supplies recorded beats-per-minute samples.
- Heart-rate variability, which can add another signal for trend analysis.
- Resting heart rate, which helps establish a personal baseline.
- Workouts, which provides context for separating exercise-related elevations from other events.
The app can only use the categories you approve. If you skip sleep or workout access, its analysis won't have those contextual records available.
Review access after setup
You can revisit permissions in Settings > Privacy & Security > Health. The in-app screen and the iOS settings screen serve different purposes. The initial system sheet grants access, while the settings area lets you inspect or change the decision later.
Enable Background App Refresh if the app relies on background updates, and allow notifications if you want alerts when the app identifies a relevant event. These settings don't turn HealthKit into a continuous live stream, but they can help the app process new information when the operating system permits it.
For a more detailed workflow around preparing records for review, see this guide to Apple Health data export.
Troubleshoot missing records
When no data appears, check the source before assuming the integration failed:
- Confirm the watch connection. Make sure the Apple Watch is paired with the intended iPhone.
- Check wrist detection. Sensor collection can be affected when the watch isn't being worn or wrist detection is disabled.
- Review Health sources. Open the relevant metric in the Health app and inspect which sources contribute records.
- Recheck permissions. An app may have access to heart rate but not workouts or HRV.
- Allow processing time. Background delivery can be delayed, so an app may not react immediately to a new sample.
A Worked Example for POTS and Dysautonomia
Consider a read-only app analyzing heart-rate records for someone who experiences dizziness after standing. Apple Health supplies the underlying samples. The app's job is to arrange those samples into a timeline that answers more useful questions than “What was my heart rate?”
A condition-focused workflow can examine a baseline, look for a substantial rise over a short interval, and record the peak and sustained duration. Cardiogram describes automatic detection of 30+ BPM rises within 5 minutes, with episode timing, baseline, peak, and duration recorded for review. That criterion is a screening and tracking rule, not a diagnosis, and a clinician must interpret it alongside symptoms and other medical information.
Context separates patterns from noise
A high reading during a workout shouldn't be treated the same way as a rise while standing in the kitchen. Workout records and recovery periods can therefore be excluded from episode counts, reducing a common source of misleading alerts.
Sleep, symptoms, hydration, salt intake, medications, and activity context can add another layer. A person might log dizziness or palpitations near an episode, then review whether similar events occur after poor sleep or during particular parts of the day. The result isn't a medical conclusion. It's a more organized set of observations for a clinical conversation.
For an explanation of how raw records can become longitudinal patterns, see this guide to health trend analysis.
On-device processing changes the workflow
Apple says HealthKit data remains protected on the device, and apps can be designed to read local summaries without requiring server-side access to raw health histories. In an on-device model, the app analyzes permitted samples locally and syncs through the user's own iCloud environment rather than sending raw records to a vendor backend.
The output can be a weekly summary, a heatmap of episode timing, or a PDF that states the detection criterion and summarizes episodes, symptoms, and trends. That format addresses the practical problem Maya faced at the beginning. Her clinician doesn't need a long scroll through disconnected graph points. They need a concise record that shows what happened, when it happened, and what context the patient observed.
Where Apple Health Integration Still Falls Short
Apple Health integration can connect data sources without automatically making them agree. Apple Health is often treated as a unified record, but the records may still differ in timing, coverage, metadata, and source priority.
Independent coverage describes a significant limitation: HealthKit doesn't normalize data across different wearable brands, and it doesn't provide built-in trend or readiness signals. A person using multiple devices may see overlapping records, gaps, or conflicting measurements. The integration may technically work while still leaving the user to decide which source should guide a trend.
Raw data doesn't become insight by itself
HealthKit provides structured health samples, not a condition-specific interpretation layer. It doesn't natively label an orthostatic episode, explain why a heart-rate rise happened, or produce a clinician-ready summary of POTS symptoms.
That work falls to the app reading the data. If the app doesn't offer appropriate filtering, context logging, or reporting, the user remains responsible for turning a long history into something a care team can review.
The phone remains the practical gateway
Because HealthKit is designed around device-local storage and explicit permission, many integrations depend on a local iPhone app to read and package information before another system can use it. This protects user control, but it can make interoperability less convenient.
The same tension appears when people want to combine health records across ecosystems. Recent reporting notes that cross-ecosystem syncing is improving in adjacent markets, but availability and supported data types can vary. The useful question isn't merely whether an app “integrates with Apple Health.” Ask which data types it reads, how much history it imports, how it handles duplicates, and which source takes priority.
Strong privacy can reduce convenience. That tradeoff is acceptable only when the app makes export, review, and permission management clear.
Other gaps can affect interpretation. HRV may be unavailable or inconsistent on some devices, sleep staging may be fragmented, and symptom information often requires deliberate manual logging. Those limitations cost the patient time, especially when a clinician needs context rather than another unannotated graph.
Best Practices for Developers Building on HealthKit
HealthKit developers should treat background delivery as an event-driven notification system, not a continuous heart-rate stream. Apple documents that most watchOS data types have limited background delivery frequency, while certain event types, including high-heart-rate, low-heart-rate, and irregular-rhythm events, can be delivered immediately. A reliable design should account for batching and intermittent app wake-ups.
Query for changes, not the entire archive
Use an observer query with enableBackgroundDelivery to learn that relevant data may have changed, then use an anchored query to fetch only the samples added since the last checkpoint. This avoids repeatedly processing the same history and makes the app's local state easier to reason about.
Filter workout samples and recovery periods before calculating resting trends. Otherwise, exercise-related elevations can distort the baseline that an episode detector depends on.
Keep storage and authorization narrow
Batch writes through HKHealthStore.save when writing is required. If the product only analyzes existing records, prefer read-only authorization and avoid requesting write scopes that don't serve a clear user need.
Store derived insights on-device with an appropriate local persistence layer, such as SwiftData or Core Data. Before showing the system permission prompt, explain each requested category in plain language. The permission rationale should match the code.
Finally, make the privacy disclosure match reality. If the app says analysis happens locally, the implementation and data flow should support that statement. A privacy label isn't a marketing paragraph. It's a contract with the user.
Choosing Integrations You Can Trust
Before tapping Allow, ask four practical questions:
- What can the app read and write? Read-only access is narrower than read and write access.
- Where is processing performed? On-device analysis limits unnecessary movement of sensitive records.
- Does the privacy explanation match the permission sheet? The app's description should name the same categories it requests.
- Can you export and revoke access? You should be able to create a useful report, change permissions, and stop sharing without confusion.
A trustworthy Apple Health integration requests minimal scopes, explains its purpose before consent, and separates raw records from derived interpretation. For additional guidance on evaluating storage and permission choices, review this health data privacy guide.
The most useful integration isn't the one that collects the most information. It's the one that turns approved data into a transparent, reviewable result while preserving the original record and the user's control.
Cardiogram reads permitted heart-rate data from Apple Health with read-only access, analyzes patterns on the device, and organizes episodes, trends, context, and clinician-ready reports for people tracking POTS or dysautonomia symptoms. Visit Cardiogram to see how an existing Apple Watch and Apple Health workflow can become easier to review and share.
