A mobile app that works offline is one where the core tasks can still be done without an internet connection, and the data is sent to the central system automatically once the connection comes back. For field teams, warehouse staff, sales reps working in rural areas, or crews at farms and energy sites, this isn't a luxury; it is the feature that decides whether the app gets used at all. In this article we explain what working offline means, and the hardest part, synchronization, in plain language.
What does offline-first mean?
Most apps work on an "internet first" basis: every screen asks the server, and if no answer comes, the app waits or shows a warning. With the offline-first approach, the app works first with its own data on the device; talking to the server is something done in the background, whenever there is a chance.
From the user's point of view, the difference is this: the app always opens quickly, screens appear instantly, and the work done is saved on the device. A small note such as "3 records waiting to be sent" appears in a corner of the screen, and when the connection comes back, that number drops to zero.
This approach is useful not only where there is no internet at all, but anywhere the connection is weak or patchy. In an elevator, in a tunnel or at a crowded trade fair, the app keeps running smoothly.
Which data should be kept on the device?
Downloading everything to the phone is neither possible nor sensible. The right question is: which tasks does the user need to be able to do when they are offline?
| Data type | Keep it on the device? | Note |
|---|---|---|
| The user's work orders for the day | Yes | Downloaded at the start of the day |
| Product / parts list | Yes, in summary form | Code, name, unit; no large images |
| Customer cards | Only the relevant ones | The full customer list is unnecessary and risky |
| Price information | Depends | If freshness is critical, show the "last updated" time |
| Photos, signatures, forms | Yes, until they are sent | They should be cleared from the device once sent |
If the data kept on the device includes personal data, it must be stored encrypted, remote access must be revocable if the phone is lost, and it must not be kept longer than necessary.
Synchronization: the hardest part of the job
Synchronization means bringing the data on the device and the data on the server into line. It works both ways: changes made on the device go to the server, and updates on the server come down to the device.
It looks easy, but a few questions need answers up front:
- Order of sending. Should the work order closure go first, or the photos attached to it? Dependent records must be sent in the right order.
- Interrupted uploads. If the connection drops in the middle of sending, the record must not be created twice. Giving every record a unique ID on the device solves this problem.
- Large files. Should photos be sent over mobile data, or should the app wait for Wi-Fi? It helps to give users this choice.
Conflicts: when two people change the same record
A conflict occurs when the same record is changed both on the device (while offline) and somewhere else. For example, while a technician adds a note to a work order without internet, the office may have updated the address on the same work order. When the connection comes back, which one wins?
There is no single right answer; you need rules by data type:
- Last write wins. The simplest method; enough for low-risk fields (such as a notes field).
- Field-level merge. If the technician added a note and the office changed the address, both are kept, because they touched different fields.
- Fields with a defined owner. Some fields can be changed only by the office, others only by the field team. Conflicts are prevented from the start.
- Ask a human. For truly critical fields (such as amounts or quantities), the system flags the conflict and waits for an authorized person to decide.
Sensitive data such as stock needs an extra safeguard. An order written while offline should be saved as a "pre-order" and approved centrally, because stock may have changed by the time the connection comes back. We define the general framework for rules like these, covering which system is responsible for which data, as part of our integration work.
Be honest with the user
In an app that works offline, users wonder whether their data has gone through. So:
- The number of records waiting to be sent should always be visible.
- A clear warning should appear for records that haven't been sent for a long time.
- Users should be warned about pending data before they log out or delete the app.
- If the server rejects a record, the reason should be explained in plain language.
Checklist
- Have the typical places and durations without internet been identified?
- Has the list of data to keep on the device been drawn up?
- Is personal data stored encrypted on the device?
- Is every record created with a unique ID?
- Have conflict rules been written for each data type?
- Are pending records visible to the user?
- Has a real field day been tested in airplane mode?
How we do it at Globya
We discuss offline requirements at the start of the project; adding them later is much harder than planning them from the outset. Together with you, we write down which tasks will be done without internet, which data will stay on the device and what the conflict rules are, and we test the app in airplane mode with real field scenarios. We apply this approach especially in field team apps and in industries with large field operations such as construction and building materials. You will find the overall framework on our mobile app page.
Frequently asked questions
Can an app that runs in the browser (a PWA) also work offline?
Yes, to a degree. Screens and a limited amount of data can be kept on the device. But when you need large amounts of data, long periods without internet and background sending, a store app gives more reliable results.
What happens to the data on the device if the phone is lost?
The data is stored encrypted, and the user's session can be closed centrally. Because unsent records may be lost, it is important for the app to send them whenever it finds a connection.
Can offline support be added to our existing app?
It is possible, but it may require extensive changes depending on the app's data structure. We first review the existing structure and tell you how much of it can be reused.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.