# Offline-first

> Offline-first is a design approach where an app treats the network as an optional extra rather than a requirement. The interface renders from locally stored…

Source: https://northerngo.com/glossary/offline-first/
Language: en
Updated: 2026-08-28

---
**Offline-first is a design approach where an app treats the network as an optional extra rather than a requirement. The interface renders from locally stored data first and synchronises when a connection exists, so losing signal degrades one feature at a time instead of blanking the whole app.**

### Render first, fetch second

The defining habit of an offline-first app is that nothing waits for the network to paint. Layout, navigation and any static content appear immediately, and live data fills in afterwards. An app that waits for a database response before drawing anything shows a blank screen offline no matter how good its caching is.

The pieces that make it work:

1. **A [service worker](/glossary/service-worker/)** that serves the app shell, styling and previously seen images from cache.
2. **Local storage of the data itself** — `localStorage` for small amounts, IndexedDB for anything structured or large.
3. **An explicit connection state** in the interface. `navigator.onLine` plus the `online` and `offline` events is enough for an honest banner. Users accept "showing your last saved view" far better than a spinner that never finishes.
4. **Failure per feature, not per app.** One failed call should disable one panel.

### Writes are the hard part

Reading offline is a caching problem and mostly solved. Writing offline is a distributed systems problem and is not. Once you let users create records without a connection, you need a queue that survives a reload, retries that do not duplicate records if the first attempt actually succeeded, and a rule for what happens when the same record was changed on another device meanwhile.

That is why so many "offline" apps are read-only offline, and why it is an honest thing to ship.

### The misconception

Caching pages is often mistaken for being offline-capable. They are different: a cached shell means the app *opens*, not that it *works*. Anything genuinely live still fails.

NorthernGo published apps (subdomain or custom domain) queue `save()` and `delete()` in the SDK when there is no network, and `get()` returns the last successful list plus any pending records (marked `_pending: true`). Login, payments, e-mail and AI still need a connection. The [offline guide](/resources/offline-first-web-apps-pwa/) covers the two-state UI.

---

NorthernGo is an AI-powered platform for building production-ready web apps with zero coding. Local AI generation via WebGPU is unlimited and free, and you own all generated source code. https://northerngo.com/