A phone spends much of its day on weak, slow or missing connections, so we design every mobile product as if the network might not be there. At EacTech, offline-first is not a feature we add late in development; it is the starting assumption that shapes data models, screens and release plans. This note explains what that means in practice, how it shows up in the products we are building, and what it costs.
Key takeaways
- Offline-first means the app’s local data is the source of truth, and the network is an enhancement for sync, sharing and live features.
- Mobile connectivity is unreliable in ordinary places: transit, elevators, basements, rural roads, crowded venues and roaming abroad.
- Local-first data also reduces latency, saves battery and keeps personal information on the device by default.
- The hard parts are sync, conflict handling, content updates and testing. They are manageable if planned from day one and expensive if retrofitted.
- Features that truly need a connection should say so clearly instead of failing silently.
What offline-first actually means
Offline-first means the app reads from and writes to data stored on the device, treats that local data as the source of truth, and uses the network only to enhance what already works. The network becomes a way to back things up, share them, update content or reach other people, not a precondition for opening a screen.
This is different from “works offline sometimes.” Many apps cache a few screens and show a spinner or an error the moment a request fails. An offline-first app is built the other way around: the default path never waits on a server, and online behavior is layered on top.
Why this matters on mobile specifically
- Connectivity is uneven. Signal drops in trains, parking garages, stairwells and buildings with thick walls. Data plans run out. Roaming gets switched off.
- Latency is felt. Even on a good connection, a round trip to a server is slower than reading from local storage. For a quick action, such as opening a document or starting a puzzle, that delay is the difference between instant and sluggish.
- Battery and data matter. Fewer network calls mean less radio time and smaller bills for people on limited plans.
- Privacy improves by default. Data that never leaves the phone cannot be exposed in transit or on a server. That is a simpler privacy story than any policy document.
How offline-first shapes our products
All of the products below are in development and not yet released. The examples describe how we are designing them, not results from production.
Scanzia: the document library lives on the phone
Scanzia, our mobile document scanner and PDF toolkit, is currently in development. Its core workflow (scan, organize, reorder pages, merge, split, sign and share) is designed to run entirely on the device.
That decision has concrete consequences:
- The document library is a local database plus files on device storage. Folders, names and search work without a connection.
- PDF operations such as merging and splitting are performed on the phone, not sent to a server for processing.
- Documents stay local by default. Planned cloud sync is opt-in, and it is designed as a layer over the local library rather than a replacement for it.
Documents often contain financial, legal or medical details. Keeping them on the device is the most direct way to be privacy-conscious, and it means a scan made at a counter with no signal behaves exactly like one made at home on Wi-Fi.
Mystery Word: levels ship with the app
Mystery Word, our multilingual word puzzle game, is also in development. A word puzzle is a natural fit for offline play: there is no opponent to wait for, and a session might happen on a commute or a flight.
To make that work, level definitions and the per-language word data needed to validate answers are bundled with the app. Progress is saved locally after every level. A network connection can later bring new themed challenges or additional content, but losing signal mid-level should never cost a player their place.
FootyQuiz: offline mode with question packs
FootyQuiz, our football trivia game, is in development too, and it is the most interesting case because it also has live multiplayer. Live PvP obviously needs a connection. Quick matches against the game do not.
Our approach is to ship and cache question packs on the device so offline mode works without a server. Results and progression earned offline are recorded locally and queued for sync when the connection returns. The online parts, including live matches and ranked play, are clearly marked as online. We cover the multiplayer side in detail in designing multiplayer games before you have thousands of players.
Patterns we rely on
These patterns are not new, but they are easy to skip under schedule pressure. We try to put them in place before the first feature screen.
Local storage as the primary store
Every screen reads from local storage. Network responses update the local store, and the UI reacts to that change. This keeps one code path for rendering, whether data arrived a second ago or a week ago.
A durable sync queue
User actions that need to reach a server, such as a finished match result or a progress update, are written to a persistent outbox on the device. A background process drains the queue when a connection is available. If the app is closed or the phone restarts, the queue survives.
Idempotent operations
A request might be sent twice: the first attempt timed out, but the server actually received it. Every queued operation carries a unique identifier so the server can recognize a repeat and ignore it. Without this, retries create duplicate scores, double-counted rewards or repeated records.
An explicit conflict strategy
When the same data changes on two devices, or on a device and a server, something has to decide the outcome. There is no universal answer, so we choose per data type:
| Data type | Example | Strategy we favor |
|---|---|---|
| Append-only events | Completed levels, match results | Merge both; never overwrite |
| Personal settings | Language, sound preferences | Most recent change wins |
| Counters and totals | Lifetime points | Recompute from events, not from stored totals |
| Shared or competitive state | Ranked rating | Server decides; device displays |
Writing this table early forces useful conversations. Modeling progress as a list of events rather than a single overwritable number removes most conflicts before they exist.
Clear UI for online-only features
Some features genuinely need the network: live opponents, opt-in cloud sync, fetching new content. Those features should show their status plainly, explain what is unavailable offline, and recover quietly when the connection returns. An offline-first app should never present a blank screen or a generic error for something it could have explained in one sentence.
The costs and trade-offs
Offline-first is not free. We think it is worth it for these products, but the costs are real.
App size
Bundling level data, question packs and word lists makes the install larger. We weigh what must ship with the app against what can be downloaded once and cached. Language-specific content is a good candidate for on-demand download, which ties into how we approach building multilingual apps from the start.
Sync complexity
A sync queue, idempotency keys and conflict rules are more engineering than calling an API from each screen. The complexity is front-loaded, which is exactly why it has to be designed early. Adding sync to an app that assumed a constant connection usually means rewriting its data layer.
Content updates
If content lives on the device, fixing a typo in a question or adding a new set of levels means shipping a content update. We plan for versioned content packs that can be refreshed independently of app releases, with the bundled version as a safe fallback.
Testing
Offline-first multiplies the states to test: offline from launch, connection lost mid-action, connection restored with a full queue, two devices editing the same data, an app update arriving with pending sync items. These cases need deliberate test scenarios, including simulated poor networks, not just a pass on fast office Wi-Fi.
An offline-first checklist
Before a mobile feature is considered designed, we want clear answers to these questions:
- Does this screen render from local data with no network?
- Where is this data stored, and is the local copy the source of truth?
- If an action needs the server, is it queued durably and retried safely?
- Does every queued operation have a unique ID so retries are idempotent?
- What happens if this data changes on two devices? Is the rule written down?
- Is any online-only feature clearly labeled, with a useful offline message?
- What content must ship with the app, and what can be downloaded later?
- Have we tested airplane mode, a dropped connection mid-action and a long offline period?
Where this leads
Offline-first is one of the principles behind all of EacTech’s mobile products, alongside privacy-aware analytics and multilingual architecture. It asks for more care up front and pays it back in apps that open instantly, keep personal data close and respect the places people actually use their phones.
Scanzia, Mystery Word and FootyQuiz are all in development, and each is being built around these patterns. More engineering notes from the studio are collected in EacTech Build Notes.