Offline-first Architecture
Works even in a tunnel. Syncs itself.
We design mobile applications from the ground up for offline operation — local data, automatic sync, zero data loss.
Why Offline-first¶
Wi-Fi is a given in the office. In the field, connectivity is a luxury.
A driver in an underground garage, a warehouse worker in a concrete building, a technician on a transmitter roof, a sales rep on a train — your users work where the network isn’t reliable. An app that shows a spinner and waits when the network drops is useless. Users go back to paper.
Offline-first is not a feature — it’s an architectural approach. The local database is the primary source of truth. The app responds instantly to every interaction. Synchronization happens in the background, transparently. The user doesn’t notice being offline — and that’s exactly the goal.
Where Offline-first Solves Real Problems¶
- Logistics: Drivers confirm deliveries, photograph shipments, scan codes — all offline. Data syncs when returning to the depot or passing through an area with coverage.
- Field service: Technicians fill out service reports, upload photo documentation, read technical documentation — without network dependency.
- Inventory: Scanning thousands of items per hour. Every record instantly in the local DB. Sync after the shift ends.
- Sales: Sales rep in the field has catalog, price lists, customer data — all offline. Orders are sent once there’s a network.
Architecture of an Offline-first App¶
Local Database as Primary Storage¶
All data needed for work is local. SQLite (Room on Android, Core Data / GRDB / SwiftData on iOS) as primary storage. Schema migrated via versioning — database upgrade on app update without data loss.
For more complex scenarios we use Realm (real-time sync built-in) or WatermelonDB (React Native, lazy loading for large datasets). Choice depends on platform, data size and sync requirements.
Selective sync: Not all data needs to be offline. The user gets data relevant to their role, location and current tasks. A driver has shipments for today’s route, not the company’s entire inventory.
Sync Engine¶
Synchronization is the hardest part of offline-first architecture. Trivial for read-only data. Complex for bidirectional sync with multiple users.
Sync engine architecture:
- Change tracking — every local change is written to an outbox table with timestamp and version
- Upload — outbox is sent to server in order, server returns confirmation or conflict
- Download — server sends changes since the last sync point (delta sync)
- Apply — downloaded changes are applied to the local DB
- Conflict resolution — if the same record was changed by two users, business rules are applied
Delta sync: We don’t synchronize the entire database. Only changes since the last successful sync. Timestamp-based or event-based sync. Payload compression (Protocol Buffers, MessagePack). Even on a slow EDGE connection, sync completes in seconds.
Conflict Resolution¶
Two warehouse workers edit the same inventory item offline. Who wins?
Strategy based on business context:
- Last-write-wins: Simple, deterministic. Suitable for scenarios where concurrent editing is unlikely (personal settings, individual forms).
- Field-level merge: If user A changed the address and user B changed the phone, both changes apply. Conflict only when the same field is changed.
- CRDT (Conflict-free Replicated Data Types): For collaborative editing — text, lists, counters. Mathematically guaranteed convergence without central authority.
- Custom business rules: “Manager approval always wins.” “Newer measurement replaces older.” Rules defined with a business analyst.
Key principle: the user never loses data. On an unresolvable conflict, both versions are preserved and the user decides.
Queue Management¶
Operations performed offline are queued in a persistent queue. The queue survives app restarts, crashes and even updates.
Queue properties:
- Ordering: Operations are sent in the order they were performed
- Retry: Exponential backoff with jitter on failure (1s → 2s → 4s → 8s + random)
- Idempotence: Each operation has a unique ID. Backend is idempotent — a repeated request won’t cause duplicates
- Priority: Critical operations (delivery confirmation) have priority over non-critical (photo)
- Visibility: User sees the queue status — how many operations are pending, what’s currently syncing
Background Sync¶
Synchronization runs in the background even when the app is minimized. iOS Background Tasks API for periodic sync. Android WorkManager for guaranteed execution. We respect battery and data constraints — sync over Wi-Fi preferred, cellular only for critical data.
Data Integrity¶
Offline-first increases demands on data integrity. The app must be resilient to:
- Partial sync: Server received 50 of 100 records, then the network dropped → transactional batching
- Schema mismatch: User A has version 2.1, user B has 2.0 → backward-compatible sync protocol
- Clock skew: Devices have different times → server-side timestamping for ordering
- Corrupted local DB: Crash during write → WAL mode, integrity checks, automatic recovery
Testing: Network condition simulation (Charles Proxy, iOS Network Link Conditioner). Chaos testing: random disconnects, slow networks, packet loss. Automated tests in CI verify: zero data loss, zero corrupted state, eventual consistency.
Technology Stack¶
iOS: Core Data, SwiftData, GRDB, SQLite, BackgroundTasks, URLSession background transfers.
Android: Room, SQLite, WorkManager, DataStore, OkHttp interceptors.
Cross-platform: WatermelonDB, Realm, PouchDB/CouchDB.
Sync: Custom sync engine, Firebase Realtime DB, Realm Sync, CouchDB replication protocol.
Monitoring: Sync success rate, conflict rate, queue depth, average sync duration — all in Grafana dashboards.
Časté otázky
Offline-capable means the app 'somehow works' without a network. Offline-first means the app is designed primarily for offline operation — the local database is the primary source of truth, the network is just a sync channel. An architecturally fundamental difference.
It depends on the business context. Last-write-wins for simple scenarios, CRDT for collaborative editing, custom merge strategies for complex business rules. The user is always informed about conflicts — no silent data loss.
Modern devices have tens of GB of free space. We typically store hundreds of thousands of records (orders, inventory, forms). For large datasets we implement selective sync — only data relevant to that user is available offline.
Yes. Images, documents, signatures — everything cached locally. Media syncs in the background with prioritization (metadata first, then images). Progressive quality — thumbnail immediately, full resolution after sync.
Network condition simulation in CI — throttling, packet loss, disconnect/reconnect cycles. Chaos testing: random network drops during operations. Verification: no data loss, no corrupted state after recovery.