Offline First App Development

Who needs an offline first app, and at what level

Coverage maps hide the places where work actually happens. Technicians lose signal in crawlspaces and mechanical rooms, inspectors work on rural sites, warehouse staff move through steel buildings, hospital teams pass through basements and imaging suites, and event staff scan tickets in a stadium where tens of thousands of phones share the same towers. If your app stops at a spinner in any of those places, people go back to paper and type it in later.

Not every app needs full offline capability, and Tepia sizes it to the job:

• Cached reading. Recently viewed content stays available, such as a product catalog or a schedule. Suitable for most consumer apps.
• Offline capture. Users create new records, photos and signatures offline that upload later, but rarely edit shared data. Common for inspections and proof of delivery.
• Full offline read and write. Users edit shared records that others may also change, which requires sync with conflict handling. Typical for work orders, inventory and patient visit notes.

Each step up adds engineering, so Tepia agrees the level per feature during Discovery rather than applying the heaviest option everywhere.

Choosing a conflict strategy for each record type

Conflicts happen when two people change the same record while one of them is offline. There is no single right answer, so Tepia picks a rule per record type and writes it into the User Stories:

Append only designs are underrated. When every reading or note is its own record, most conflicts disappear, and you get an audit trail for free.

The architecture behind a reliable sync

Tepia builds offline first apps on a few rules that hold across native, React Native and Flutter projects:

• The UI reads only from the local database. Room on Android, Core Data or SwiftData on iOS, SQLite or WatermelonDB in React Native, and Drift in Flutter. Network responses update the database, and the screen updates from there.
• Every change goes through an outbox. Each change gets a unique ID so the server can safely ignore a duplicate when a retry follows a dropped response.
• Sync moves deltas, not everything. The app asks for changes since its last cursor, deletions arrive as tombstones, and each user downloads only their territory, route or facility.
• Background work respects the platform. Android WorkManager and iOS background tasks run sync when the system allows, and the app syncs again whenever it opens.
• Photos travel separately. Attachments queue on their own, compress on device and upload in resumable chunks so one large file does not block form data.
• Logins survive a long shift. If a token expires offline, the user keeps working and reauthenticates at the next sync.

On the server we build sync endpoints in Node.js or .NET on PostgreSQL, designed with our database design team. For simpler apps, Firebase offline persistence can be enough, and Tepia will say so.

How Tepia approaches offline first development

Offline behavior is planned in every one of the six Tepia phases, because adding it after launch usually means rewriting the data layer.

1. Discovery: site visits or ride alongs to find the real dead zones, a review of the systems the app syncs with, and User Stories that state the offline level and conflict rule for each feature. The Investigation Summary estimates the volume of data each user needs on the device.
2. Design: wireframes for sync status, pending changes, rejected edits and storage warnings, so users always know what has and has not reached the office.
3. Development and Testing: the local schema, outbox and sync endpoints are built first. Alpha test plans cover disconnected use, and Beta runs on real devices in the places users actually work.
4. Training: sessions show crews what the sync indicator means and what to do if a change is rejected.
5. Launch: data migration seeds each device on first login, and the rollout goes team by team so sync load stays predictable.
6. Support: sync failures are logged with device and app version, and repeat issues become tracked bugs.

Read about the full Tepia process.

Testing for the network your users really have

Office Wi-Fi hides every offline bug. Tepia QA uses the iOS Network Link Conditioner and Android emulator network profiles to simulate weak signal, then runs scripted cases that break naive apps: toggling airplane mode during a save, force closing the app mid sync, two devices editing the same record offline, a phone with the wrong clock, and a device that comes back after three days with hundreds of pending changes. We also test with low storage, since a full phone is a common reason sync fails in the field.

The app should never fail silently. Tepia builds a visible sync state showing pending items, the last successful sync and anything that needs attention. Offline first is a core part of our field tech apps and inspection and checklist apps, and it pairs well with rugged device apps. See our work or talk to Tepia about where your users lose signal.

Frequently asked questions