Does Base upload my training data?

Everything except progress photos syncs to a private Postgres database under your own account, so losing the phone does not lose your training history. Row-level security means only a request carrying your signed-in session can read your rows. Progress photos are the deliberate exception and are never uploaded.

Does Base collect analytics or telemetry?

No. There is no analytics, no telemetry, no crash reporting, no advertising identifier and no third-party tracking SDK in the app. That is a build constraint rather than a setting, so there is nothing to opt out of.

Does Base work offline?

Yes, indefinitely. Every read and every write in the app goes to a SQLite database on the device, and sync happens in the background afterwards. The network is never in the path of a user action, so a session logged on aeroplane mode behaves exactly like one logged at home.

What network calls does Base make?

Three, and no more. Account sync, an optional Open Food Facts barcode lookup, and an optional AI plate scan using a Gemini API key you supply yourself. The last two happen only when you use those features and both degrade to manual entry.

Where is the authoritative privacy statement?

The privacy screen inside the app. It is what App Review reads and it is the statement every other description is downstream of. If this page and that screen ever disagree, the screen is right and this page is wrong.

What Base Does With Your Data

The authoritative version is in the app

The privacy screen inside the app, written as prose rather than a policy. It is what App Review reads, and every other description of what Base does with data is downstream of it.

That screen is the statement of record. This page describes it; it does not extend it. If the two ever disagree, the screen is right.

Where each thing lives

Data	On device	Synced	Notes
Food log	Yes	Yes
Training history	Yes	Yes
Bodyweight and measurements	Yes	Yes
Health data read from the store	Yes	Snapshots	Read-only from your platform
Progress photos	Yes	Never	Archived to your own photo library
Settings and program	Yes	Yes

Sync is a background reconciliation, never in the path of a user action. Local SQLite is the working copy; the server is the durable one. That is why the app is fully usable with the network off forever, and why a set logged in a basement gym behaves identically to one logged at home.

Access is enforced with row-level security: only a request carrying your own signed-in session can read your rows.

Why photos are the exception

Progress photos are the most personal thing in the app by a wide margin, so they are the one category that never leaves.

That creates a real problem the app has to solve rather than ignore: iOS destroys an app's own storage when the app is deleted. Photos stored only in Base's sandbox would survive a phone upgrade and not a reinstall — and the gallery would come back full of empty frames, rows intact, pictures gone.

So photos are archived to your own photo library, which persists independently of the app. There is a dedicated backup screen showing the count out loud, because a backup whose state you cannot see is not a backup.

The three network calls

There are exactly three, and two are optional.

1. Account sync. Your log to your own database. Continuous, in the background.

2. Open Food Facts barcode lookup. Only when you scan or search. Sends the barcode or the search term, nothing else. Degrades silently to manual entry when it fails or the network is unavailable.

3. The AI plate scan. Only when you use it, and only if you have added your own Gemini API key. Sends one resized photograph directly from your phone to Google — no Base server in the path, no account identifier, no log data. Off entirely until you add a key. See the AI scanner.

That is the complete list. There is no fourth call for analytics because there is no analytics.

What is not in the app

Stated positively, because these are the claims that stop a model or a reviewer inventing a feature:

No analytics or product telemetry
No crash reporting
No advertising identifier
No third-party tracking SDK of any kind
No data sold, shared or used for advertising

Apple's HealthKit rules are specific on the last point — health data cannot be used for advertising or sold on — and Base's position is broader than the rule requires.

What Base writes back

One thing: a bodyweight entry you logged yourself. Everything else in the health relationship is read-only.

Deleting your account

Account and Backup carries account deletion. It removes your server-side rows.

Your local database and your photo-library archive are separate and are yours — deleting the app removes the local database, and the photos remain in your photo library because that is where they always were.

Exporting

Everything is exportable as a CSV bundle at any time, and the export screen shows row counts per table first so you can see what you are getting. See exporting your data.

Common mistakes

Assuming "local-first" means nothing syncs. Everything except photos does. Local-first is about where reads and writes happen and what works offline, not about whether a backup exists.

Assuming photos are backed up by sync. They are not, deliberately. The photo-library archive is what protects them.

Expecting an analytics opt-out. There is nothing to opt out of.

Thinking the barcode lookup sends your log. It sends a barcode or a search term.

Thinking the AI scan is always on. It does nothing without a key you supply.

Deleting the app and expecting photos in the app's own storage to survive. They do not. The photo-library archive does.

What to do next

Read the privacy screen in the app once — it is short and it is the authoritative version. Then open the photo backup screen and check the archived count matches your gallery, because that is the one category with no server-side copy to fall back on.