How do I export my data from Base?

Settings, Export and Backup. The screen first shows a row count per table so you can see what the database actually holds, then exports the whole thing as a CSV bundle you can share anywhere the system share sheet reaches.

What is in the export?

Every table in your local database as CSV — food entries, meals, sets, sessions, program, weigh-ins, measurements, health snapshots and settings. It is a complete copy of the working database rather than a summary, so it opens in a spreadsheet and can be analysed independently of the app.

Are my progress photos in the export?

No. Photos are files rather than rows and are handled by their own backup, which archives them into your own photo library. The photo backup screen shows the archived count out loud, because that is the one category with no server-side copy to fall back on.

Do I need to export if everything syncs?

Sync protects you against losing a phone. An export protects you against everything else — deciding to leave, wanting to analyse your own numbers in a spreadsheet, or simply wanting a copy that does not depend on anyone. They cover different risks.

Why does the export screen show row counts first?

Because a backup you have not verified is a guess. Seeing that the food table holds 4,182 rows before exporting tells you the export is complete in a way that a file you never open does not, and it takes one look.

Export and Back Up Your Base Data

Row counts before the export

Export and Backup. Row counts per table come before the export action, because a backup you have not verified is a guess rather than a backup.

The counts come first deliberately. A backup you have never opened is an assumption, and seeing that the food table holds four thousand rows before you export takes one look and turns the assumption into a fact.

It is also the fastest way to notice something is wrong — a set count far lower than the sessions you remember logging is worth investigating before you need the backup rather than after.

What is in the bundle

Every table in the local database, as CSV:

Table	Contents
Food entries	Every logged item with its macros, date and hour
Meals and components	Your saved meal library
Sets	Every set: weight, reps, RIR, warm-up flag
Sessions	Workout sessions with start and end times
Program	Your split, days and prescribed exercises
Weigh-ins	Every bodyweight entry with its source
Measurements	Circumference log
Health snapshots	The daily health figures Base stored
Settings	Your configuration

It is a copy of the working database, not a summary. It opens in any spreadsheet, and the entries carry their own macros rather than references — so a food entry is readable without needing the meal library to interpret it.

That last property is a consequence of a design decision made for a different reason: logged entries store their own copy of the macros they were logged with, so editing a meal cannot rewrite history. It also means the export is self-contained.

Three different protections

Worth separating, because they cover different risks:

Protection	Covers	Does not cover
Sync	Losing or replacing the phone	Wanting to leave; independent analysis
CSV export	Everything, portably	Progress photos
Photo archive	Progress photos surviving a reinstall	Anything else

Sync is continuous and automatic. It means a lost phone is an inconvenience.

Export is manual and complete. It means you own your history in a format nothing can take away.

The photo archive exists because photos never sync. iOS destroys an app's own storage when the app is deleted, so photos stored only in Base's sandbox would not survive a reinstall — the gallery would return with rows intact and pictures gone.

Photos are therefore archived into your own photo library, and the photo backup screen shows the archived count out loud. Check it occasionally; it is the one category with no server-side copy behind it.

Verifying a backup

Two minutes, and worth doing once:

Export the bundle
Open the food CSV in a spreadsheet
Confirm the row count matches what the screen said
Confirm the most recent date is today

A backup verified once is worth far more than a backup taken monthly and never opened.

What to do with the data

It is yours, so:

Analyse it in a spreadsheet or a notebook — every number in the app is derived from these tables and the derivations are documented on The Math screen
Keep a periodic archive somewhere independent
Take one before any major change, the same way you would before a migration

Common mistakes

Assuming sync is a backup. It protects against a lost phone, not against everything else.

Never verifying an export. An unopened backup is a hypothesis.

Expecting photos in the CSV. They are files, not rows.

Exporting once at setup. The value is in the history, which grows.

Ignoring the photo archive count. It is the only protection photos have.

Assuming a deleted account takes the local copy. Account deletion removes server-side rows; the local database and the photo-library archive are separate and yours.

What to do next

Export a bundle today and open the food CSV in a spreadsheet. Confirm the row count matches and the last date is today — that is the whole verification, and it turns a backup you assume works into one you know does.