A business app can work without internet access if it stores the necessary data on the device and has defined rules for entering and sending changes later. An employee can then complete a report or read downloaded work orders. The changes enter the shared record only after the server accepts them. Each offline task needs a clear boundary and a visible indication of work that has not been sent.
Consider a service technician entering a basement without reception. The employee needs to save the report during the visit and send it once a connection is available. If you are choosing the type of application, see our PWA and native app comparison. This guide follows one business task through a connection loss.
Which functions can work without internet access?
Start with the information needed for one shift: assigned work orders, instructions and a report form. Decide what the app downloads while connected and how it shows the last update time. An order that was never downloaded will not become available simply because the app has an offline mode.
Reading a saved order and entering a note can happen locally. Checking current stock in a shared warehouse requires access to the system that manages it. Without that connection, the app can show a timestamped last known quantity or save a request that awaits a stock check.
Android's guidance on offline apps considers reading and writing separately. An app that opens downloaded content does not necessarily support data entry without a connection. Specify offline behavior for each function in the scope and proposal.
Example: completing a service report without reception
The following is a fictional workflow for discussing requirements. It is not a test result or a description of an existing client product. Before leaving, Ana downloads work order SV-104, version 7, for an equipment inspection. She loses reception in the basement, enters “Filter replaced”, sets the condition to “Ready for use” and adds a photograph.
The proposed app checks required fields and finishes writing the data to the device before confirming a local save. If there is insufficient space for the photograph, it reports that the attachment was not saved. It must not present the whole report as successfully saved. Ana needs to know which part of the task requires another attempt.
Scroll the table sideways to see all columns.
| Message shown | What is confirmed | What happens next |
|---|---|---|
| Saved on this device | The data and required attachment are in local storage. | The server has not confirmed the report. |
| Waiting to send | The report is queued; receipt has not been confirmed. | Retry when connected, with an unsent report count visible. |
| Confirmed by server | The server has accepted the complete report and required attachment. | Show the confirmation time and updated order version. |
| Decision needed | The change conflicts with a newer shared version. | Review the difference and obtain an authorized decision before finishing synchronization. |
When the connection returns, the app sends the report. If the current version and permissions allow it, the server accepts the report as version 8. Ana sees confirmation and the coordinator can open the accepted data. A Wi-Fi indicator alone does not confirm that the server received the report.
How do you prevent duplicates when retrying?
A connection can fail after the server saves a report but before the phone receives its response. The employee still sees “Waiting to send”, even though receipt is complete. The next attempt must therefore recognize the same operation.
In this proposed workflow, the app assigns a unique identifier to the submission and stores it with the data. An automatic retry and the “Try again” button use that same identifier and content. The server checks whether it has processed the submission and returns its result. Receiving it again does not create another report or trigger the same notification twice.
The server rejects the same identifier with different content. A deliberate new edit receives a new identifier and refers to the previous record version. This separates a repeated transfer from new work. The processing is called idempotent: repeating an operation has the same business effect. The HTTP standard explains why safe retry behavior must be known in advance. Counting clicks in the interface does not itself prevent duplicates.
What if two people change the same information?
In a separate variation of the example, Ana is working offline on version 7 while the coordinator changes the equipment condition to “Out of service”. Ana records “Ready for use” on her phone. When she reconnects, her older version must not silently overwrite the coordinator's warning.
The proposed rule preserves Ana's entry, shows both values with their authors and asks the coordinator to decide. The coordinator checks the equipment, chooses the valid value and records a reason. The history retains previous changes. Until that decision, the report remains marked as unresolved.
Automatic merging may be appropriate for different, independent fields. For the same field, choose a rule based on the consequence of an error. Keeping only the latest edit may be unacceptable for approvals or equipment condition. Record who decides and what the employee sees before development begins.
Will data be sent after I close the app?
That depends on the operating system, browser and implementation. For web apps, Workbox documents Background Sync and its fallback behavior. Where that API is unsupported, Workbox retries when the service worker starts again. Check sending behavior on supported devices, including what happens while the app is closed.
Provide a process the employee can complete with the app open: an unsent items list, a retry action and a clear result. Test screen locking, battery saving and reopening the app on the devices the team actually uses.
The local copy also needs a recovery plan. WebKit describes storage limits and conditions in which browser data can be removed. Clearing site data, losing a phone or uninstalling an app can leave you without access to unsent entries. Employees need to see what exists only on that device and know who handles failed transfers.
What happens to sensitive data and expired sessions?
Download only the information needed for the agreed task. Decide how long it stays accessible, how it is protected and what happens when another person signs in. OWASP warns that browser storage does not itself provide confidentiality. Sensitive information requires an assessment of device access, application protection and key management.
In the proposed workflow, an expired session pauses sending and asks the same user to sign in again. The entry remains associated with that account and is not transferred to whoever signs in next. The server checks permissions again before accepting it. A phone that is offline cannot immediately learn that access was revoked on the server, so define how long local access is allowed.
What should you test before accepting an offline feature?
Use test accounts and fictional records. Start each scenario from a known state. Record the app version, device, operating system and outcome. The following is a test plan, not a claim that these checks have already been performed.
- Download an order, disconnect, complete its report and reopen the app. Check that the data and required attachment remain available.
- Interrupt the response after server acceptance. Retry with the same identifier and confirm that one accepted report exists.
- Change the same field from another account. Check the conflict message, preserved entry and authorized decision.
- Test session expiry, switching users and revoked permissions. An unsent report must not become visible to another account.
- Test attachment storage failure and insufficient space. The message should identify what was not saved.
- Restore the connection after locking the screen and reopening the app. Check the sending queue and confirmation of the complete report.
Add these rules to your software specification. For a mobile app development discussion, prepare one field task, the devices you use and the data required without a connection. In your project estimate request, include how long the team usually works without reception so we can define the scope and its acceptance checks.