Lepo · iPhone and Apple Watch

Privacy

Your health data never leaves your device. Lepo sends usage analytics, and this page lists everything they contain.

Health data

Lepo reads from Apple Health and never writes to it. The app requests read-only access, so it has no ability to add, change, or delete anything in Health.

Your readiness score, sleep figures, heart rate, and every other measurement are computed and kept on your device. They live in a container shared between the app, the watch app, and the widgets, so all three can show the same numbers. They stay there, and in your own iCloud or device backups if you have those switched on.

No health reading of any kind is transmitted off the device. Not a score, not a sleep duration, not a heart rate, not a single measurement. This was checked by listing every property the analytics service has actually received.

One thing sits close enough to that line to name it. When the morning briefing is held back because a resting heart rate or respiratory rate reading has not arrived yet, the app records that it waited, for how many seconds, and whether the score it was waiting on was complete by the time it gave up. That is a fact about when data reached your device, not about what the data said — no reading, no value, no measurement leaves the device. It is listed in the table below with everything else.

Wellness disclaimer

Lepo is not a medical device. Scores and insights are for general wellness and informational purposes only — they are not medical advice, diagnosis, or treatment. Always consult a qualified health professional before making decisions about your health.

Analytics

Lepo sends usage analytics to PostHog, hosted in the European Union at eu.i.posthog.com. PostHog processes this data on Lepo's behalf. Nobody else receives it.

What is sent Why
Install ID, a random UUID generated on your device the first time you open the app There is no sign-in, so this is what makes it possible to understand usage per install. It is not an Apple ID, an account, or the advertising identifier, and it is not linked to any identity.
Whether the build is debug, TestFlight, or production, and whether the event came from iPhone, iPad, or Watch To keep test builds out of real numbers, and to tell phone behavior apart from watch behavior.
What you did in the app: which onboarding step you reached and whether you finished, whether the Health access request completed, notification permission state, which metric tile was tapped, which time range you chose, when you inspected the graph, settings changes such as theme and day count, how many complications are installed and of which kinds, and that you opened a morning or evening notification — along with which stage of the morning schedule it came from and, when the briefing was held back waiting for a resting heart rate or respiratory rate reading to arrive, how many seconds it was held and whether the score it was waiting on was complete by the time it gave up To see which parts of the app get used and where people get stuck.
Refresh and sync diagnostics: whether a background refresh completed or was skipped and which kind of refresh it was, how long it took and how long each internal stage of it took, how stale the cached data was in minutes, which kind of Health query failed, how many times a refresh asked each kind of complication to reload and the smallest and largest number of kinds a single refresh asked for, how a complication drew the small bars under its graph — from the stored per-period values, from a reconstruction of them, or not at all — along with how many of those periods it had and how many hours each one covers, whether the watch accepted or refused the purchase status its paired iPhone handed it and on what grounds, whether the iPhone was able to hand that status over at all and what stopped it if not, and error codes and messages Widgets and complications go out of date in ways that are invisible from the outside. These events are how that gets found and fixed.
The paywall and purchases: which part of the app opened the paywall, and for a purchase that was started, canceled, completed, or failed — the product identifier, whether it is the monthly, yearly or lifetime plan, the amount charged or the price shown along with its currency, whether a free trial or an introductory offer applied, and Apple's identifiers for the subscription and for the individual charge. A failure carries the error alongside it. Tapping Restore Purchases is recorded on its own, and so is backing out of it or having it fail. To know which products people buy and what they are worth, to see where the paywall is reached from and where it is abandoned, and to find purchases that break.
What happens to a subscription afterwards: that it renewed, lapsed, changed plan, converted from a trial, entered a billing retry or grace period, was switched off or back on for the next renewal, or was refunded — with the amount where money moved, the same two Apple identifiers as above, the date it took effect, and the date the app found out. Where a subscription stopped renewing, Apple's reason for it: that it was turned off, that a payment failed, that a price rise was not accepted, or that the plan is no longer sold Apple tells the app about a renewal or a lapse only while the app is running, so a subscription that ended with the app closed is a difference found later rather than something seen happening. Without both dates, every ending gets filed to whenever its owner next opened the app. Knowing that a subscription was switched off, and why one ended, is the difference between a plan people stop wanting and a payment that simply failed — the second is worth fixing rather than accepting.
Whether this install currently has Pro, on which plan, whether it is in a trial, and when it first became Pro To read every other number above separately for paying and non-paying installs. This is current state, kept alongside the install identifier rather than sent on every event.
Turning analytics off, and turning it back on So that events stopping is distinguishable from an app that crashed or was deleted. Switching off sends one last event saying so, and then nothing further is sent.

Tile names, never tile values. Tapping the sleep tile sends the word "sleep". It does not send how long you slept.

Turning it off

All of this is optional and the switch is in the app, not in an email to me. Open Settings, find the Privacy section, and turn off Share analytics from this device. Nothing further is sent from that device.

Switching it off sends one final event recording that you switched it off, before the sending stops. That is deliberate rather than sneaky: without it, a device going quiet is indistinguishable from a crash, and the crash would get chased instead of respected. It carries the same install identifier as the rest and no health data.

Each device has its own switch, because each has its own install identifier. Turning it off on your iPhone does not turn it off on your Apple Watch.

Your iPhone tells your Apple Watch whether you have Lepo Pro. The watch often cannot check a purchase for itself, and without being told it would show the free version to someone who has paid. What crosses is the purchase status and the date a subscription runs until, nothing more. It goes straight between your own two paired devices over Apple's Watch Connectivity, the same way the app already passes them health figures they both need, and it goes nowhere else — not to a server of mine, not to PostHog, not off the pair at all.

Purchases go through Apple's App Store. Your card and payment details are handled entirely by Apple and never reach Lepo. What does reach Lepo is the amount a purchase charged and its currency, listed in the table above. Two of Apple's identifiers go with it: one for the subscription and one for the individual charge. They identify the purchase, not you — neither is your Apple Account, and neither can be traced back to a person by Lepo. They are there so that a renewal seen by both your iPhone and your iPad is counted once rather than twice.

What the PostHog SDK adds on its own

iOS redacts the device name to just "iPhone" before the SDK sees it, so if you have given your device a name, that name is not transmitted.

On iPhone and iPad, crashes and unhandled exceptions are reported automatically.

Approximate location

Lepo does not request location access, does not use Core Location, and never sends a location. But events reach PostHog over the network, and PostHog looks up the IP address they arrive from to infer an approximate location on its servers: country, region, city, postal code, and rough coordinates. That inference is attached to events after they leave your device.

The app never learns where you are. What is inferred is roughly where the network you were on is, at city accuracy rather than GPS accuracy. It is real, it is worth telling you about, and it is not location tracking.

What Lepo does not do

Who is responsible for this data

Lepo is made by Tuomas Koponen, an independent developer in Finland, who is the data controller for everything described on this page. There is no company behind it — it is one person.

Reach him at privacy@lepohealth.app.

Why Lepo is allowed to collect it

Health data is not collected at all, so this only concerns the usage and diagnostic data described above.

That data is processed on the basis of legitimate interests: understanding which parts of the app get used, and finding faults that are invisible from the outside — a complication that has quietly stopped refreshing is the usual example. It is not used to profile you, to target advertising, or to make any decision about you.

You can object to it at any time, and you do not have to give a reason. You do not have to ask me either — the switch described under Turning it off above stops it on the spot. See your rights below.

How long it is kept

Analytics events are kept for one year and then deleted automatically. Nothing is kept longer than that, and there is no archive of older events.

Your rights

If you are in the EU or EEA, you can ask for any of the following:

Because there are no accounts, the only handle on your data is the random install identifier described above. Your iPhone and your Apple Watch each generate their own, and the two are not linked, so a request needs the identifier from every device you use Lepo on — otherwise only part of your data can be found.

You can find it in the app under Settings, in the Privacy section, labeled "This device's ID". On iPhone, tapping it copies it. On Apple Watch it is shown but cannot be copied, because watchOS gives apps no pasteboard — read that one off the screen. Quote both when you write, or only half your events can be found.

You can also complain to the data protection authority in your own country.

Contact

Privacy questions, and any of the requests above, go to privacy@lepohealth.app.

Last updated 31 August 2026