On the Ceum mobile app you can keep working when your device drops its connection. Cached data stays readable, a small set of surfaces stays editable, and any changes you make are queued and replayed automatically once you're back online. This is a mobile-only capability — the web app assumes a live connection.
What works offline
- Reading cached data — screens you've already loaded keep showing their last-known data instead of going blank.
- Adding and editing transactions and time entries — these two surfaces stay fully writable offline. Your change is applied to the on-screen list immediately and queued to sync later.
- Everything else becomes read-only — other surfaces (clients, projects, tasks, settings, and so on) still show cached data, but their create / edit / delete controls are disabled while offline, with a short hint explaining why. This avoids queuing changes that can't be reliably reconciled.
What stays saved after you restart
The app keeps an encrypted snapshot of its most important data on the device, so a cold start while offline still opens on real data rather than empty screens.
- The snapshot is written when the app leaves the foreground (not on every change), and restored once on launch.
- It's encrypted at rest with a per-device key, so the cached copy isn't readable off the device.
- It's deliberately small — it holds your settings, the primary list landings (work lists, transactions, time entries, subscriptions), the quick list, and the active timer — not everything you browsed. Details, calendar overlays, insights, mail, and search are re-fetched when you open those screens.
Changes waiting to sync
Changes you make offline go into a durable queue (the "outbox") that survives an app restart. The queue is smart about collapsing redundant work so the server only ever sees the net result:
- Editing something you created offline merges into that pending create — it still syncs as a single new record.
- Deleting something you created offline drops it entirely; nothing ever reaches the server.
- Repeated edits to the same record collapse to a last-write-wins result.
- Deleting a record drops any earlier queued edits to it, and a duplicate delete is ignored.
The offline banner
A status strip appears above the navigation while you're signed in:
- Offline — notes that you're disconnected and, if anything is queued, how many changes will sync when you reconnect.
- Syncing — shows briefly while the queue is being replayed.
- Needs attention — appears when sync hit something it can't resolve on its own. Tap it to open the resolution sheet (below).
When you're online with an empty, clean queue, the banner is hidden.
Syncing on reconnect
The queue drains automatically when the connection returns, when the app comes back to the foreground, and on launch. Each queued change is replayed against fresh server state. Most changes apply silently, and you get a brief confirmation of how many synced. After a drain, the app pulls authoritative server data so your lists reflect the real state.
Resolving conflicts
Some changes can't be applied blindly — the server may have changed while you were offline. These are surfaced in the resolution sheet, opened from the "needs attention" banner. Because the sheet is driven by the queue itself, it survives an app restart mid-resolution.
- Possible duplicates — a queued new transaction that closely matches a recent server transaction is held so you can decide. Choose Keep to add it anyway, or Discard to drop it.
- Changed on the server — an offline edit to a record that was modified (or deleted) on the server since you went offline is held. Choose Overwrite to push your version, or Discard my change to keep the server's.
- Discarded — a change that genuinely conflicts (for example, a time entry that would overlap an existing one) is dropped with an explanation. Review the reason and Dismiss it.
Conflicts that aren't held — like a transient server error — are simply left in the queue and retried on the next sync, so a brief glitch never loses your change.