Keeping Firestore Data Available Offline on Android and iOS

The problem: data disappears when the network drops

Mobile users frequently move between Wi‑Fi, cellular, and dead zones. Without a local cache, a Firestore‑backed app shows stale data or loses writes the moment the connection fails, leading to frustration and potential data loss.

Thesis: enable Firestore’s built‑in offline persistence

Firestore can store a local copy of the documents you read and queue writes while the device is offline. When connectivity returns, the SDK automatically reconciles the queue with the backend. Turning this on is a one‑line configuration change on each platform.

Enabling persistence

Android (Kotlin)

val settings = FirebaseFirestoreSettings.Builder()
    .setPersistenceEnabled(true)   // <-- the switch
    .build()
Firebase.firestore.firestoreSettings = settings

Place this code before any Firestore call, typically in your Application subclass or the first activity’s onCreate. The call requires no extra permissions; it only uses the app’s private storage.

iOS (Swift)

let settings = FirestoreSettings()
settings.isPersistenceEnabled = true   // <-- the switch
Firestore.firestore().settings = settings

Add the snippet in application(_:didFinishLaunchingWithOptions:) or the first view controller that uses Firestore. Again, no special entitlements are needed.

Worked example: a minimal note‑taking flow

1. Model – a notes collection with documents containing text and timestamp.
2. Write – when the user taps “Save”, call db.collection("notes").add(data). The SDK writes to the local cache immediately and returns a document reference.
3. Read – attach a snapshot listener: db.collection("notes").order(by: "timestamp").addSnapshotListener { … }. The listener fires with cached data while offline.
4. Test offline – enable airplane mode on the device/emulator, add a note, and verify the UI updates instantly.
5. Reconnect – disable airplane mode. The pending mutation is flushed; the new document appears in the Firebase console within seconds.

No extra code is required for the sync; the SDK handles the mutation queue internally.

Trade‑offs and limitations

• Storage ceiling – the default cache is capped at roughly 10 MB. If your app syncs large collections, older documents may be evicted, causing missing data on the next offline session.
• Write conflicts – simultaneous offline edits to the same document on different devices produce a conflict when both queues flush. Firestore does not auto‑merge; you must implement a resolution strategy (e.g., last‑write‑wins, field‑level merge, or user‑prompted merge).
• Cache invalidation – clearing app data or uninstalling wipes the cache, so the next launch starts with a fresh download.

Verification checklist

1. Run the app on a physical device or emulator.
2. Open the Firestore console and note the current document count.
3. Enable airplane mode (or disable Wi‑Fi/cellular).
4. Perform a write (add a note). Confirm the UI shows the new entry immediately.
5. Check the device logs for a line similar to Persistence enabled and for a pending mutation queue entry.
6. Disable airplane mode.
7. Observe the console: the document count should increase by one, and the new note should appear without errors.

If the document does not appear, verify that setPersistenceEnabled(true) / isPersistenceEnabled = true executed before any Firestore call and that the cache size has not been exceeded.

Actionable next step

Add the persistence flag to your app’s initialization code today, then run the verification checklist. Once confirmed, consider implementing a simple conflict‑resolution policy (e.g., server timestamp wins) for any collection that multiple users can edit offline. This small investment keeps your app responsive regardless of network conditions.