What Base Does With Your Data

The authoritative version is in the app

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

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 never uploaded to a Base server. Exactly one optional feature reads them, the body fat estimator, and it is off until you turn it on.

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 five network calls

Everything except the first can be switched off, and three of them are off until you turn them on.

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. Google's Gemini API, behind five optional features. They work out of the box on a free daily allowance of AI use per account, and the first time you use one the app asks whether it may send your request to Google. Say no and nothing is sent. On the allowance, requests pass through Base's server, which adds Base's key and stores nothing except a daily total of what your AI use cost; with your own Gemini key, added in Settings › AI, they go straight to Google with no limit. One of the five, the body fat estimator, needs a second switch of its own.

The plate scan sends one resized photograph and nothing else. The workout coach sends what you typed plus your sex, age, bodyweight, experience and goal. The endurance coach sends that plus a summary of your training history, which means your twelve-week run and ride counts, your average weekly mileage, your longest sessions, your VO₂max, your estimated maximum heart rate and your threshold pace and FTP. The coach chat can reach the most: your recovery, sleep, heart-rate and step history, your workouts and one session in full, your bodyweight trend, your lifts, your macros, your measurements and your goals, each only when a question needs it, plus up to four photographs you attach to a message yourself. The body fat estimator sends three progress photos a week, resized on the device, with your sex, age, height, trend bodyweight and the tape estimate. Those last two are the only things that read your progress-photo archive, they share one switch, and it is off until you turn it on: with it on the chat can also look at your first set beside your most recent one when you ask how lean you are, up to four images, with the dates and your trend weight and nothing else.

The endurance coach and the coach chat are health data leaving the device, they are the only two places in the app where that happens, and that is why neither sends anything until you have said yes. None of the five is ever sent your location or any part of a route, and none is sent your name or email. The only photographs that travel are the one you point the scanner at, the ones you attach to a chat message, and the three the body fat estimator reads once you have turned it on. See the AI scanner and the privacy page for the full list.

4. Product analytics. Which screens are opened, which actions are taken, and when something fails, sent to PostHog. It is tied to your account rather than anonymous: your email address, your display name, your signup answers and the numbers you entered yourself go with it, including your height, age, bodyweight and your calorie and macro targets. What never goes with it is anything read from Apple Health or Health Connect, and never a route, a photo, a food name, a note or a search term. Turn it off in Settings › Privacy and nothing further is sent.

5. Map imagery. A workout with GPS is drawn on a real map, and the picture behind it comes from your device's own map service. The request asks for imagery of an area; your route is drawn on top afterwards, on the device, and is not part of the request. With no network there is no background and the route still draws.

That is the complete list.

What is not in the app

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

• No crash reporting service
• No advertising identifier
• No attribution or fingerprinting SDK
• No session or screen recording: the code for it is not installed
• No cross-app or cross-site tracking
• No Apple Health or Health Connect data in any analytics event, ever
• No route, photo, food name, note or search term in any analytics event
• 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 does not do it.

One clarification on the crash line, because "no crash reporting service" is true and easy to over-read: when a screen fails, the app sends one analytics event saying that it crashed and which screen it was. No message, no stack trace, nothing about you. There is no crash reporting SDK in the app and no crash log is ever uploaded.

What Base writes back

Three things, all of them yours and all with your permission: the bodyweight you logged, the nutrition you logged, and a session you recorded on your watch. Everything else in the health relationship is read-only.

Deleting your account

Settings › Account & Backup carries account deletion. It erases your account and everything in it, from the server and from this phone. It is immediate and it cannot be undone.

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 no analytics at all. There are analytics, they are tied to your account, and the switch is in Settings › Privacy. What is not in them is anything your health app measured.

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

Thinking the AI scan is always on. It sends nothing unless you use it, and it asks before the first time.

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.