Privacy Policy

2.1 Data stored on your device

The App keeps the following in its local storage on your device. This stored record is never uploaded. We receive no copy of your history, your notes, your goals, or your settings file. Some of the same values are, however, sent separately as analytics events at the moment they happen, unless you have turned analytics off — section 2.2 lists exactly which, and describes the switch. These are two different things: your stored history stays on the device, while individual actions are reported as they occur.

• Focus and sleep sessions: duration, planned duration, start and completion timestamps, mode, whether the session completed or was interrupted and why, your 1–5 quality rating, logged distractions, sleep quality rating, your free-text morning journal note, whether you felt refreshed, wake time, and which sound you used. The App keeps up to 1,000 sessions; older ones are dropped.
• Settings: timer durations, sound and volume preferences, selected sound, all notification settings and reminder times, language, onboarding flags, install date.
• Goals: your daily target and each goal you create, including the title you type.
• Custom timer presets: including the name you type (up to 10 presets).
• Streaks and achievements: badges and when they were unlocked, current challenge, longest streak, streak-freeze state.
• Apple Health readings copied into the App: see section 7.
• Weekly report cache: the computed report (score, peak hours, mode distribution, totals, streaks, recommendations).
• Subscription state: your current tier (free / monthly / annual / lifetime).
• Timer state and download status of premium sounds.
• Downloaded premium sound files (.mp3) in the App's Documents folder.
• A CSV export file, if you use the export feature, written to the App's cache folder and handed to the iOS share sheet. The App does not upload it anywhere; what happens after you choose a destination in the share sheet is up to you and that destination.

What is stored here and genuinely goes nowhere. From the list above, the following never appears in any analytics event, crash report, export or network request:

• the free text you type — goal titles, custom timer names, and your morning journal note;
• whether you felt refreshed, and your wake time;
• the stored session records themselves, including the start-time field they hold;
• the contents of the cached weekly report — its score, peak hours, mode distribution and recommendations. Opening the report is reported as an event; what the report says is not;
• your Apple Health readings, both as numbers and as anything computed from them (section 7.2, including the one residual case it names for installations upgraded from an older version);
• the live state of the timer.

Two files are also never uploaded by the App: the CSV you create with the export feature (it is written to the App's cache folder and handed to the iOS share sheet — after that it is up to you and the destination you choose), and the premium sound files you download.

One thing that list cannot hide, and we would rather say than let you assume otherwise: every event is timestamped by the analytics SDK at the moment it is sent. So even where a stored time field never leaves the device, the time at which you did something is visible to the recipients of the corresponding event.

Everything else in that list has a counterpart in section 2.2. The duration, mode, outcome and rating of a session, the distraction types you log, your sleep quality rating, the sound you used, your language and notification settings, your subscription tier, your goal targets and your badges are all reported as events or as properties at the moment they occur — not as a copy of the stored record, but as the same information.

2.2 Analytics and product usage data

In one sentence: we can see which screens you open, how long your sessions last, what you rated them, which sounds and features you use, and what you bought — and we cannot see a single word you typed.

The App sends usage events to two analytics services at the same time:

• Firebase Analytics (Google) — configured on the iOS build and on the Android build
• PostHog Cloud EU (PostHog)

Both services receive the same events, apart from two differences: Google's standard purchase event — which carries the product identifier, value and currency of a completed purchase — is sent to Firebase Analytics only, and PostHog additionally records each change of a device-level property as its own small event (see below).

You can turn all of this off. Settings → Privacy & Safety → Usage Analytics is a switch that stops everything described in this section. It is on by default — the App does not ask you before the first event is sent — and your choice is stored on your device and survives restarts and app updates.

While the switch is off:

• no event, no screen view and no device property is sent to Firebase Analytics or to PostHog;
• the App additionally turns off the two SDKs' own automatic collection, so Firebase's automatic events and PostHog's app-lifecycle events stop as well;
• if analytics has been off since you first opened the App, the PostHog client is never created at all, so no PostHog person profile exists for your installation;
• the breadcrumb trail written into crash reports (section 2.3) stops too — not only the names of the analytics events, but the App's own markers as well ("App launched", "Timer started: pomodoro 1500s", "Session recorded", which sound could not be played) — and so do the details attached to a handled error, such as which sound or which subscription plan was involved.

What the switch does not stop — we would rather say so here than let you discover it later:

• crash reports and error diagnostics to Firebase Crashlytics (section 2.3) keep running — but with the switch off they carry the crash or the error itself and the name of the code path it happened in, and nothing about what you were doing before it;
• RevenueCat (section 2.4) keeps running. It is how a purchase is recognised at all, and switching it off would take away the premium features you paid for;
• the plain network facts in section 2.5 — the premium-sound download, the over-the-air update check, and the IP address that any request reveals.

Turning analytics off sends nothing at all: there is deliberately no "opted out" event. Turning it back on sends one event recording that you did, and where from — at that moment you have consented again.

What is in an event. Each event has a name and a small set of parameters. Categories of events:

Device-level properties attached to your events. These are attached to events rather than sent once, so they travel with everything above. There are two groups.

Set by the App: subscription status and tier; a bucketed session count (0, 1-5, 6-20, 21-50, 51+); a bucketed days-since-install; whether sound is on; your app language setting; whether notifications are enabled; whether you granted the iOS notification permission; your selected sound; the app version; which timer mode you use most often; whether you use goals; whether you use the sleep timer; whether you bought or skipped at the end of onboarding; and whether Apple Health is connected. Every event is also tagged with whether it came from a development build or from the released app.

Added by the SDKs themselves: the PostHog SDK attaches, on its own, device type, manufacturer, the device model name as reported by the operating system (for example "iPhone 15 Pro" — not the name you gave your phone), OS name and version, app name, bundle identifier, app version and build number, whether the app is running in a simulator, locale and time zone, and it generates app-lifecycle events (installed / updated / opened / backgrounded). The Firebase SDK likewise attaches its own identifiers and device information; those are produced inside Google's SDK rather than by our code, so we describe them from Google's documentation rather than from ours.

One consequence worth knowing if you ever compare volumes: in PostHog, each change to one of the App-set properties above is recorded as its own small event, so PostHog holds more events than the number of actions you took.

Identifiers. The App never calls the "identify this user" function of either service — there is no user ID to give them. Each service generates its own anonymous, per-installation identifier and attaches it to the events. PostHog is configured to build a person profile around that anonymous identifier, which means your events are grouped together across sessions on that installation. A few event parameters (a session id, a goal id) are millisecond timestamps generated on your device — the moment a session finished, the moment a goal was created — and used as local identifiers. They reveal that timing to the recipient, but they are not linked to you.

2.3 Crash reports and error diagnostics

In one sentence: with Usage Analytics off, Crashlytics still receives crashes and handled errors — the stack trace, the error, and the name of the code path it happened in — and nothing about what you were doing before them.

• Firebase Crashlytics (Google) receives crash reports. While analytics is switched on, it also receives a breadcrumb log: the name of every analytics event listed above, and the App's own markers alongside them ("App launched", "Timer started: pomodoro 1500s", "Session recorded", which sound could not be played), written into that log as they happen — so a crash report then contains a trail of what you were doing. Handled (non-fatal) errors are reported too, with a short context string naming the code path that failed; the attributes attached to such an error — which sound, which subscription plan, which notification type — follow the same switch as the breadcrumbs.
• PostHog receives a copy of the same handled errors through its error-tracking feature.
• What the analytics switch in 2.2 does and does not cover here. It covers the whole breadcrumb log, the attributes of a handled error, and the PostHog copy of the errors — all of which stop with the switch off. It does not cover Crashlytics itself: the crash report and the bare non-fatal error keep going. If you do not want those either, the only way to stop them is to uninstall the App.
• Expo receives one crash-related item as well: if the App crashed fatally the last time you used it, the text of that error is attached to the next update check. See 2.5.

Crash and error reports contain stack traces and technical state, not your notes, goals or Health readings. With Usage Analytics off that is all they contain; with it on, they additionally carry the breadcrumb trail and the error attributes described above.

2.4 Purchase and subscription data

Purchases run through Apple's In-App Purchase system and are managed with RevenueCat.

• On every cold start of the App, and whenever your subscription status changes, the App contacts RevenueCat — even if you have never made a purchase. Opening the paywall also fetches the product catalogue from RevenueCat.
• RevenueCat's SDK creates an anonymous app user ID for the installation. The App does not set, read or store it, and never sends RevenueCat your email address, name, or any custom attribute — there are no such calls in the App.
• When you buy or restore, Apple's StoreKit handles the transaction with your Apple ID and RevenueCat validates it. The App itself only reads back which product identifier is active.
• On iOS, the App turns on Apple Search Ads attribution: Apple's AdServices attribution token is collected and passed to RevenueCat, so a purchase can be attributed to the ad campaign that led to the install. This is Apple's own privacy-preserving attribution. The App does not show the App Tracking Transparency prompt and contains no advertising SDK, so iOS does not give it the advertising identifier (IDFA).
• On Android builds the purchase SDK is not configured, and the App sends nothing to RevenueCat there. Firebase Analytics and Crashlytics, however, are configured on Android — the Android exception applies to RevenueCat only.

What reaches the analytics services. A completed purchase is reported to both Firebase and PostHog with the subscription tier, the price, the currency and the place in the App you bought from; the product identifier additionally goes to Firebase Analytics inside Google's standard purchase event. A cancelled, deferred or failed purchase is reported to both services with the product identifier and, on failure, the store's error code.

2.5 Data your device reveals simply by connecting

Every network request the App makes reveals your device's IP address and its user-agent string to whoever receives it. This is how the internet works; it is not something the App adds or can remove. From an IP address, a recipient can generally infer approximate location — typically country, region or city, not a street address. The recipients are listed in section 4.

Your IP address is not masked before it reaches the analytics services, and it is not stripped there at our request. While analytics is switched on, events go to Firebase and to PostHog over a connection that carries your IP address, and each service can derive an approximate location from it. The App does not ask either service to skip that step: the relevant PostHog setting is left at the SDK's default, which permits IP-based location enrichment. Whether the derived location is then retained, and how coarse it is, is controlled in each service's own console rather than by the App.

Two further requests are worth naming explicitly:

• Premium sounds are downloaded on demand from a Cloudflare R2 bucket. The request is a plain file download with no identifier attached, but the file name reveals which sound you chose, and the request reveals your IP and the time.
• Over-the-air updates. On each cold start the App asks Expo's update service whether a new JavaScript bundle is available. That request carries an installation identifier (EAS-Client-ID) generated by the update library, your IP address and user agent, and technical fields used to match an update to your build: platform, protocol and API version, runtime version, and build environment. If the App crashed fatally the last time you used it, the text of that error — truncated to 1,024 characters — is sent with this request too, in a header the update library adds so that a broken update can be rolled back. That header is added by Expo's update library rather than by our code; the list above is what the library sends on iOS.

2.6 What the App does not collect

None of the following happens in the App:

• No accounts. No registration, no login, no password, no OAuth, no server of our own. The "Log Out" button in Settings does not log out of anything — see section 9.
• No name, email address, phone number, or postal address. The App never asks for them and has no field to enter them.
• No location APIs. The App does not request or use location permission and contains no location code. (See 2.5 for what an IP address alone reveals — that is a different thing, and it does happen.)
• No advertising SDKs, no ad networks, no IDFA, no App Tracking Transparency prompt.
• No microphone, camera, contacts, photos, or calendar access.
• No push notifications. All notifications are scheduled locally on your device; the App does not register for a push token and there is no push server. See section 6.
• No free text. Goal titles, custom timer names and morning journal notes never appear in any event.
• No Apple Health value leaves the device, and neither does anything computed from one. See section 7.2 for the small amount of Health-related metadata that is sent instead, and for one residual case on installations upgraded from an older version.
• We do not sell your data, and there is no data broker in the chain.

5.1 Where the data lives

On-device data is stored in the App's private container using the operating system's standard app storage (a local key-value store plus files in the App's Documents and Caches folders). It is readable only by the App and by anything with access to your unlocked device.

5.2 Security

The App does not apply its own encryption to the data it stores. Its own code does not use the iOS Keychain or a secure enclave (what the third-party SDKs do internally is governed by their own documentation). Your data is protected by the device encryption and file protection that iOS applies to every app's container — that is Apple's protection, not something the App adds. Network requests use HTTPS.

5.3 Backups

The App's key-value store — sessions, settings, goals, achievements, and the copies of your Apple Health readings — is marked as excluded from device backup, so it is not copied into an iCloud or computer backup. Files in the App's Documents folder are not marked as excluded: this covers downloaded premium sound files and the analytics SDK's small local file containing its anonymous identifier and its queue of not-yet-sent events. Those may therefore be included in your device backup, which is managed by Apple under Apple's terms.

5.4 How long data is kept

On your device: indefinitely, until you delete it or uninstall the App. There is no time-based deletion. Two limits exist: session history is capped at the most recent 1,000 sessions, and the Health history arrays keep the most recent 14 daily readings each.

At the third parties in section 4. We keep no separate copy of any of it — we have no server and no database — so these periods are the ones that matter. Some are fixed by the provider and some are a setting we choose in that provider's console; we say which is which rather than guessing:

If a period above is described as a console setting and you want the current number, email the address in section 13 — that is a question we can answer precisely, unlike a request to find your individual records (see the end of section 9).

7.1 What the App reads, and when

If you tap "Connect Apple Health" on the Health screen, iOS shows you its own permission sheet. The App requests read access to exactly three data types:

• Heart rate variability (SDNN)
• Resting heart rate
• Sleep analysis (in bed, awake, core, deep, REM, unspecified)

It reads the most recent HRV and resting heart-rate sample from the last 24 hours, sleep from the last day, sleep stages from last night (yesterday 18:00 to today 12:00, local time), and up to 14 days of HRV and sleep history. Reads only happen when the App is in use and at most once every 30 minutes; there is no background delivery of Health data.

The App never writes anything to Apple Health. The permission request asks for read access and an explicitly empty set of write types, and the App contains no Health-writing code at all. You may still see a "write" purpose string in iOS — the HealthKit framework requires that text to be present in any app that links it, and Apple's build validation rejects the app without it. It does not mean the App writes.

Onboarding does not request Health access; only the button on the Health screen does. The App is fully usable without Apple Health. Without it, the session-length suggestion falls back to a time-of-day model. The recovery score is computed from whatever inputs exist: with no Apple Health data and no in-app sleep-timer session it reads zero, but if you have used the App's own sleep timer, the score is computed from that instead.

A technical caveat worth knowing: for privacy reasons, HealthKit does not tell an app whether read access was denied. When the App shows Health as "connected", that means you answered the permission sheet — not necessarily that you granted access.

7.2 Do your Health data leave the device? — Direct answer

No Apple Health value leaves the device, and, with a single exception this section names in full at the end, neither does anything computed from one. No HRV number, no resting heart rate, no hours slept, no sleep-stage minutes, no sleep score, no recovery score, and no bucket, band or rounded version of any of them is included in any analytics event, crash report, weekly report, CSV export, widget, or network request. We checked every analytics call in the App, the weekly-report generator, the CSV export, the widget bridge and every network destination to confirm this, and the App's test suite contains a check that fails the build if a new analytics call names a Health value or anything computed from one. That check reads the source code, so it cannot see a value that reaches an event through an ordinary variable; the one case where that happens today is described at the end of this section, because we would rather write it down than leave it for you to find.

Session lengths the App computes for you. The App can work out how long your next session should be. When Apple Health is connected, that number is computed partly from your heart-rate variability, your resting heart rate and your sleep — so the number itself is Health-derived, even though it looks like a plain timer duration. Every event about such a session therefore omits the length: what is sent is a label saying the length was computed rather than chosen (adaptive as opposed to preset), the mode, the outcome, and — for an interrupted session — the percentage of it you completed. The absolute seconds are dropped from the event and from the crash-report breadcrumb alike. The "recommendation applied" event now carries no parameters at all.

That same adaptive label is used when the App computes a length without Health data, from your own session history or the time of day. That is deliberate: if only the Health branch dropped the number, the mere presence of a duration in an event would reveal that you have no Health data, and the disclosure would simply move from the value to its absence.

What is still sent, and it is all metadata rather than measurement:

• that you answered the Health permission sheet, and whether it came back granted or denied;
• a device property recording that Apple Health is connected;
• the adaptive / preset label described above.

All three follow the analytics switch in section 2.2 and stop entirely when you turn it off.

One residual case, on installations upgraded from an older version. In versions before this one, choosing the "AI" timer mode also wrote the two lengths it had just computed — the focus length and the break length that follows it — into your saved timer settings. The current version no longer writes them there, but values already saved on your device are not erased, and they cannot be told apart from lengths you set by hand.

Where this surfaces: when a focus session ends, the App sets up the next break for you, and when a break ends it sets up the next focus session. If you start that next session, the saved length travels with the "session started" event as an ordinary preset length — the break length after a focus session, the focus length after a break. Nothing else in the App reads those two saved values, and the end of a break is not reported at all.

How it ends: both values are replaced by fixed presets the moment you pick any built-in mode other than AI (Pomodoro, Long Focus, Short Sprint or Flow), "Log Out" in Settings resets them to the App's defaults, and uninstalling clears them. We would rather name this than let the paragraphs above be read more widely than they are true.

7.3 Health data and third parties

No Apple Health data, and nothing computed from it, is sent to any third party by the current version of the App — with the single exception named at the end of 7.2, which affects only installations upgraded from an older version and stops as soon as a built-in mode is chosen. Not to Firebase Analytics, not to PostHog, not to Crashlytics, not to RevenueCat, not to an advertiser, not to anyone. There is nothing here to sell and nothing here to target you with.

The three metadata items listed at the end of 7.2 — that you answered the permission sheet, that Health is connected, and that a length was computed rather than chosen — go to the same two analytics services as everything else in 2.2, are covered by the analytics switch, and are attached inside PostHog to the anonymous person profile for your installation described in 2.2. That profile is not linked to your identity and is not used to target you.

7.4 Deleting Health data

Revoking Health access in iOS Settings → Health → Data Access & Devices stops further reads, but it does not delete the readings the App already copied to your device. Neither does "Log Out" in the App's Settings. Uninstalling the App deletes them. See section 9.

There is a consequence worth being explicit about. Because HealthKit does not tell an app that access was revoked (see 7.1), the App continues to treat Health as connected after you revoke it, and it still holds the readings it copied earlier. It keeps using them on the device — for the recovery score and the suggested session length — until they age out of the 14-day history or you uninstall. Nothing computed from them is sent anywhere (see 7.2); if you would rather the App did not hold them at all, uninstalling is what clears them.