Overview
Grio uses Apple Health as a read-only, one-way import. It never writes, renames, or deletes an underlying HealthKit record. Anything you record manually, in chat, or through the coach stays a Grio-owned record, with its origin visible.
That boundary is deliberate: Grio should never become a second writer to your health store, and you should always be able to tell where a fact came from.
How it’s calculated
What actually syncs
The ordinary sync reads a bounded recent window and produces daily projections: sleep, movement, recovery metrics, body mass, workouts. What is persisted on your device and synced to the server are those derived projections, not raw samples.
Raw samples live only for as long as the read or aggregation that consumes them. A screen that needs finer detail requests a bounded detail slice: one read serves every surface asking for the same window, pressing a card can warm the read its detail page is about to make, and the slice is forgotten a few minutes after the last surface stops watching it. Slices are never persisted or uploaded, and leaving the account or disconnecting Apple Health clears them.
Heart-rate trends use a statistics-only calendar slice of at most 366 inclusive local dates. Each observed day is folded to its minimum and maximum before crossing the native bridge, and missing days stay missing.
When it refreshes
| Trigger | What happens |
|---|---|
| Connecting Apple Health | A forced bounded read |
| Pull to refresh | A forced bounded read |
| Opening the app | A read when health freshness has gone stale |
| Ordinary background refresh | May read and checkpoint projections locally; must not upload them |
| Two narrow native paths | May use background network delivery |
Those two native paths are the only background uploaders, and neither is general. One carries the five-minute buckets that Physiological Load and Stress read. The other is a selected-observation stream carrying privacy-reduced sleep, workout, body-mass, and daily recovery projections. Each owns a separate bounded checkpoint, its own credential, and its own server contract.
The background path uses bounded full-window recomputation rather than relying on the app waking up. The first compatible checkpoint reads at most 30 days; later checkpoints begin 90 minutes before the account cursor, aligned to a five-minute boundary, so open, late, and corrected buckets are recomputed completely.
Reconciliation and provenance
- Imported workouts keep their HealthKit identity and source: their details are read-only in Grio. Removing the Grio projection does not mutate Apple Health, and sync may restore or mark it missing as the underlying record appears or disappears.
- Overlapping Apple and Grio sessions are reconciled with a shared overlap rule so a workout recorded twice is not counted twice. The underlying source records keep their own provenance.
- Imported body mass may appear in the weight card, and a Grio weight record you authored for the same date takes precedence.
- Workout analysis is limited to sessions recorded in Grio. Imported Apple workouts do not become Grio-recorded analysis statistics.
Edge cases and fallbacks
- A failed read may preserve already-observed past projections rather than erasing history. It never fabricates a current observation.
- Missing values remain missing: nothing becomes zero.
- Connecting requires at least one fresh metric result from the bounded read. A stale carry-forward is useful data but is not proof the connection works.
- A metric your device does not write to HealthKit is simply not available. Grio does not connect to third-party vendor accounts.
How to read your score
- A gap is not a zero: an unobserved day looks unobserved everywhere in Grio, and that is why some scores read as unavailable rather than as a low number.
- Later data can change an earlier day: a delayed upload updates history, and Grio’s freshness rules stop it being presented as a current change.
- Provenance matters when two sources disagree: the record’s origin is shown, and the reconciliation rules are consistent rather than first-writer-wins.
What to do with it
- Grant every permission Grio asks for, or expect the matching feature to be unavailable: a denied read is indistinguishable from no data.
- Pull to refresh when a screen looks behind: it is the cheapest way to force a bounded read.
- Wear the watch overnight for recovery metrics: HRV, resting heart rate, and sleep are all overnight observations, and a night on the charger is a night with no evidence.
- Check what your non-Apple device actually writes to HealthKit before concluding Grio missed something. Many devices write far less than their own app displays.
Troubleshooting & FAQs
- Why is today's data missing when Apple Health clearly has it?
- Ordinary refresh happens when you connect, pull to refresh, or open the app after the data has gone stale. Two narrow native paths run in the background, and neither is a general uploader. If a screen looks behind, pull to refresh. That forces a bounded read rather than waiting for the next trigger.
- Does Grio write anything back to Apple Health?
- No. It is a read-only, one-way import. Grio never creates, renames, or deletes a HealthKit record. Removing an imported workout from Grio's Activity list removes Grio's projection of it and leaves Apple Health untouched.
- I use a Garmin. Will it work?
- It works to the extent your device writes into Apple Health, which varies by device and metric and is often sparse. Grio reads what is in HealthKit. It does not connect to third-party accounts directly, so anything your device does not write is not available.