DEV Community: Jahanzaib Ramzan

Scaling Firebase for Growing Mobile Apps

Jahanzaib Ramzan — Fri, 04 Sep 2026 11:17:47 +0000

Originally published on jahanzaibramzan.com.

Firebase is the fastest way I know to get a mobile app from idea to store. It's also very easy to build something that works beautifully at 1,000 users and falls over — or gets expensive — at 100,000. The difference is almost never Firebase itself. It's a few data-modeling and Cloud Functions decisions that are cheap to make early and painful to change later.

This is what I've learned keeping a Firebase-backed React Native app healthy as it grew from around 10,000 to more than 300,000 users.

Model for reads, not for tidiness

Firestore bills per document read, and every read is a network round trip on a phone. So the question for every screen is: how many documents does this screen need to open? If the answer is "one per item in the list," you have a problem that will get worse in proportion to your success.

The instinct from relational databases is to normalise: a users collection, a posts collection, a comments collection, and join them on the client. In Firestore, that turns a feed of 20 posts into 20 post reads plus 20 author reads plus 20 comment-count queries.

Instead, denormalise what the screen shows. A post document should carry the author's display name and avatar URL, the like count, and the comment count. Update those copies when the source changes — usually from a Cloud Function, so the client never has to.

// posts/{postId}
{
  title: "…",
  body: "…",
  authorId: "u_123",
  author: { name: "Ayesha", avatarUrl: "…" },   // copied, not joined
  likeCount: 42,
  commentCount: 7,
  createdAt: Timestamp,
}

One read per list item, and the client stays simple.

Keep counters out of the client

Counting is the classic Firestore trap. collection("posts").where("authorId", "==", uid).get().size reads every document just to count them. At scale that's slow, expensive, and racy.

For anything users see constantly — likes, followers, streaks, leaderboard points — maintain a stored counter and update it server-side:

// Cloud Function: keep commentCount in sync
export const onCommentCreated = onDocumentCreated(
  "posts/{postId}/comments/{commentId}",
  async (event) => {
    const postRef = db.doc(`posts/${event.params.postId}`);
    await postRef.update({ commentCount: FieldValue.increment(1) });
  }
);

For counters that many users hit at once (a viral post, a global leaderboard), a single document caps out at roughly one write per second. Use the distributed counter pattern — a handful of shard documents summed on read — or aggregate periodically with a scheduled function. For "count all documents" cases where the number just needs to be shown, count() aggregation queries are much cheaper than reading every document, though they still aren't free.

Precompute the expensive views

A weekly leaderboard that's recalculated every time someone opens the screen is a scaling problem waiting to happen. The pattern that works: compute it once, on a schedule, and write the result to a small document the app reads.

export const buildWeeklyLeaderboard = onSchedule("every 15 minutes", async () => {
  const top = await db.collection("users")
    .orderBy("weeklyPoints", "desc")
    .limit(100)
    .get();

  await db.doc("leaderboards/weekly").set({
    updatedAt: FieldValue.serverTimestamp(),
    entries: top.docs.map((d) => ({
      uid: d.id,
      name: d.get("displayName"),
      avatarUrl: d.get("avatarUrl"),
      points: d.get("weeklyPoints"),
    })),
  });
});

Now every user opening the leaderboard costs one read, regardless of how many users you have. The same idea applies to "recommended for you", "trending", daily challenge content, and anything else that's shared across many users.

Design for offline from day one

Firestore's offline persistence is enabled by default on iOS and Android, and it's one of the best reasons to use Firebase for mobile. But it only helps if your data model plays along.

Keep the documents a user interacts with most — their own profile, progress, settings — small and self-contained, so they cache well and can be written offline without conflicts. Avoid patterns where a single user action must update several documents atomically from the client; move that into a Cloud Function triggered by one write.

In the React Native app, read from the cache first and let the server update arrive:

const unsubscribe = onSnapshot(
  doc(db, "users", uid, "progress", "current"),
  { includeMetadataChanges: true },
  (snap) => {
    setProgress(snap.data());
    setIsFromCache(snap.metadata.fromCache);
  }
);

Users get an instant screen; you get fewer "the app is slow" reviews.

Write security rules that scale with you

Rules are evaluated on every request, and rules that read other documents (get() / exists()) count as reads. A rule that checks a user's role by fetching their profile document on every read effectively doubles your read bill.

Two habits keep this in check. First, put authorisation data on the auth token as custom claims, set from a Cloud Function, so rules can check request.auth.token.role with no extra read:

match /admin/{doc=**} {
  allow read, write: if request.auth.token.role == "admin";
}

Second, structure paths so ownership is obvious from the path itself:

match /users/{uid}/{document=**} {
  allow read, write: if request.auth.uid == uid;
}

Test rules with the emulator suite before deploying. A rules bug at scale is either a data leak or a wave of permission-denied crashes, and both show up in reviews.

Keep Cloud Functions fast and cheap

Functions scale automatically, but each cold start adds latency and every instance costs money. The things that matter most:

Pin a region close to your users and your Firestore location. Cross-region calls add hundreds of milliseconds.
Set minInstances: 1 on the handful of functions that sit in the user's critical path (login, first-screen data) so they don't cold start.
Keep functions small and single-purpose. A 40 MB bundle that imports the entire Admin SDK plus half of npm starts slower than one that imports what it uses.
Use onCall functions for client-to-server RPC rather than raw HTTPS; you get auth context and typed errors for free.
Add idempotency to triggers. Firestore triggers can fire more than once; an increment(1) that runs twice is a bug you'll only notice in the data.

Watch the Functions dashboard for execution time and error rate per function; the slow one is usually obvious.

Control cost before it controls you

A Firebase bill that surprises you is a data-model bill. Once denormalisation, stored counters, and precomputed views are in place, the remaining levers are:

Pagination everywhere. Never load a collection without limit(). Use startAfter() with a cursor, not offset.
Bundle static content. Reference data that rarely changes (vocabulary lists, level definitions, category trees) can be shipped as a Firestore data bundle or plain JSON in Cloud Storage with a version stamp, rather than read per user.
Storage image variants. Generate resized images at upload with the Resize Images extension so phones download thumbnails, not originals.
Budget alerts. Set a Google Cloud budget with alerts at 50/80/100%. It costs nothing and it's the only way to catch a runaway loop before month-end.

Plan the migrations you'll need

You will change your data model. Firestore has no schema migrations, so plan for it:

Add a schemaVersion field to documents you expect to evolve.
Write client code that tolerates missing fields rather than crashing on old documents.
For large backfills, run a Cloud Function or a script with the Admin SDK in batches of 500 writes, with a checkpoint so you can resume.

The app I've spent the most time on has been through several of these; none were fun, but all were manageable because the versions were explicit and the client was forgiving.

The short version

Model each screen for one or two reads. Keep counters and aggregates in Cloud Functions. Precompute anything shared across users. Design documents to cache and write offline. Keep rules read-free. Paginate. Set budget alerts.

Do those things while the app is small and Firebase will carry you a very long way. If your app is already past that point and the bill or the latency is climbing, that's the kind of audit I do — see Services or get in touch.

10 Tips to Improve Performance in React Native Apps

Jahanzaib Ramzan — Fri, 04 Sep 2026 11:16:11 +0000

Originally published on jahanzaibramzan.com.

Most React Native performance problems I get called in to fix aren't exotic. They're the same handful of issues, repeated: lists that re-render everything on every keystroke, images that are ten times larger than the box they sit in, screens that fetch more data than they show, and a startup path that does far too much work before the first frame. This is the list I actually work through on client apps, roughly in the order I check them.

1. Measure before you touch anything

Performance work without measurement is guessing. Before changing code, get a baseline for the three things users feel: time to first interactive screen, frame drops during scroll and animation, and the delay between a tap and visible feedback.

The built-in Performance Monitor (shake → Perf Monitor) shows JS and UI frame rates. For anything deeper use Flipper with the React DevTools plugin, or the React Native DevTools profiler. On Android, adb shell dumpsys gfxinfo <package> gives frame timing without any extra tooling.

Write the numbers down. Then when you apply one of the fixes below, you'll know whether it helped or whether you just made the code more complicated.

2. Replace FlatList with FlashList for long lists

FlatList recreates list item components as they scroll into view. On a feed with hundreds of items and images, that's the single biggest source of dropped frames I see. Shopify's @shopify/flash-list recycles item views instead, and on the same data it typically cuts scroll jank dramatically.

import { FlashList } from "@shopify/flash-list";

<FlashList
  data={posts}
  renderItem={({ item }) => <PostCard post={item} />}
  estimatedItemSize={180}
  keyExtractor={(item) => item.id}
/>

The one thing it needs is estimatedItemSize — an honest guess at the average row height. Get that roughly right and the rest is a drop-in replacement. If you can't migrate yet, at least set windowSize, maxToRenderPerBatch, and removeClippedSubviews on FlatList — but migrate.

3. Stop list items from re-rendering

Even with FlashList, if every row re-renders when unrelated state changes, you're back to jank. Two habits fix most of it.

Wrap row components in React.memo, and make sure the props you pass are stable:

const PostCard = React.memo(function PostCard({ post, onPress }: Props) {
  return (
    <Pressable onPress={() => onPress(post.id)}>
      <Text>{post.title}</Text>
    </Pressable>
  );
});

// In the parent — stable callback, not a new arrow function per render
const handlePress = useCallback((id: string) => navigate("Post", { id }), [navigate]);

The common mistake is memoizing the child and then passing it a fresh { style: {...} } object or inline function on every render, which defeats the memo entirely. If a memoized component still re-renders, the React DevTools "Highlight updates" toggle will show you which prop changed.

4. Size images for the box they fill

A 4000×3000 photo rendered into a 120×90 thumbnail still has to be decoded at full size. Multiply that by a scrolling list and you've got memory pressure, decode stalls, and OOM crashes on low-end Android.

Serve images at roughly the display size (2× for retina is fine), and cache them on disk. expo-image handles caching, placeholders, and transitions well; react-native-fast-image does the same on bare RN.

import { Image } from "expo-image";

<Image
  source={{ uri: post.thumbUrl }}   // a 240px variant, not the original
  style={{ width: 120, height: 90 }}
  contentFit="cover"
  cachePolicy="memory-disk"
  placeholder={blurhash}
/>

If your backend is Firebase Storage, generate resized variants at upload time with the Resize Images extension rather than resizing on the client.

5. Make sure Hermes is on, and check your bundle

Hermes has been the default engine for a while, but I still find apps that turned it off during a migration and never turned it back on. Confirm it in android/gradle.properties (hermesEnabled=true) and the iOS Podfile, then check at runtime:

const isHermes = () => !!(global as any).HermesInternal;

While you're there, look at what's actually in your JS bundle. npx react-native-bundle-visualizer shows it as a treemap. Every time I run it on a client project there's something surprising — a full lodash import for two functions, moment with every locale, an icon library pulling in thousands of glyphs. Swapping to lodash/debounce, date-fns, and a tree-shakeable icon set can cut startup by hundreds of milliseconds.

6. Move work off the startup path

Cold start is where apps feel slowest, and it's usually self-inflicted. The pattern to look for: the root component fetching remote config, hydrating a persisted store, initialising analytics, checking auth, and registering push notifications — all before rendering anything.

Split it into what the first screen actually needs and what can wait:

useEffect(() => {
  // Needed to render the first screen
  restoreAuthSession();

  // Everything else after first paint
  InteractionManager.runAfterInteractions(() => {
    initAnalytics();
    registerForPushNotifications();
    prefetchSecondaryData();
  });
}, []);

Persisted state (Redux Persist, Zustand's persist) should only include what you need on launch; a 2 MB cached feed in AsyncStorage is a startup cost, not a feature. Lazy-load heavy screens with React.lazy so their code isn't parsed until someone navigates there.

7. Keep animations on the UI thread

Any animation driven by JS state updates competes with everything else the JS thread is doing, so it stutters the moment a list scrolls or a network response arrives. Reanimated runs animations as worklets on the UI thread and stays smooth under load.

const progress = useSharedValue(0);
const style = useAnimatedStyle(() => ({
  opacity: progress.value,
  transform: [{ translateY: (1 - progress.value) * 20 }],
}));

useEffect(() => {
  progress.value = withTiming(1, { duration: 250 });
}, []);

For gestures, pair it with react-native-gesture-handler so the whole interaction stays off the JS thread. For the old Animated API, useNativeDriver: true gets you part of the way for opacity and transforms.

8. Fetch less, cache more

Slow screens are often just waiting on the network. Three things help.

First, don't fetch on every focus. TanStack Query (or SWR) gives you stale-while-revalidate for free: show cached data immediately, refresh in the background.

const { data } = useQuery({
  queryKey: ["post", id],
  queryFn: () => fetchPost(id),
  staleTime: 60_000,
});

Second, fetch only what the screen shows. A list needs titles and thumbnails, not the full body of every item.

Third, if you're on Firestore: enable offline persistence (it's on by default on mobile), model data so a screen is one or two reads rather than a fan-out of N queries, and precompute counters and aggregates in Cloud Functions instead of counting on the client. Firestore bills per document read and each read is a round trip — both add up fast on a feed.

9. Watch for expensive re-renders from context and stores

A single React.Context holding the whole app state means every consumer re-renders whenever any field changes. The same applies to selecting the whole store from Redux or Zustand.

Split contexts by how often they change (auth vs. theme vs. feed data), and select narrowly:

// Re-renders only when `unreadCount` changes
const unread = useStore((s) => s.notifications.unreadCount);

// Re-renders on every store update — avoid
const store = useStore();

why-did-you-render is worth adding in development for a week; it's blunt but it finds these fast.

10. Test on the phone your users actually have

Everything above will look fine on an iPhone 15 or a Pixel 8. Most of the world isn't on those. Keep one genuinely cheap Android device — something with 3–4 GB of RAM from a few years ago — and make it part of the QA pass before every release. Enable Don't keep activities in developer options once in a while too; it exposes state-restoration bugs that only appear when the OS kills your app in the background.

Release builds only. Debug builds run the JS through the Metro dev server with extra checks, and are not representative of what users get.

A workflow that sticks

The fixes above are fairly mechanical. What keeps an app fast is doing them consistently: set a performance budget (for example, first screen under 1.5 s on the test device, no dropped frames on the main feed), check it in CI or at least before each release, and treat a regression like a bug rather than a polish task for later.

I've applied this checklist on apps ranging from a Quran-learning app with 300K+ users on Firebase to solo Android projects, and the outcome is usually the same: the first two or three items fix most of the complaints, and the rest keep them from coming back.

If you have a React Native app that has gotten slow and you'd like a second pair of eyes on it, I do technical audits — see Services or get in touch.