Skip to main content
Back to blog
MobileMobiStackOffline-first

Offline-first sync patterns we use in MobiStack

Prabhix Engineering · 5 August 2025 · 7 min read

MobiStack's technician app is used on shop floors where connectivity is inconsistent — basement service counters, crowded malls, shared shop Wi-Fi that drops under load. 'Online-only' wasn't an option.

We built the mobile client with an offline-first architecture using a local SQLite store as the read/write surface, with background sync to the Prabhix API when connectivity is available.

**Write locally, sync later.** Ticket creation, status updates, and inventory adjustments write to the local database immediately. The UI reflects the change instantly. A sync queue batches mutations and sends them to the API with exponential backoff on failure.

**Conflict resolution by domain.** Not every conflict can be 'last write wins':

- **Ticket status** — server wins on conflict; the technician sees a toast explaining the current server state.

- **Inventory counts** — optimistic locking with version numbers; conflicts surface a merge UI for the shop manager.

- **Customer notes** — append-only; both local and server notes are preserved and deduplicated by timestamp.

**Part compatibility cache.** The compatibility engine data for supported device families is pre-synced to the device during login. Technicians can look up compatible parts offline; the cache refreshes on each successful sync.

**Sync indicators.** The app shows a subtle status bar: synced, syncing, or offline with N pending changes. Technicians trust the app because it never silently drops their work.

These patterns aren't unique to repair shops — any field-work application with unreliable connectivity benefits from the same approach: local-first writes, domain-specific conflict rules, and transparent sync status.