Offline support and performance

Mobile networks are not like office Wi-Fi. Users ride the metro, sit in lifts, live in areas with weak signal, or run out of data at the end of the month. An app that shows a blank screen or an error whenever the network drops feels broken, even when the code is correct.

This lesson explains how to build apps that keep working with a bad or missing connection, and how to keep them fast on cheap phones. It is a concept lesson, so there are small code examples rather than a full build. The *Project: expense tracker app* lesson uses a local database in a real app.

You do not have to go fully offline-first. Decide per feature. A Brew & Bean menu can be cached. Placing an order needs the server, so show a clear message instead of failing silently.

@react-native-community/netinfo tells you whether the phone is connected. Install it with npx expo install @react-native-community/netinfo. The hook below returns the current state and updates when it changes.

import { Text } from 'react-native';
import { useNetInfo } from '@react-native-community/netinfo';

export function OfflineBanner() {
  const { isConnected, isInternetReachable } = useNetInfo();
  // isConnected can be true on Wi-Fi with no internet, so also check isInternetReachable.
  const offline = isConnected === false || isInternetReachable === false;
  if (!offline) return null;
  return (
    <Text style={{ backgroundColor: '#444', color: '#fff', padding: 8, textAlign: 'center' }}>
      You are offline. Showing saved data.
    </Text>
  );
}

Both values can be null while the state is still being checked, so treat only a definite false as offline.

The simplest offline feature: after a successful fetch, save the result locally. On the next start, show the saved copy immediately, then refresh in the background. The user sees content instantly, even on a slow network. This is often called stale-while-revalidate.

Use AsyncStorage (npx expo install @react-native-async-storage/async-storage) for small JSON such as a menu or settings. It stores strings, so use JSON.stringify and JSON.parse.

import AsyncStorage from '@react-native-async-storage/async-storage';
import { useEffect, useState } from 'react';

type MenuItem = { id: string; name: string; price: number };
const CACHE_KEY = 'menu_cache_v1';

export function useMenu(apiUrl: string) {
  const [menu, setMenu] = useState<MenuItem[]>([]);
  const [fromCache, setFromCache] = useState(false);

  useEffect(() => {
    let cancelled = false;
    (async () => {
      // 1. Show the saved copy straight away
      const saved = await AsyncStorage.getItem(CACHE_KEY);
      if (saved && !cancelled) {
        setMenu(JSON.parse(saved));
        setFromCache(true);
      }
      // 2. Try to refresh
      try {
        const res = await fetch(`${apiUrl}/menu`);
        if (!res.ok) throw new Error('Bad response');
        const fresh: MenuItem[] = await res.json();
        await AsyncStorage.setItem(CACHE_KEY, JSON.stringify(fresh));
        if (!cancelled) {
          setMenu(fresh);
          setFromCache(false);
        }
      } catch {
        // Offline or server error: keep showing the cached copy
      }
    })();
    return () => {
      cancelled = true;
    };
  }, [apiUrl]);

  return { menu, fromCache };
}

The _v1 in the key lets you change the data shape later without breaking old saved data.

Libraries such as TanStack Query (React Query) do this for you: caching, background refresh, retries and loading states. For most apps that read server data, TanStack Query plus a persisted cache is less work than hand-written code. Learn the hand-written version first so you understand what the library does.

When users create data (expenses, notes, tasks), they must be able to add it with no network. Use a local SQLite database through expo-sqlite. It is a real SQL database stored in a file on the phone, so you can filter, sort and sum without loading everything into memory.

AsyncStorage is fine for a few KB. Move to SQLite when you have lists that grow, need queries, or need relations.

Offline-first apps must get local changes to the server later. A simple, reliable design:

Every row has a synced flag (0 or 1) and a unique id made on the phone (for example a UUID), not a database counter. When the user adds an item, it is saved locally with synced = 0. A sync function runs when the app starts, when the connection returns, and after each save. It sends all rows with synced = 0 to the server, and marks each as synced only after the server confirms.

import * as SQLite from 'expo-sqlite';

type Row = { id: string; title: string; amount: number };

export async function syncPending(db: SQLite.SQLiteDatabase, apiUrl: string) {
  const pending = await db.getAllAsync<Row>('SELECT id, title, amount FROM expenses WHERE synced = 0');
  for (const row of pending) {
    try {
      const res = await fetch(`${apiUrl}/expenses`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(row),
      });
      if (!res.ok) break; // stop and retry later
      await db.runAsync('UPDATE expenses SET synced = 1 WHERE id = ?', row.id);
    } catch {
      break; // network problem: try again on the next run
    }
  }
}

Because ids come from the phone, sending the same row twice must not create a duplicate. The server should treat a repeated id as an update (this is called being idempotent).

If the same record can be edited on two devices, edits can clash. Simple strategies:

Last write wins: keep the version with the newer updated_at. Easy, but one edit is lost. Server wins: the server's copy always replaces the phone's. Merge or ask: combine fields, or ask the user. This is the hardest option and you rarely need it in a first app.

For single-user apps (a personal expense tracker), conflicts are rare and last-write-wins is usually enough.

Many users in India use budget Android phones with limited RAM and 4G or weaker networks. Test on a low-end device, not only on your own phone or a fast emulator. Common causes of slow apps and their fixes:

import { FlatList, Text } from 'react-native';
import { memo, useCallback } from 'react';

type Item = { id: string; title: string };

const Row = memo(function Row({ title }: { title: string }) {
  return <Text style={{ padding: 12 }}>{title}</Text>;
});

export function BigList({ data }: { data: Item[] }) {
  const renderItem = useCallback(({ item }: { item: Item }) => <Row title={item.title} />, []);
  return (
    <FlatList
      data={data}
      keyExtractor={(item) => item.id}
      renderItem={renderItem}
      initialNumToRender={12}
    />
  );
}

FlatList only renders rows near the screen. memo stops a row from re-rendering when its props did not change.

Typical questions: "How would you make this app work offline?", "How do you sync local data to a server?" and "How do you make a list of 10,000 items scroll smoothly?" A strong answer names the storage choice (SQLite for lists, SecureStore for tokens), the synced flag and retry on reconnect, how conflicts are resolved, and FlatList with memoised rows.