How Backups Work in Walti

When I started building Walti, I knew I wanted to keep expense data on the device. It made sense for the kind of app I was building, but it also meant I had to think about what happens when someone wants to move their data elsewhere.

Walti lets you export your data to a file and import it back whenever you need to. There's no automatic cloud backup involved. You decide when to create a backup and where to keep it.

The export is only half of it, though. Importing the data back is where things get more interesting.

Thinking about restore

Expense data isn't just a list of amounts and dates. A backup holds your expenses, categories, payment methods and recurring rules, plus your currency, and the links between them have to make sense again after a restore.

So I wanted the backup to carry what Walti needs to rebuild your data, rather than treating it as a generic spreadsheet export. Amounts, for example, are written as plain text in one fixed format, whatever language the phone is set to, so 1.234,50 and 1,234.50 can't get mixed up between devices.

An import merges with what's already on the phone instead of replacing it. It only adds what's missing, so importing the same file twice doesn't create duplicates. If a file has nothing new in it, the Import button stays disabled.

This is also why importing CSV or JSON files from other apps isn't supported right now. Those files can have completely different structures, and mapping them into Walti's data model is its own project. For now, import is designed around backups made by Walti itself.

Keeping the format maintainable

The app won't keep the same data model forever. New features add fields or change how existing data is stored, and a backup made with an older version still has to import correctly.

Every backup file starts with a format name and a version number. Walti refuses files it doesn't recognise, and files from a newer version than it understands, instead of guessing what's in them.

The version has already changed once in a way that mattered. When I added "every 2 weeks" as an option for recurring expenses, an older copy of the app reading a new backup wouldn't have known that value and would have quietly turned those rules into monthly ones. So the format went from 2 to 3, and an older app now refuses the file instead. Backups in the old format still import fine.

Exporting the current state of a database is easy. Making sure that file still means the same thing several updates later is where most of the work is. I don't want the backup format to become something I have to work around every time I add a feature.

Backups and what comes next

For now, backups stay manual. I'm planning to add iCloud sync at some point, and that will change what a restore means. Today an import only adds what's missing, which is safe on a single phone. With sync, restoring an old backup could bring back expenses you deleted on another device and push them everywhere, so I'll need to rethink how the two fit together.