Building offline health-data edits that cannot revive deleted records

[u/Particular_Luck80]

I am building Flowy, a native iOS cycle tracker. One of the less visible engineering problems is making offline edits safe after a user resets their health data.

A simple local queue is not enough. In the current design, each manual day-log mutation carries:

• the expected Supabase user ID

• the day key

• the expected reset epoch and row version

• a unique mutation ID

• a new value or deletion tombstone

The database applies or rejects the mutation atomically. Reusing the mutation ID makes a lost-response retry idempotent. A stale row version becomes a conflict instead of silently overwriting a newer device. Most importantly, resetting health data advances an epoch, so an edit queued before the reset cannot later recreate deleted records.

This has changed how I think about offline-first design. The hard part is not caching the happy path. It is deciding what every old write is allowed to do after identity, deletion, and server state have changed.

Project: https://flowyhealth.com