Offline-First Apps: Building for Unreliable Connections

An offline-first app is a mobile app designed to work from the phone's own storage and to sync with the server whenever a connection is available, instead of failing the moment the network drops. For users in Afghanistan, where coverage, electricity and data costs are all unpredictable, offline-first design is often the difference between an app people rely on and one they uninstall.

Key Takeaways

• Offline-first means screens read from local data; the network is used to sync, not to draw every screen.
• Decide feature by feature what must work offline: viewing, creating, editing, or nothing.
• Queue user actions on the device and sync them with retries, clear status and conflict rules.
• Small payloads, cached images and incremental sync cut data costs for users.
• Test with airplane mode, throttled networks and devices that stay offline for days.

What Does Offline-First Actually Mean?

Offline-first means the app reads and writes to a local database on the phone first, and treats the server as a place to sync with later. When the user opens a screen, it appears immediately from local data. When they submit a form, it is saved locally, marked as pending, and sent when the connection allows.

This differs from offline support bolted on at the end, where an app is built to call the server for every action and then given a cache. Bolted-on caching usually shows old lists but blocks the user as soon as they try to do anything. Offline-first is an architecture decision, and it is far cheaper to make at the start than halfway through a project.

Which Apps Need Offline-First Design?

Any app used in the field, on the move, or by people paying for every megabyte benefits from offline-first design. Typical cases:

• Field data collection: surveys, inspections, health outreach and agricultural extension work
• Sales and delivery apps where agents record orders, payments and proof of delivery on the road
• School and training apps where students download lessons once and study later
• Inventory and point-of-sale tools in shops where power and internet cut out
• Catalogues, menus and guides whose content changes rarely

If your users sit in an office with stable Wi-Fi all day, a lighter approach may be enough. In Kabul, and even more so in provincial towns and rural districts, that is rarely the whole audience.

How Does Data Sync Work in an Offline-First App?

Sync works by keeping a queue of local changes and a record of what the device last received, then exchanging only the differences when the phone is online. A typical design:

1. Store data in an on-device database; SQLite-based options are common in both React Native and Flutter.
2. Give each record a unique ID created on the device, so it can be saved before the server knows about it.
3. Write every user action to an outbox queue with a timestamp.
4. When a connection appears, send queued actions in order, with automatic retries and increasing wait times.
5. Ask the server only for changes since the last successful sync, not the full dataset.
6. Mark records as synced, pending or failed, and show that status to the user.
7. Apply agreed conflict rules when the same record changed in two places.

How Should You Handle Sync Conflicts?

You handle conflicts by deciding a rule for each type of data before writing code, because there is no single right answer. Common rules:

• Last write wins: simple, and acceptable for things like personal settings.
• Server wins for sensitive fields: prices, stock levels and payment status should come from the server.
• Merge: for lists such as notes or order items, combine changes instead of overwriting them.
• Ask a person: for rare but important clashes, show both versions and let someone choose.

Also make operations safe to receive twice. On a poor connection the server may get a request while the phone never receives the reply, so the phone sends it again. Because each record carries its device-generated ID, the server can recognise the duplicate and ignore it instead of creating a second order.

Designing the Experience for Unreliable Connections

Good offline UX is honest: it tells users what is saved, what is waiting and what failed, without blocking them. Practical patterns:

• A small, calm offline indicator instead of a full-screen error
• A "saved on this phone, will send when online" message after submitting
• A pending-items screen so staff can see what has not synced yet
• A "sync now" button for people who know they have a signal for a moment
• Download controls for large content, with file sizes shown, so users decide when to spend data

Language and layout matter here as well. Status messages should read naturally in Dari and Pashto and work properly in right-to-left layouts, because these are exactly the messages people read when something is going wrong.

How Do You Keep Data Usage and App Size Low?

You keep usage low by sending only what changed and by never downloading the same thing twice. Compress responses, resize images on the server before they reach the phone, cache them on the device, and let users choose Wi-Fi-only downloads for heavy files such as videos.

Watch the install size too. Many users have phones with little free storage, and a large app is often the first thing they delete. For simpler needs such as catalogues and forms, a progressive web app with a service worker can also work offline and avoids an app store install entirely.

Security and Testing for Offline Apps

Data stored on the phone needs protection: encrypt sensitive local data, clear it on logout, and never keep secrets such as private API keys inside the app. Our guide to mobile app security best practices covers this in more detail.

Testing an offline-first app means breaking the network on purpose. A useful checklist:

1. Create and edit records in airplane mode, then reconnect.
2. Close the app while a sync is half finished and reopen it.
3. Throttle the connection to a slow mobile profile.
4. Edit the same record on two devices while both are offline.
5. Leave a device offline for several days with many pending changes.
6. Check what happens when a user logs out with unsynced data.

Work With Sheen

Sheen builds Android and iOS apps designed for real Afghan network conditions, with local storage, reliable sync and Dari, Pashto and English interfaces. Learn more on our mobile apps page or contact us at info@sheen.af or +93 784 966 018.