# Where your health app data actually goes

> A tracker does not need a server to store your readings. Here is how to read the store disclosures, and what an account requirement really tells you.

Source: https://apps.swtlm.com/blog/where-your-health-app-data-goes · TLM Apps — focused mobile apps from a team of engineers.
Published: 2026-07-29 · Updated: 2026-07-29 · TLM Software Design

Your readings are in one of two places: only on your phone, or on a server
belonging to whoever wrote the app. Nothing about a blood pressure or sleep
tracker needs the second. A year of readings is a few kilobytes and the
arithmetic is an average, so an app that insists on an account has made a
choice rather than met a constraint. Both stores make developers declare which
one it is, and the declaration sits on the listing page.

We fill in those forms for a health app of our own, so what follows describes
paperwork we have submitted rather than a guess about it.

## Why "it needs an account" is the tell

Ask what the server is *for*. There are honest answers: sync across devices,
a clinician's shared view, a backup you can restore after losing a phone.
Each is a real feature, and each is optional.

Storage is not an honest answer. A phone has kept lists of numbers unaided for
fifteen years. So when a tracker demands an account before it will record a
single reading, the account is there for some other purpose, and that purpose
is usually a user record that outlives your interest in the app.

Install the app, turn on aeroplane mode, and use it normally for a few minutes.
If you can still enter a reading, look at your history and export the lot, then
nothing is being sent anywhere while you use it. An app that stops at the first
screen has answered the question just as clearly.

## Reading the disclosures

**Google Play — Data safety.** A card on the listing, above the reviews. Three
things to read, in order:

- **Data collected** versus **data shared**. Collected means it leaves the
  device to the developer; *shared* means it goes on to a third party. Shared
  is the serious one.
- **Whether health and fitness appears at all.** It is a distinct category, so
  it cannot be hidden inside a vaguer heading.
- **Data cannot be deleted** as a stated line. If data is collected and there
  is no deletion request path, that combination is worth taking seriously.

**App Store — App Privacy.** The same idea in three buckets:

- **Data Used to Track You** — the strongest signal on the page. For a health
  app this should be empty.
- **Data Linked to You** — collected and tied to your identity.
- **Data Not Linked to You** — collected but not tied to you. Crash reports and
  aggregate usage counts usually live here, legitimately.

Both are **self-declarations**, checked by spot audit rather than inspection.
That still counts for something, because a false declaration is a policy
violation with real consequences. But read them as a claim somebody signed, not
as a fact somebody verified. The aeroplane-mode test is the half you can check
yourself.

The thing to look for is not the length of the list. It is whether the category
that matters to you appears in it, and whether anything says **shared** rather
than **collected**.

## Medical privacy law probably does not apply

This surprises people, so it is worth stating plainly. Rules written for
medical records, HIPAA in the United States and its equivalents elsewhere,
cover healthcare providers and the companies handling data on their behalf.
They do not cover an app you found in a store and installed yourself.

What applies instead is general data-protection law and the store's own
policies. Both are meaningfully weaker than the medical regime most people
assume they are under. In practice that means your protection comes from how
the app was built, not from a body of law it sits outside.

## Syncing to Health or Fit is a different thing

"Sync" gets used for two unrelated behaviours.

**Writing to Apple Health or Google Fit** puts the data into a store on your
own device that other apps can read once you allow it. The developer never sees
any of it. This is the good kind, and worth having, because it is what lets a
reading appear alongside everything else your phone knows.

**Syncing to a company's cloud** sends it to their servers. That is perfectly
legitimate if you asked for a backup. It implies something completely
different.

When a listing says "syncs" without saying where to, that is the question to
answer before you type anything in.

## What we do

[Blood Pressure Diary](https://apps.swtlm.com/blood-pressure-diary) keeps readings on the device.
There is no sign-in and nothing to create, and the whole app works with the
phone in aeroplane mode. That last part is the version of the promise you can
check yourself in a minute.

Its Data safety declaration is the one in the question above: purchase history,
crash logs, app interactions and a device identifier, all collected and none
shared, with no account creation and a route to request deletion. Health and
fitness data is not declared, because none is collected. That is the whole
list, and it is on the Play listing rather than only in this paragraph.

[Somnia](https://apps.swtlm.com/sleep-sounds-generator) has nothing to send: the fifteen audio loops
ship inside the download and a mix is a local setting.

Neither shares anything with a third party, and nothing is joined across our
apps. There is no shared identifier that would let us join it. The broader
statement of what we will and will not claim is on the [About page](https://apps.swtlm.com/about).

If you are assembling readings for an appointment,
[a blood pressure log your doctor can actually use](https://apps.swtlm.com/blog/blood-pressure-log-for-your-doctor)
covers what to record and how to present it, and
[how to mix sleep sounds that mask noise](https://apps.swtlm.com/blog/how-to-mix-sleep-sounds-that-mask-noise)
does the same for [Somnia](https://apps.swtlm.com/sleep-sounds-generator). The rest of what we make
for tracking and sleep is on the [Health & Sleep page](https://apps.swtlm.com/health).

## Frequently asked questions

**Where does a health app store my readings?**

Either only on your device, or on a server belonging to whoever made it. Nothing about a tracker requires the second — the data is tiny and the arithmetic is trivial — so an app that requires an account has chosen a server rather than needed one.

**What does the Data safety section tell me?**

What the developer declares is collected, whether any of it is shared with third parties, whether it is encrypted in transit, and whether you can request deletion. Health data has its own category, so it is visible rather than hidden inside 'personal info'.

**Is a health app covered by medical privacy law?**

Usually not. Rules like HIPAA cover healthcare providers and their contractors, not an app you downloaded yourself. What governs a consumer tracker is general data-protection law and the store's own policies.

**Does syncing to Apple Health or Google Fit send data to the developer?**

No. Those are on-device stores the app writes to with your permission. Syncing to them is different from syncing to a company's own cloud, and the two often get described with the same word.

**What is the single most useful thing to check?**

Whether the app works with the phone in aeroplane mode. An app that keeps working with no connection cannot be sending your readings anywhere while you use it.