Building Offline-First Mobile Apps with React Native and Firebase

I was sitting in a café in Al Ain last summer, trying to demo a plant care app for a client. The Starbucks Wi-Fi dropped again. This app — Greeny Corner — helps farmers track irrigation schedules and plant health. But half my users live in areas with spotty internet. If the app only worked online, it’d be useless to them. We needed a plan B.

Why offline matters in the real world

Let’s get something straight: Offline mode isn’t a niche feature. In the UAE, even with all our fiber-optic hype, coverage gaps exist. Rural areas. Metro tunnels. Airplane Wi-Fi (or lack thereof). Add GCC’s regional neighbors, and suddenly offline isn’t “nice to have.” It’s table stakes.

How Firebase and React Native handle offline by default

I’ll be real — when we first spun up Firebase, I thought it’d handle everything. Cloud Firestore’s offline persistence is built-in. Call enablePersistence(), and the SDK caches data locally. For basic CRUD, it works magic.

But it’s not foolproof. When you read from a document, Firestore checks the cache first. If you’re offline, the UI keeps returning results. But write operations? They hang in limbo until the device reconnects.

Configuring Firebase for offline resilience

This is the core setup I’ve used across projects:

const db = getFirestore(app);  
enablePersistence(db).catch((err) => console.error('Persistence failed', err));

That’s it. Firebase handles the rest… until it doesn’t.

Wait. One thing that burned me: Enabling persistence only works if you’re not using snapshot() for real-time updates. If you mix onSnapshot() with offline mode, you’ll get cached results. But users might not realize they’re working locally.

Making the UI reflect offline status

React Native’s NetInfo library is your friend. I used it in Tawasul Limo’s booking flow to show an “Offline” banner when connectivity dropped. Sure, Firebase caches data, but users should know the network’s unstable.

NetInfo.addEventListener((state) => {  
  if (!state.isConnected) {  
    showOfflineBanner();  
  } else {  
    hideOfflineBanner();  
  }  
});  

This isn’t just good UX — it prevents users from hammering a “send” button that won’t work.

Handling write conflicts (because real life isn’t clean)

Here’s where my confidence shattered. We built a feature for Greeny Corner letting users log soil moisture readings. If you track plants in 50°C heat, you don’t want to lose data because your phone went offline.

But when two admins edit the same plant’s humidity threshold while offline, Firestore doesn’t magically pick the right winner. Last-write-wins works sometimes. Not always.

We ended up adding version numbers to each document. If the server’s version is newer than the local one, we prompt the user for a manual merge. Not perfect, but better than data loss.

Local storage + Firebase: The combo that isn’t redundant

For critical inputs like form submissions, I layer in a local SQLite database. When the network drops, writes hit SQLite first. Then Firebase observers pick them up automatically once persistence resumes.

This setup added 3 days to the timeline for Reach Home Properties’ agent app. Was it worth it? When one of their field agents in Ras Al Khaimah logged property inspections from a desert site with 0 bars of LTE, yeah. She later thanked me mid-meeting, not because she’s polite — but because her job depends on this working.

A hiccup I can’t unsee

One thing I spent way too long debugging: Firebase Auth sessions. By default, the SDK tries to validate tokens against a server. Even with offline persistence, re-authentication flows break mid-airport if you’re offline.

Solution? Store auth state separately, and treat account actions as “pending” until online. That limo booking app? We delayed a feature launch two weeks because I didn’t catch this early.

Offline isn’t optional — it’s the environment

The real lesson here? Plan for offline from day one. If you’re writing a retail app targeting shoppers on Dubai Metro, or a logistics tracker for trucks on empty highways, your app will run offline. You can’t test it only in Wi-Fi-friendly offices.

I once built a prototype for a Fujairah client using Expo’s mock location features to simulate dead zones. Faked a 30-second network drop. The first run crashed 6 components.

Final thoughts (but not a listicle)

Building offline-first isn’t glamorous. No client requests it in their RFP. But ship an app that breaks every time you enter a basement, and no one’s happy.

If you’re diving into this stack for the first time, start small. Enable persistence. Test write operations across restarts. Mock network failures. And remember — users won’t blame Firebase if it breaks. They’ll blame your app.