Short answer. An offline app is not an app that “keeps a copy just in case”; it is an app whose screen reads only the phone’s database, whose every write enters a persistent queue with an idempotency key, whose synchronisation is background work that drains the queue in order when the network returns, and whose server recognises a key it has already seen and returns the same response instead of creating a duplicate. Conflicts are settled by rules written per field before the code, and every entry carries a visible status. Two weeks of inventory, ten weeks of build, an airplane-mode acceptance, a pilot on one route.
This guide is for the distributor whose pre-sellers spend the day in covered markets, the driver who signs in a basement, the agency doing inventories in cellars, the chain of shops whose till cannot stop, and the founder settled in France who has read “offline mode” in three quotes without any saying what it means. It picks no framework; it describes what must exist for the sentence “it works without network” to be true, and how it is checked.
What the figures say
The Algerian network is everywhere and nowhere. According to ARPCE figures reported by the press, 48.7 million of the 54.87 million mobile subscriptions were on 4G at the end of June 2025, 88.8 %, and 51.63 million 4G and 5G subscriptions were counted in the second quarter of 2026; the ITU estimates 3G and 4G population coverage at 99.1 % in 2025, an international estimate, not a regulator reading. But coverage obligations are expressed in population, not area, and secondary sources describe networks concentrated on the northern corridor; Algérie Télécom announced in February 2026 a plan of 345 new 4G stations in 44 wilayas, and the September 2026 press mentions extending services to 3,000 low-density localities. A phone covered for 99 % of the population is covered at zero in a covered market, a basement, a cellar, a cold room or a village between two hills, and that is where the people who enter data work.
The network also stops by decision. During the baccalauréat, Algeria cut or strongly disrupted fixed and mobile internet every June from 2018 to 2023: AFP described full one-hour cuts in 2018, Algérie Télécom spoke in 2021 of a “restriction” of sharing networks during the first half of each exam, and TSA noted in 2023 an internet strongly disrupted from day one. The 2026 bac, which began on 7 June, was the first without a general cut according to TSA and Algérie-Eco. Whether the cuts return or not, a field app built for Algeria was designed for days when the network is not a given.
The subject has long been written up by those who build at scale. Android’s architecture guide defines the offline-first app as one that “is able to perform all, or a critical subset of its core functionality without access to the internet”, states that the local data source is the canonical source of truth which the screen must read exclusively, distinguishes three write strategies, online-only, queued, lazy, and names the most common conflict rule, “last write wins”, with background tasks that wait for the network and retry at a growing interval. Stripe, for its part, documents idempotency keys: a client-generated key, a random identifier long enough, kept for at least twenty-four hours, which makes a replayed request return the saved response instead of creating a second object. These two texts alone say the essentials of this guide; the rest is Algeria and the trade.
The life of an offline entry, in six moments
The architecture is not described by its components but by what happens to an order taken at 9 am in a covered market, until the depot sees it.
The local write is immediate: the order is saved in the phone’s database with an identifier created on the spot, a long random identifier, not a number only the server can give; the phone’s time and a version. The screen shows it at once, because it reads the local database and nothing else. The queue receives the operation, not just the data: “create order X”, with its idempotency key, timestamp, attempt count, status. The queue survives the app being closed and the phone restarting. The network returns, sometimes for thirty seconds in a lift: a background task drains the queue in write order, one operation at a time; on failure it retries after one second, then two, then four, never in a tight loop, because a tight loop drains the battery and floods the server when a thousand phones find the network at the same minute.
The server receives and does three things in this order: it looks at the idempotency key, and if it has already seen it, returns the response it had given, redoing nothing; otherwise it checks the record’s version, and if there is a conflict, applies the rule written for that field; then it applies the operation and answers. This moment is what separates an offline app from an app that retries. Reconciliation follows: the server’s response holds the true state, the validated price, the final order number, the refused line; the local database updates, and the screen follows without the pre-seller tapping anything. The proof is what the user demands and projects forget: every entry carries a status, pending, sent, confirmed, rejected with its reason; the pre-seller knows at 4 pm what has gone out and what has not, and does not call the depot to ask. It is the same proof the pre-sale guide demands for the time-stamped visit.
The offline architecture, in five layers
Behind the six moments, five layers, and the first is a decision, not a library.
The local database is the only thing the screen reads: catalogue, customers, prices, the day’s orders, pending photos. It is synchronised for reads by deltas, meaning the phone asks the server “what changed since my last sync” rather than the whole catalogue, which matters on a slow plan and a slow network. An app that reads the network first and “falls back to the cache” on failure is not offline: it shows a spinning wheel for twenty seconds before deciding it has no network, twenty times a day. The queue is persistent, ordered and visible: a table in the local database, not a list in memory; each row carries the key, the timestamp, the attempt count and the status, and the app’s screen can show it. Synchronisation is a background task, which the operating system launches when the network returns and the battery allows; on Android it is the role of the persistent work Google documents, with retries at a growing interval.
The idempotent API is the server-side layer, and it is often the one missing when a vendor promises offline: every write accepts a key, the server keeps the key and the response for at least twenty-four hours, and returns the same response if the key comes back; every record carries a version, and every field has a conflict rule written before the code. Supervision comes last and changes the sales manager’s life: the list of phones whose queue holds operations older than two hours, data age per device, rejections per rule. A phone stuck since morning is a call to make before 11 am, not an evening statistic. These layers are built on a single API, the one described in the guide on PWA and native: the field’s native face carries the local database and the queue; the customers’ web face carries a lighter version.
«An app that reads the network and keeps a copy just in case is not offline; it is online with a cache.»
A worked example
An example on volume assumptions, and requirements that are not assumptions: a distributor, twelve pre-sellers, one day of route.
Eight hours is not an assumption but a requirement to write in the specification: from 8 am to 4 pm, the pre-seller must read the catalogue, this customer’s prices, their history and balance, and enter orders and shelf checks with photos, without the app asking for the network once. If the specification says “offline mode” without saying eight hours and without saying what, three vendors will read three things. 350 orders on twelve phones in a day is our volume assumption; what is not one is the expected result: zero lost orders and zero duplicates on arrival at the depot, because every order is written locally before anything else and carries a key the server recognises. Without a key, a day of unstable network produces duplicates, and every duplicate is a truck delivering twice or a retailer refusing.
Two minutes between the network returning and the order visible at the depot is our assumption for a queue of thirty operations drained in order against a server answering in under a second; it becomes ten minutes if the queue holds heavy uncompressed photos, which is fixed by compressing on the phone and sending photos after orders. One rule per field is the requirement that costs least and avoids most: the server is authoritative on price, the phone on the entered quantity, the most recent on the free note, the server-side deletion wins. The assumptions to check at home: how many hours without network your teams really spend, how many writes per day and per device, and how big the photos are; a week of logging on two phones answers all three.
Six conflicts that happen, and the rule written before the code
Conflicts are not rare cases; they happen in the first week, and the only way to make them harmless is to have written the rule before.
Two pre-sellers editing the same customer offline, one the phone number, the other the address: the naive rule, “last write wins” on the whole record, erases one of them; the useful rule merges per field, each field keeping its most recent change. The same order sent twice is the most frequent and most costly conflict: the network drops after the server received the order but before the phone received the response; the phone retries; without an idempotency key, the depot picks twice. The price that changed during the day is settled by deciding who is authoritative: the server, with a gap threshold under which the order passes at the entered price, above which it goes to the sales manager for approval.
Stock that no longer suffices because three pre-sellers sold the same last case is not settled on the phone, which cannot know real-time stock offline: the order is accepted with a “to confirm” line, the depot offers a substitution, the retailer is told, and that is the mechanism the guide on the B2B ordering portal describes. An item deleted on the server and edited locally: the deletion wins, and the line becomes “rejected, product removed” with its reason, visible to the pre-seller, rather than vanishing. A wrong phone clock is more frequent than one thinks: the server timestamps on receipt and keeps the phone’s time as information; the order of operations comes from the queue, never from the clock. A seventh conflict is not in the table because it is human: a pre-seller who fixes a rejected order by re-entering it instead of editing it; the “rejected” status with a “correct” button that reuses the key avoids the duplicate.
«What makes a conflict harmless is not a library, it is a rule written before the code.»
Six products: what must work without network, what waits for it
Not everything must work offline, and the list of what must is the first thing to write.
The pre-seller needs to read everything and enter orders and shelf checks; they do not need the depot’s confirmation or real stock, which wait for the network with a clear status. The driver needs their route, the note, the signature, the photo and collection with a printed or displayed receipt; the SMS receipt to the customer and the balance update wait, as the guide on the cold chain and proof of delivery describes. The inventory happens in a cellar or on a roof: the full checklist, time-stamped photos and signature must work with nothing, and the report leaves afterwards, as in the guide on the flat managed from France. The till cannot stop: sale, ticket, discount, closing and printing work all day without network, and online card payment, reconciliation and the chain dashboard wait, as the guide on tills and QR payment describes.
The customer’s portal or app needs less: reading the catalogue, the basket and last orders, and entering an order that goes into the queue; the day’s prices, confirmation and payment wait for the network, and that is acceptable because the customer is not in a cellar eight hours a day. The manager’s dashboard is the only screen that need not work offline: it shows the last known state with its time, without allowing action, because its truth is on the server. It is also the screen everyone asks for first, which is why it must be written explicitly in the right column: a manager deciding on an “offline” dashboard decides on yesterday’s figures.
Seen elsewhere: what Google and Stripe have written, and what transposes
Android’s architecture guide says three things any Algerian specification can copy. First, that the local data source is the canonical source of truth and that the app’s upper layers read only it, which ensures consistency between connection states. Second, that writes fall under three strategies, online-only for what must happen in real time like a bank transfer, queued for what can wait without the user being told like analytics, lazy for what is critical and must exist locally first like an order; and that the third requires conflict rules. Finally, that synchronisation is persistent work, entrusted to the system, with retries at a growing interval and constraints such as “network connected”. These three things transpose as they are, and a vendor who does not know them will not build an offline app.
Stripe documents the other half, server side: an idempotent request carries a client-generated key, a random identifier with enough entropy to avoid collisions, up to 255 characters; the server saves the status code and body of the first response, returns them if the key comes back, and may prune keys after at least twenty-four hours. What transposes: the key per write, the replayed response, the retention period. What does not: the scale. An Algerian distributor’s API receives a few thousand writes a day, not millions; it can keep its keys for a month and log every conflict, which Stripe cannot afford, and that is an advantage: every rejection is readable by the sales manager the same evening.
Airplane-mode acceptance
An offline app is checked by cutting the network, and acceptance that does not do so has checked nothing. The scenarios fit on one page and are played on two real phones, not an emulator: enter ten orders in airplane mode, close the app, restart the phone, turn the network back on and count at the depot; cut the network during the sending of an order, exactly between request and response, and check there is only one order; edit the same customer on two offline devices and check the per-field merge; set one phone’s clock to last year; drain the battery at 30 % of the queue; load 2,000 catalogue lines and 300 photos and measure opening and sync time on the team’s oldest phone, the Android 11 or 12 one that the guide on PWA and native recalls is four phones in ten.
Each scenario has a written expected result, and those results are the specification’s acceptance criteria, as the guide on the specification recommends: “ten orders entered in airplane mode are at the depot within two minutes of the network returning, with no duplicate” can be checked; “robust offline mode” cannot. Airplane-mode acceptance is a milestone of its own, between build and pilot, and it takes two weeks because it always finds something.
The 2027 calendar
The calendar is that of a twenty-four-week build, whose first two weeks produce no code and decide everything.
Weeks 0 to 2 take the inventory with the business: every possible write in the app, its key, its conflict rule, its visible status, and the list of what must work without network for how many hours. Weeks 2 to 6 wire the screen to the local database and build read synchronisation by deltas; at the end, the app reads everything without network. Weeks 6 to 10 build the queue, the idempotent API, versions and coded rules, with visible statuses; this is the project’s core. Weeks 10 to 12 are airplane-mode acceptance. Weeks 12 to 16 are the pilot on one real route, twelve phones, with queues and rejections watched every evening by the sales manager and the vendor together. Weeks 16 to 20 add supervision and extend to all teams; weeks 20 to 24 review: losses, duplicates, conflicts per rule, and what can, in the end, remain online-only. What a year of such an app then costs is detailed in the guide on keeping an app alive; lead times by project type in the guide on real lead times.
What makes offline fail
The “offline” apps we see fail almost always fail for one of these reasons.
- Reading the network first. The wheel spins twenty seconds before falling back to the cache; the user picks the notebook back up on day three.
- A queue in memory. The app is closed by the system or the phone restarts; the day is lost.
- No idempotency key. The first day of unstable network produces duplicates, and the depot no longer trusts any order.
- A server-issued identifier. The order cannot exist before the network; everything else is false.
- “Last write wins” on the whole record. The address fixed by one erases the phone number fixed by the other, without anyone knowing.
- No visible status. The pre-seller calls the depot to know what went out; the depot calls the vendor.
- Acceptance without airplane mode. Everything works at the office on Wi-Fi; nothing works in the covered market, and you learn it on pilot day.
Frequently asked questions
The questions we receive from distributors, chains of shops, agencies and founders settled in France.
- Is offline an option added at the end?
- No. An app whose screen reads the network does not become offline by adding a cache; the screen must read the local database, writes must go through a queue and the server must accept idempotency keys. These three things are decided before the first line of code, which is why they belong in the specification, with the number of hours and the list of screens.
- How many hours without network should be planned?
- The ones your teams really spend without network, measured for a week on two phones before writing the specification. For a pre-sale or delivery route, eight hours is the rule; for a till, the whole day; for a customer ordering from home, a few minutes suffice.
- What happens if two people edit the same thing?
- What the rule written for that field says: the server is authoritative on price, the phone on the entered quantity, the most recent on the note, the server-side deletion wins, the fields of one customer merge one by one. When the rule decides against the user, they see it in the status, with the reason.
- And photos?
- They are compressed on the phone, queued after orders, sent when the network is good and preferably on Wi-Fi, and linked to their order or inventory by the identifier created on the spot. A forty-photo inventory leaves in a few minutes on a good network and in an hour on a bad one; the user does not have to wait.
- Can an installable web app be offline?
- For reading and for a queue of light orders, yes, on Android and on iPhone once added to the Home Screen. For eight hours of field work with photos, scanning and printing, no: that is the native face’s job, and the guide on PWA and native explains where the line falls.
- How do we check the vendor can do it?
- Ask them, in writing, for the six airplane-mode acceptance scenarios and the expected result of each, and ask to see the queue table and the server-side handling of the idempotency key in a demo. A vendor who has already built offline has these answers in ten minutes.