How to plan offline mode for a mobile or POS app

How do you plan offline mode for a mobile or POS app?

Decide which actions must work without a connection, save them on the device in a queue, send them to the server through endpoints that are safe to call twice, agree in advance how conflicts are resolved, and show people clearly what is waiting to sync. Offline mode is a design decision, not a feature you add at the end. Apps that treat it as an afterthought lose data, double-count sales or confuse staff the first time the Wi-Fi drops.

This is the planning checklist we use when a mobile app or POS system has to keep working in a basement, a warehouse, a market stall or a restaurant with patchy signal.

Which features need to work offline?

Start by sorting every action in the app into three groups. Do it with the people who use the app every day, not only the product owner.

Keep the first group small. Every action in it needs local storage, sync logic, conflict rules and testing, so it is where most of the extra cost sits.

Where should offline data be stored?

Each device needs its own local database. Native and cross-platform apps usually use SQLite or a similar embedded store, and web apps use IndexedDB in the browser. Plan three kinds of local data:

• Reference data the app reads, such as products, prices, customers and staff, refreshed whenever the device is online.
• An outbox of actions the user took while offline, in the order they happened.
• Sync state: the last successful sync time and any items that failed, so the app can retry and report problems.

Encrypt anything sensitive at rest, limit how much history each device keeps, and decide what happens when a device is lost or replaced before its queue was sent.

How should sync work when the connection returns?

The safest pattern is an outbox queue. Every offline action gets a unique ID created on the device. When the connection returns, the app sends the queue in order, and the server records each action once, even if the same request arrives twice because the first reply was lost.

• Make endpoints idempotent. The server checks the action ID and ignores duplicates instead of creating a second sale or a second stock movement.
• Send events, not final states. "Sold 2 of item 1043 at 14:05" merges cleanly with other devices; "stock is now 7" overwrites everyone else.
• Retry with a back-off, and stop retrying an item that the server rejects for a real reason so it can be reviewed by a person.
• Sync both ways. After sending its queue, the device downloads changes from the server, such as new prices or products.

How do you handle conflicts between devices?

Conflicts happen when two devices change the same thing while apart. Write the rules down before development starts, because the right answer is a business decision:

• Server authority for prices, products, discounts and permissions. Offline devices use the last values they had and accept updates when they reconnect.
• Append, never overwrite for sales, payments, notes and stock movements. They are events, so they can all be kept.
• Last change wins only for simple fields where it truly does not matter, such as a customer's preferred name.
• Human review for anything else, such as two staff editing the same booking. The system flags it rather than guessing.

What about card payments while offline?

Card payments are the riskiest part of an offline POS. With Stripe Terminal, for example, payment details are collected at the time of sale, but authorization is only attempted after connectivity returns and the payment is forwarded. Stripe states that the business assumes the decline and tamper risk for offline transactions, recommends restricting large offline amounts, and enforces its own offline maximum per transaction. A smart reader must also have connected online on the same local network within the last 24 hours to take offline payments (Stripe: collect card payments while offline).

So set limits per transaction and per day, give each offline payment your own reference so it can be matched later, and make sure staff can see how many payments are still waiting to be forwarded. Other providers have different rules, so check yours before promising offline cards.

What should users see while offline?

• A clear, calm status indicator, such as "Offline: 12 sales waiting to sync", not an error screen.
• Actions that cannot work offline disabled with a short reason, instead of failing after the user fills in a form.
• Nothing the user typed is ever lost, even if the app is closed or the battery dies.
• A manager view of failed sync items, so problems are fixed the same day.

How do you test offline mode properly?

Normal testing on fast office Wi-Fi will not find offline bugs. Test with flight mode on and off mid-action, with a slow and unstable network, with the app closed during sync, with two devices editing the same record, and with device clocks set slightly wrong. Run a pilot in one real location before rolling out everywhere. Our guide to custom POS systems covers that rollout, and for web-based tools our comparison of PWAs and native apps explains how far browser offline support goes. If your workflow needs software built around it, our custom software development team can plan the sync from day one.

Frequently asked questions

Last updated November 1, 2026