Offline-First Mobile Apps For Emerging Markets
How to architect Android and cross-platform apps that stay usable when the network drops — a lesson from building Soko Mtaani and LeoTap in Tanzania.
Why offline-first is not optional in East Africa
In Dar es Salaam, Dodoma, and Zanzibar, mobile network coverage is improving but still unreliable during peak hours, in underground shops, and in rural last-mile delivery zones. If your app shows a blank screen or a spinning loader when the connection drops, users will uninstall it within a day.
Offline-first does not mean the app works entirely without the internet. It means the app caches enough state locally that users can browse products, review their cart, check previous orders, and queue new actions that sync automatically when connectivity returns.
The architecture pattern that works
We use a local-first data layer built on SQLite (for Android) or AsyncStorage (for React Native), combined with a background sync service. When the user adds an item to their cart or submits a delivery address, the action is written to a local queue first, then pushed to Cloud Firestore or a REST API when the device regains connectivity.
The key principle is: write locally, sync remotely, resolve conflicts with last-write-wins for non-critical data and server-authoritative resolution for payments and inventory counts.
Practical cache invalidation strategies
Product catalogs are cached with a TTL (time-to-live) of 30 minutes. Category metadata is cached for 2 hours. User session tokens are persisted in encrypted shared preferences with refresh-on-expiry logic. Images use a two-tier cache: in-memory LRU for the current session, disk cache for repeat visits.
The most important rule: never cache payment or transaction state. Those must always be server-authoritative to prevent double-charging or phantom orders.
Handling sync failures gracefully
When a queued action fails to sync (e.g., the server returns a 409 conflict because inventory was depleted), the app displays a clear, localized error in Swahili or English explaining what happened and what the user can do next. Silent failures destroy trust faster than any other bug.
We also implement exponential backoff with jitter for retry logic, capped at 5 attempts over 10 minutes, before marking the action as failed and notifying the user.
Designing Secure APIs For Real Operations
Why consistent contracts, permissions, and structured failure handling matter more than flashy endpoint counts.
Read ArticleRBAC Design For Business Systems
A practical approach to authorization when your product has admins, reviewers, operators, and stakeholders with different responsibilities.
Read Article