A Guide to State Management in Large-Scale React Native Applications

If you are managing state in a large-scale React Native application, the right answer is almost never "one tool for everything." Effective react native state management at scale means separating server state from client state, keeping global state small, and choosing libraries based on measured performance and team ergonomics rather than popularity. In my experience leading mobile teams, the applications that stay maintainable are the ones that treat state as an architecture decision, not a dependency choice.

This guide walks through how I approach state in production React Native apps: the categories of state you actually have, how to pick between Redux, MobX, and lighter options, and the performance traps that bite enterprise teams.

Start by Classifying Your State

Most state problems come from treating all state as the same thing. Before you reach for a library, separate your state into four categories:

1. Server state — data fetched from APIs. It is cached, can go stale, and needs refetching and invalidation.
2. Global client state — authentication status, feature flags, theme, user preferences. Shared across many screens.
3. Local component state — form inputs, toggles, animation values. Lives and dies with the component.
4. Navigation state — the current route stack, managed by your navigation library.

The single biggest improvement I have seen in large codebases is moving server state out of Redux and into a dedicated data-fetching library. Libraries like TanStack Query or RTK Query handle caching, deduplication, and background refetching for you. Putting server responses in a global store by hand means you reimplement all of that, badly.

// Server state with TanStack Query — no global store needed
import { useQuery } from '@tanstack/react-query';

function useAccount(accountId: string) {
  return useQuery({
    queryKey: ['account', accountId],
    queryFn: () => api.getAccount(accountId),
    staleTime: 60_000,
  });
}

Once server state is handled separately, your global store shrinks dramatically. Often what remains is small enough that you no longer need the heavyweight tooling you assumed you did.

React Native State Management Options Compared

With server state handled, you are choosing a tool for the remaining global client state. The practical contenders for large scale react native apps are Redux Toolkit, MobX, Zustand, and Jotai. Here is how I weigh them.

Redux Toolkit

Redux Toolkit (RTK) is the modern, opinionated Redux. The boilerplate that gave classic Redux a bad reputation is largely gone. You get createSlice, Immer-powered immutable updates, and RTK Query bundled in.

import { createSlice } from '@reduxjs/toolkit';

const sessionSlice = createSlice({
  name: 'session',
  initialState: { userId: null as string | null, theme: 'light' },
  reducers: {
    signedIn: (state, action) => { state.userId = action.payload; },
    themeToggled: (state) => {
      state.theme = state.theme === 'light' ? 'dark' : 'light';
    },
  },
});

export const { signedIn, themeToggled } = sessionSlice.actions;

When I reach for RTK: large teams that benefit from strict conventions, apps that need serializable state for time-travel debugging or persistence, and codebases where predictable, auditable update flows matter for compliance. The Redux DevTools and middleware ecosystem are genuinely useful on big projects.

Trade-offs: more ceremony than alternatives, and you must be disciplined about useSelector to avoid re-render storms (more on that below).

MobX

The redux vs mobx react native debate usually comes down to philosophy. Redux is explicit and functional: you dispatch actions, reducers compute new state. MobX is reactive and mutable: you mutate observable objects, and components re-render automatically based on what they read.

import { makeAutoObservable } from 'mobx';
import { observer } from 'mobx-react-lite';

class CartStore {
  items: string[] = [];
  constructor() { makeAutoObservable(this); }
  add(id: string) { this.items.push(id); }
  get count() { return this.items.length; }
}

const Badge = observer(() => <Text>{cart.count}</Text>);

MobX shines when your domain model is complex and object-oriented, and when fine-grained reactivity matters. Components only re-render when the specific observables they read change, which is excellent for performance without manual memoization.

Trade-offs: the "magic" reactivity can be harder for new engineers to reason about, and mutable state makes some debugging less transparent than Redux's action log.

Zustand and Jotai

For many apps, after extracting server state, these lighter options are the pragmatic winners.

• Zustand is a small store with a hook-based API, selector support, and no provider boilerplate.
• Jotai is atomic: state is composed from small atoms, which avoids the single-store re-render problem by design.

import { create } from 'zustand';

const useSession = create((set) => ({
  userId: null,
  signIn: (id: string) => set({ userId: id }),
}));

// Subscribe to only the slice you need
const userId = useSession((s) => s.userId);

I recommend starting here for new enterprise react native projects unless you have a concrete reason to adopt Redux or MobX. You can always layer in more structure later.

A Decision Framework

Rather than a universal recommendation, use these questions:

• Is most of your state actually server data? If yes, invest in a query library first. The global store question may become trivial.
• Do you need strict audit trails and serializable state? Favor Redux Toolkit.
• Is your domain a rich object graph with derived values? MobX earns its keep.
• Do you want minimal ceremony and have a small global surface? Zustand or Jotai.
• How large and how senior is the team? Larger, mixed-seniority teams benefit from Redux's guardrails. Small, senior teams move faster with lighter tools.

We help teams make exactly these architecture calls as part of our software and platform engineering capabilities, where the goal is a stack the team can maintain, not the trendiest one.

React Native Performance: Where State Goes Wrong

React native performance issues at scale are usually re-render problems, not raw computation. The JavaScript thread drives the UI, and unnecessary renders cause dropped frames, especially in lists.

Avoid over-broad subscriptions

The classic mistake is selecting too much from the store:

// Bad: re-renders on ANY state change
const state = useSelector((s) => s);

// Good: re-renders only when userId changes
const userId = useSelector((s) => s.session.userId);

Select the narrowest slice each component needs. With Redux, use memoized selectors (createSelector from Reselect) for derived data. With Zustand, pass a selector function. With Jotai and MobX, fine-grained subscriptions are the default.

Keep global state small

Every piece of state in a global store is a potential re-render trigger. Form state, scroll positions, and transient UI flags belong in local useState or useReducer, not in Redux. This is also better for correctness: ephemeral state should not outlive the screen.

Watch list rendering

In FlatList and FlashList, ensure renderItem and item components do not subscribe to broad state. Memoize item components with React.memo and keep their props stable. A single badly-subscribed list cell can tank scroll performance across the whole screen.

Persist selectively

For offline-capable apps, persist only what you need. redux-persist or MobX persistence can rehydrate large blobs on startup and block the first render. Whitelist specific slices and consider lazy hydration.

// redux-persist: persist only the session slice
const persistConfig = {
  key: 'root',
  storage: AsyncStorage,
  whitelist: ['session'],
};

Putting It Together: A Reference Architecture

For a typical enterprise app, the layout I recommend looks like this:

• Server state: TanStack Query or RTK Query, keyed by resource.
• Global client state: a small Zustand or Redux store for session, theme, and feature flags.
• Local state: useState / useReducer inside components.
• Navigation state: owned by React Navigation.
• Derived state: computed with memoized selectors or MobX getters, never duplicated.

This separation keeps each layer testable and prevents the "everything in one giant store" pattern that makes large apps slow and brittle. It also scales across domains with different needs. Teams building regulated apps in sectors we serve across the industries we work with often lean toward Redux for auditability, while consumer-facing teams favor lighter stores. The framework is the same; the weighting changes.

The core principle holds regardless of library: classify your state, keep the global surface small, and let performance measurements, not habit, drive your choices.

FAQ

Is Redux still worth using in 2024?

Yes, in the right context. Redux Toolkit removed most of the historical boilerplate, and RTK Query is a strong server-state solution. For large teams needing strict conventions, serializable state, and powerful DevTools, it remains a solid choice. For smaller global state surfaces, lighter libraries are often simpler.

Should I use Redux or MobX for React Native?

Choose Redux Toolkit when you want explicit, auditable, serializable state and strong tooling. Choose MobX when you have a rich object-oriented domain model and want automatic fine-grained reactivity with less manual memoization. Both scale well; the decision is largely about team philosophy and domain shape.

How do I improve React Native performance related to state?

Subscribe to the narrowest state slices possible, memoize derived values, keep transient UI state local instead of global, and be careful with subscriptions inside list item components. Most performance problems at scale are unnecessary re-renders rather than heavy computation.

Do I still need a global store if I use TanStack Query?

Often much less than you think. Query libraries handle server state, caching, and refetching. What remains is usually a small amount of client state such as session and preferences, which a lightweight store like Zustand can handle comfortably.

What is the best state management for a new enterprise React Native app?

Start by separating server state into a query library. For the remaining global state, begin with a lightweight option like Zustand or Jotai, and adopt Redux Toolkit only if you need its conventions and tooling. Match the tool to team size, domain complexity, and compliance needs.