Delivery drivers in the UAE spend their days moving between buildings, basements, and loading docks. Underground parking garages in Dubai residential buildings have no signal. Metal-walled warehouse loading docks block cellular. Rural areas outside major cities have sparse tower coverage. Elevator shafts create frequent dead zones. Industrial free zones like Jebel Ali are connectivity nightmares.

A logistics app that requires internet fails in every one of these locations. And these are exactly the locations where drivers need the app most.

Offline-First Versus Offline-Tolerant

Most logistics apps are offline-tolerant. They cache some data and show a "No connection" error when the network drops. The driver waits for signal. COD cash sits unrecorded. Proof of delivery cannot be captured.

Voxarel's driver app is offline-first. It works identically with or without connectivity. View assignments, update delivery status, collect signatures, photograph proof of delivery, record cash-on-delivery payments. All with zero network access. Everything queues locally and syncs when connectivity returns.

The Stack

The driver app is built on Expo SDK 54 with PowerSync for bidirectional data sync across 13 tables. PowerSync maintains a local SQLite database that mirrors the server-side PostgreSQL tables the driver needs: assignments, deliveries, customers, addresses, payments, and attachments.

SQLCipher encrypts the local database with 256-bit AES. A driver's phone contains customer addresses, contact numbers, payment amounts, and delivery signatures. If the phone is lost, the encrypted database protects that data.

Sync Priority Queue

When the driver reconnects after an offline period, not all data is equally urgent. The sync priority queue processes operations in a specific order:

  • Priority 1: COD confirmations. Money. A driver with AED 5,000 in collected cash needs that payment on the server immediately. Financial reconciliation depends on it.
  • Priority 2: Status updates. Operations. The dashboard and customer notifications depend on delivery status. A status update triggers the fan-out system (WebSocket, WhatsApp, email, audit log, AI prediction).
  • Priority 3: Photo evidence. Large files. Proof-of-delivery photographs and signature captures are bandwidth-heavy. They sync last because they matter for dispute resolution but are not time-sensitive for operations.

Reconnection Strategy

The app syncs every 30 seconds when online. On network drop, it switches to a 7-tier exponential backoff: 5 seconds, 15 seconds, 30 seconds, 1 minute, 2 minutes, 5 minutes, 10 minutes. This prevents the app from hammering the server while still recovering quickly from brief signal drops.

Conflict resolution uses last-write-wins with server authority. The server's state is canonical. When conflicting updates exist (a dispatcher reassigned a delivery while the driver was offline), the system compares timestamps and flags the conflict for review.

What the Driver Sees

A status indicator: green (synced), yellow (pending sync), red (offline). No error messages. No "retry" buttons. No "please connect" modals. The app works. The indicator tells the driver whether their data has reached the server yet.

This simplicity is intentional. The driver is standing in a basement parking garage with packages in their arms and cash in their pocket. Marking a delivery complete should require one tap and zero network access.

The Pattern for Field Operations

Any app used by field workers (drivers, technicians, inspectors, sales reps) operates where network access is intermittent. Building for the connected case and treating offline as an error is building for the wrong default. Build for offline first. Treat connectivity as a bonus that triggers sync. The core function should never depend on a network request completing successfully.