DEV Community: Jahanzaib Ramzan

How to Launch Your App Successfully: A Release Checklist for React Native

Jahanzaib Ramzan — Tue, 08 Sep 2026 07:59:51 +0000

Originally published on jahanzaibramzan.com.

Most app launches that go badly don't fail because the product is bad. They fail on the boring stuff: a rejected build two days before the announcement, a crash on one Android manufacturer that nobody tested, a login flow that breaks the moment a real user opens the app from a push notification. After shipping releases to both stores for years — from solo side projects to an app with hundreds of thousands of users — this is the checklist I run before anything goes live.

Start the store work six weeks out, not six days

Apple and Google both have review processes, both have paperwork, and both can say no. The earlier you touch them, the less they can hurt you.

App Store Connect and Play Console accounts. Set these up as soon as you have a name. Apple's developer program enrolment for a company can take a couple of weeks if D-U-N-S verification is involved. Google's account verification has its own delays, and new developer accounts now need a closed test with real testers before they can publish to production.

Bundle ID and package name. Decide them once. They're permanent, and they show up in deep links, Firebase configs, and every store URL.

Privacy policy and data disclosures. Both stores require a hosted privacy policy URL and a data-safety / privacy-nutrition form describing what you collect. If you use Firebase Analytics, Crashlytics, or any SDK that touches the ad ID, say so. Mismatches between the form and what the app actually does are a common rejection reason.

Age rating, content, and permissions. Fill the questionnaires honestly, and make sure every permission the app requests has a visible reason in the UI. iOS reviewers reject apps that ask for camera or location access with a vague purpose string.

Make the build reproducible

If building a release involves someone's laptop and a series of remembered steps, it will break on the day you need it. Automate it.

I use Fastlane for both platforms, with lanes that bump the build number, build, sign, and upload:

# fastlane/Fastfile
platform :ios do
  lane :release do
    increment_build_number(xcodeproj: "ios/MyApp.xcodeproj")
    match(type: "appstore", readonly: true)
    build_app(workspace: "ios/MyApp.xcworkspace", scheme: "MyApp")
    upload_to_testflight(skip_waiting_for_build_processing: true)
  end
end

platform :android do
  lane :release do
    gradle(task: "bundle", build_type: "Release", project_dir: "android/")
    upload_to_play_store(track: "internal", aab: lane_context[SharedValues::GRADLE_AAB_OUTPUT_PATH])
  end
end

Signing is the part that bites. Use Fastlane match (or a similar shared store) for iOS certificates so the whole team can build. On Android, enrol in Play App Signing and keep the upload key somewhere you can't lose it — a lost upload key is a support ticket, a lost legacy signing key is a new app listing.

If you're on Expo, EAS Build and EAS Submit cover the same ground with less setup. Either way, the release should be one command.

Test on real devices, including bad ones

Simulators lie. They have unlimited memory, perfect networks, and no manufacturer quirks. Before a launch, the build needs time on physical hardware.

The minimum I want in hand: one recent iPhone, one older iPhone still on a supported iOS, one flagship Android, and one cheap Android with 3–4 GB of RAM — ideally a Samsung or Xiaomi, because their Android skins are where the surprising bugs live (aggressive background killing, notification channels, and permission dialogs that behave differently).

Test the flows that only exist in production: opening the app from a push notification when it's cold, from a deep link when it's backgrounded, after the OS kills it and restores state, and on a slow network with airplane mode toggled mid-request. Log in with a brand-new account, not your dev account with 200 test records.

Ship to testers before you ship to everyone

Both stores give you free staged distribution. Use all of it.

TestFlight for iOS: internal testers immediately, external testers after a lighter review. Get at least a week of real usage.
Play internal → closed → open testing: same idea. Open testing also lets you gather pre-launch reviews that don't count against your production rating.

Ask testers for specific things — "install, log in, complete one core task, kill the app, reopen" — not "let me know what you think." You'll get bug reports instead of opinions.

Have monitoring on before the first install

If you don't have crash reporting when you launch, you'll find out about crashes from one-star reviews. Crashlytics is free and takes an hour to add to a React Native app; Sentry is a good alternative and handles JS errors more gracefully.

Set up, at minimum:

Crash reporting with source maps uploaded so JS stack traces are readable.
Analytics for the handful of events that define success: first open, sign-up completed, core action completed, day-2 return.
Alerting on crash-free rate dropping below a threshold, so you hear about a bad release in hours, not days.

Check that you can actually see events from a TestFlight build before launch day. Dashboards that show nothing are a common surprise.

Roll out gradually

You don't have to release to 100% of users at once, and you shouldn't.

On Google Play, staged rollout lets you release to 5%, then 20%, then 50%, then everyone, halting if crash rates spike. On the App Store, phased release does the same over seven days for automatic updates. Turn both on for every release, not just the first.

Pair that with a remote kill switch: a Remote Config flag or a tiny Firestore document the app reads at startup that can disable a feature or show a "please update" screen. When something goes wrong at 3 a.m., turning off one feature is much better than waiting a day for a review.

Write the store listing for humans, not for you

The listing gets you the install; the app has to earn the second open. A few things that consistently help:

The first screenshot is the one that matters. Show the core outcome, with a short caption, not a login screen.
The first two lines of the description are visible before "more". Say what the app does and who it's for in plain language.
Use the subtitle (iOS) and short description (Android) for the main keyword phrase you want to be found for.
Localise the listing for the two or three languages where you expect most users. Machine translation of the listing is acceptable; of the app itself, less so.

Plan the first week, not just the first day

Launch day is the start of the work. Block out the week for it:

Someone watching Crashlytics and reviews daily, with the ability to ship a hotfix within 24 hours.
Reply to reviews, especially the negative ones. Public replies affect conversion.
Look at the funnel from first open to core action. If 60% drop off at sign-up, that's the next release.
Hold back at least one meaningful improvement so version 1.1 has something to say two weeks later.

The checklist

Store accounts, bundle IDs, privacy policy, data forms, age ratings: done six weeks out.
Release build is one command; signing is shared and backed up.
Tested on real devices, including a cheap Android; production-only flows covered.
TestFlight / Play testing tracks used for at least a week.
Crash reporting, analytics, and alerts verified working before launch.
Staged rollout on, kill switch in place.
Listing written for users, first screenshot shows the outcome.
First-week plan: monitoring, reviews, hotfix capacity, a 1.1 in the pipeline.

None of this is glamorous, and all of it is the difference between a launch that builds momentum and one that spends its first week apologising. If you'd like help getting a React Native app across the line — release engineering, store submission, or a pre-launch audit — see Services or get in touch.

Firestore Data Modeling for Offline-First React Native Apps

Jahanzaib Ramzan — Tue, 08 Sep 2026 07:59:25 +0000

Originally published on jahanzaibramzan.com.

Firestore ships with offline persistence turned on for iOS and Android, so a lot of people assume "offline-first" is a checkbox they've already ticked. It isn't. The SDK will cache documents and queue writes, but whether the app actually feels instant on a train or in a basement depends almost entirely on how the data is shaped. Get the model right and Firestore does the hard part for you. Get it wrong and you'll spend months adding loading spinners and retry logic to paper over it.

This is how I model Firestore for React Native apps where users expect things to work whether or not they have signal — the same approach that keeps a Quran-learning app usable for hundreds of thousands of learners, many of them on patchy mobile networks.

What the cache can and can't do

Two facts drive every decision below.

First, Firestore caches documents you've read and queries you've run. If a screen needs a document the user has never opened, it won't be there offline. So the model has to make sure the important data gets pulled in early, in as few reads as possible.

Second, offline writes are queued and replayed in order when the device reconnects. Each write is applied as a last write wins patch to the fields it touches. Two devices editing the same field will conflict silently; two devices editing different fields of the same document will merge fine. That single rule tells you how to split documents.

Split by who writes, not by what it "is"

The relational habit is to group data by entity: one users/{uid} document with everything about the user. For offline, group it by who writes it and how often.

A typical learning or social app ends up with something like this:

users/{uid}                     ← profile: display name, avatar, settings (user writes, rarely)
users/{uid}/progress/current    ← streak, level, last active (user writes, constantly)
users/{uid}/reviews/{itemId}    ← spaced-repetition state per item (user writes, offline-heavy)
users/{uid}/stats/summary       ← totals, rank (Cloud Function writes, never the client)

Why it matters offline: the progress document is small and written by exactly one device most of the time, so queued writes merge cleanly. The stats/summary document is written only by the server, so the client never queues a write to it and can never create a conflict. And the profile isn't cluttered with high-churn fields, so it stays cached and stable.

Contrast that with one big users/{uid} document holding all of it. A queued offline update to streak and a Cloud Function updating rank at the same time will step on each other, and every small change re-sends and re-caches the whole document.

Make the first screen one read

Before the user has done anything, the app needs enough to render the home screen. I aim for one document read, occasionally two.

// On app start — one listener that keeps the home screen alive offline
const unsubscribe = onSnapshot(
  doc(db, "users", uid, "progress", "current"),
  { includeMetadataChanges: true },
  (snap) => {
    setProgress(snap.data() as Progress);
    setPending(snap.metadata.hasPendingWrites);
    setFromCache(snap.metadata.fromCache);
  }
);

Everything the home screen shows — today's due count, streak, next lesson pointer — lives in that document. It's denormalised on purpose: the Cloud Function that processes a completed lesson also updates progress/current with the next due count, so the client never has to run a query to figure it out.

hasPendingWrites and fromCache are worth surfacing in the UI. A small "Saved on this device — will sync when online" hint beats a spinner that never resolves.

Keep per-item state as small documents, not arrays

Spaced repetition, watchlists, bookmarks, completed lessons — anything where the user accumulates per-item state — is tempting to store as an array on the user document:

// Don't do this
users/{uid} { reviewed: ["w_12", "w_57", "w_98", …] }

Arrays grow without bound, every change rewrites the whole thing, and two offline devices appending different items will overwrite each other. Use a subcollection with one document per item:

// users/{uid}/reviews/{wordId}
{
  interval: 4,          // days
  ease: 2.5,
  due: Timestamp,
  reps: 7,
  updatedAt: Timestamp,
}

The "what's due today" query is then cheap and cacheable:

const dueQuery = query(
  collection(db, "users", uid, "reviews"),
  where("due", "<=", Timestamp.fromDate(endOfToday())),
  orderBy("due"),
  limit(50)
);

Because it's the same query every day, Firestore keeps it warm in the cache. Offline, the user still sees today's reviews; the updates they make queue up and replay when they reconnect, one small patch per document.

Separate shared content from user state

Vocabulary lists, lesson content, movie catalogs, level definitions — anything the same for every user — should never be mixed into user documents. Two reasons: it bloats every user's cache with copies of the same content, and it makes content updates a fan-out write to every user.

Put it in its own collection, version it, and cache it deliberately:

content/{version}/lessons/{lessonId}
content/meta { currentVersion: 42 }

On startup, read content/meta (one read), compare to what's on disk, and only pull lessons the user hasn't cached yet. For large static content, a Firestore data bundle or a JSON file in Cloud Storage with a version stamp is cheaper still.

This also answers "what happens when the user is offline and the content changes?" — nothing, until they're back online and the version bumps. Old content keeps working because it's immutable by version.

Let the server own anything competitive

Leaderboards, follower counts, rankings, "trending" — anything multiple users influence at once — must be computed server-side and read by the client. Never have the client increment a shared counter directly; offline devices replaying queued increments hours later will produce numbers that don't add up, and you'll have no way to reconcile them.

The client writes an event (a completed challenge, a like), a Cloud Function aggregates, and the client reads the result:

// Client: append-only, safe to queue offline
await addDoc(collection(db, "users", uid, "events"), {
  type: "challenge_completed",
  points: 120,
  at: serverTimestamp(),   // resolved on the server, not the device clock
});

// Cloud Function: the only writer for stats/summary and leaderboards
export const onEvent = onDocumentCreated("users/{uid}/events/{id}", async (e) => {
  const { uid } = e.params;
  const points = e.data?.get("points") ?? 0;
  await db.doc(`users/${uid}/stats/summary`).set(
    { totalPoints: FieldValue.increment(points), updatedAt: FieldValue.serverTimestamp() },
    { merge: true }
  );
});

Note serverTimestamp(). Device clocks are unreliable, and an offline device replaying events with local timestamps will put them in the wrong order. Let the server stamp them.

Feeds: cache the first page, paginate the rest

For social or content feeds, offline users should see something — the last page they loaded. That happens for free if the feed query is stable and paginated by cursor:

const feedQuery = query(
  collection(db, "posts"),
  where("visibility", "==", "public"),
  orderBy("createdAt", "desc"),
  limit(20)
);

Denormalise what the card needs (author name, avatar, counts) into the post document so rendering the cached page doesn't trigger secondary reads that fail offline. Load subsequent pages with startAfter(lastDoc) only when online.

Security rules that don't break offline

Rules run on the server when writes are replayed, not when they're queued. So a write the device accepted offline can be rejected later, and the SDK will surface it as an error on the promise you've probably long stopped awaiting.

Two mitigations. Keep rules simple and ownership-based (request.auth.uid == uid on users/{uid}/**), so the client can't easily queue something that will be refused. And attach a listener for write failures so rejected writes at least get logged:

setDoc(ref, data, { merge: true }).catch((err) => {
  log.warn("Queued write rejected on sync", { path: ref.path, code: err.code });
});

Test offline like you mean it

The simulator's network toggle is not enough. On a real device: open the app online, kill it, enable airplane mode, reopen it, use it for five minutes, then reconnect and watch what syncs. Check Firestore in the console for documents that look wrong. Then do it with two devices on the same account.

The bugs you'll find are always the same: a screen that needed a document nobody had read yet, a shared counter the client was incrementing, and an array that got overwritten. Every one of them is a modeling problem, not a Firestore problem.

The pattern in one paragraph

Small documents split by writer and churn. One read for the first screen, denormalised on write by a Cloud Function. Per-item state as subcollections, not arrays. Shared content versioned and separate from user state. Anything competitive computed server-side from client-written events. Stable, cursor-paginated queries for feeds. Ownership-based rules. Test on real hardware with airplane mode.

If you're building or rescuing a React Native app on Firebase and offline behaviour is where it hurts, that's a large part of what I do on the Kalaam case study and in Firebase architecture work — or get in touch to talk through your data model.

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.