Building Scalable Mobile Applications with React Native

Most React Native apps do not fail because of React Native. They fail because four decisions were made casually in week one and never revisited. Here is how I approach each of them.

1. Draw module boundaries before you need them

A screens/ folder that grows to sixty files is not architecture. Organise by feature instead:

src/
  features/
    onboarding/    components, hooks, api, types
    checkout/
    profile/
  shared/          design system, utilities, api client

The rule that keeps this honest: a feature may import from shared/, never from another feature. When two features genuinely need the same thing, it moves to shared/. That single constraint prevents the tangle that makes large apps unsafe to change.

2. Pick the smallest state tool that works

Redux is not the default any more, and it should not be. Most screens need three kinds of state, and they want different tools:

• Server state — anything fetched. Use a query library with caching and invalidation. Do not hand-roll loading flags.
• Global client state — session, theme, feature flags. A small store is plenty.
• Local state — form inputs, toggles. useState, and nothing more.

The common mistake is putting server state in a global store. You end up writing cache invalidation by hand, badly, forever.

3. Treat navigation as part of the architecture

Navigation structure leaks into everything: deep links, auth gating, analytics, back behaviour. Decide early whether auth is a separate navigator swapped at the root (usually right) or a redirect inside a shared stack (usually painful). Define your deep link scheme up front, even if you ship it later, because retrofitting URLs onto a screen hierarchy that was never designed for them is genuinely miserable.

4. Respect the render budget

A 60fps target gives you 16ms per frame. On the mid-range Android devices most of your users actually own, you get less. Three habits cover most of it:

• Use FlatList with keyExtractor and stable item components. Never .map() a long list.
• Memoise list items and the callbacks passed into them, or memoisation does nothing.
• Keep animations on the native driver. A JS-driven animation stutters the moment the bridge gets busy.

Measure on the worst device you support

Profiling on a flagship phone tells you almost nothing. Keep a cheap Android device on your desk and test on it regularly. The performance problems that matter show up there first — usually months before a user reports them.

None of this is exotic. It is just decided deliberately rather than by accident, which is the entire difference between an app that scales and one that has to be rewritten.