Designing offline-first when there's no server

The author of this app has built a system without a server, opting for an offline-first approach. This means the database is stored as a SQLite file on the phone, and there are no accounts, sync, or API involved. At first glance, this seems simpler than a client/server app. However, removing the server does not eliminate the hard problems; it simply relocates them.

With no server as an authority to reconcile against, there is no refresh escape hatch from the backend. If the local data is incorrect, it is incorrect permanently. Any bug becomes a data-integrity bug. This change in perspective affects how one treats writes. Instead of thinking "I'll fix it in a migration later," one must consider what the correct value should have been to begin with.

The author recounts a specific mistake they made in their app. They computed a summary on demand, based on underlying records. When they edited a figure months later, every past period silently changed because they were being recalculated from the updated data. Nothing crashed, no errors were thrown. The history simply rewrote itself, and the author only noticed because a total they remembered was different.

The solution the author found was to freeze the summary at the moment the period closed and store it as a snapshot. From then on, that period is read, never recomputed. Any screen displaying those figures checks if the period is closed before allowing any changes. This approach, similar to event-sourcing, ensures derived data remains accurate once the period is finalized.

Offline-first design also brings challenges regarding backups. The author's app dumps every table to a file that the user controls, including soft-deleted records. However, they emphasize the importance of keeping deleted rows within the dump. Restoring a backup that resurrects deleted data can be worse than not restoring at all.

Moreover, not all settings are data. Things like theme and language should belong to the device, not the backup. Restoring on a new phone should not import old preferences like dark-mode settings. The biggest design failure the author encountered was adding a new table without including it in the dump-and-restore routine. This oversight caused the new table to disappear upon restoration, with no error messages or warnings.

The author's solution was to explicitly list all tables in the backup routine, ensuring any new additions require updating this list in the same commit. This makes the omission visible in code review, preventing unexpected data loss. Overall, while offline-first design offers many benefits such as no hosting, no authentication, no breach surface, and no subscription costs, it is not without its challenges.

You still need to manage a database, version your schema, and handle backup and restore - just on a device you don't control, where the user can accidentally uninstall the entire production environment.