State Management in 2026: Zustand vs Redux vs Jotai

Key facts, with sources

• React Native's New Architecture became the default in 0.76, the legacy bridge was retired in 0.82, and Hermes V1 shipped as the default JavaScript engine in 0.84. (TO THE NEW Blog)
• Microsoft retired Visual Studio App Center and CodePush on March 31, 2025, forcing every team that depended on it to migrate their over-the-air update architecture. (microsoft/react-native-code-push GitHub issue)
• In the State of React Native 2024 survey, Redux drew the most negative feedback at around 18% dissatisfaction, while React's built-in state management (31% positive) and Zustand (21% positive) were the best regarded. (InfoQ)
• Over 80% of State of React Native 2024 respondents work in teams of up to five developers, meaning most mobile architectures must be maintainable by very small teams. (SSOJet (State of React Native 2024 highlights))
• Published production examples report Shopify at 86% unified code across its apps and Instagram sharing 85 to 99% of code between iOS and Android. (CatDoes)

First, split server state from client state

Most "state management pain" I see in audits is server data — API responses, pagination, sync status — manually copied into a global store with hand-rolled loading flags. That is a caching problem wearing a state costume, and React Query (or an equivalent server-cache library) solves it better than any store: deduplication, staleness, refetch-on-focus, and optimistic updates come built in.

Once server state moves to a cache, what remains is genuinely small: auth session, theme, form drafts, UI flags, maybe a cart. Make this split first, before comparing stores. Plenty of apps I refactor discover their "Redux problem" was that ninety percent of the store never belonged there, and the remaining ten percent fits in a store so small the library barely matters.

Zustand: the pragmatic default

Zustand is a store without ceremony: a create call, a typed state object, actions as plain functions. Components subscribe with selectors, so renders stay scoped to the slice that changed — a real advantage on mobile where wasted renders show up as dropped frames. Middleware for persistence and devtools exists when needed and stays out of the way when not.

It is my default because it has the lowest concept count: a new engineer is productive in an hour, and there is no dispatch-action-reducer indirection between intent and effect. The discipline it does not provide — consistent structure across a big team — you supply with a light convention: one store per feature, actions defined inside the store, no cross-store imports.

import { create } from 'zustand';

type CheckoutState = {
  couponCode: string | null;
  applyCoupon: (code: string) => void;
  reset: () => void;
};

export const useCheckoutStore = create<CheckoutState>()((set) => ({
  couponCode: null,
  applyCoupon: (code) => set({ couponCode: code }),
  reset: () => set({ couponCode: null }),
}));

// Component subscribes to one field — other changes don't re-render it
const coupon = useCheckoutStore((s) => s.couponCode);

Redux Toolkit: still the right call for some teams

Redux Toolkit is not the boilerplate monster people remember from the pre-Toolkit era. Slices, Immer-based reducers, and RTK Query make it reasonably compact. What Redux uniquely offers is enforced uniformity: every state change flows through the same visible pipeline, time-travel debugging works, and middleware gives you one choke point for logging, analytics, and persistence.

I still recommend it in two situations: teams above roughly eight mobile engineers where convention-by-culture stops scaling, and apps with genuinely event-driven state where an action log is a feature — think audit requirements or complex undo. If you already run Redux happily, migrating to Zustand buys you little; I only migrate stores that are actively hurting.

Jotai: when state is a graph, not a tree

Jotai inverts the model: instead of one store you compose atoms, and derived atoms recompute automatically when dependencies change. That shines when your state is naturally a dependency graph — a pricing configurator where ten fields derive from each other, a drawing canvas, a filter panel where every control affects a computed result set.

The cost is discoverability. Atoms scattered across files make it harder to answer "what is the total state of this app right now," and I have watched teams create atom soup that is genuinely harder to trace than the Redux they left. I reach for Jotai selectively — often just inside one complex feature — while the rest of the app stays on Zustand. Mixing them is fine; they solve different shapes of problem.

How I actually decide on client projects

My decision sequence: move server state to React Query first, always. Then, if the remaining client state is a handful of stores, Zustand — that covers the clear majority of apps I ship. Choose Redux Toolkit when the team is large or the org already has Redux expertise and tooling. Add Jotai inside features with heavy derived state.

What I refuse to do is mix three global paradigms across one codebase by accident, which happens when each new hire brings a favorite. Write the decision down in the repo with two sentences of rationale. The library matters less than everyone using the same one the same way, and the write-up ends relitigation in every code review.

When to hire senior help

Architecture is the cheapest place to buy senior expertise, because decisions about state management, navigation, offline strategy, and update infrastructure made in week one determine costs for years. A short engagement with a senior mobile architect before or during MVP planning routinely prevents the rewrite-at-scale scenario that hits teams around their first major growth phase. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — Mobile App Architecture projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Adopting Redux with sagas and heavy boilerplate for a five-screen MVP when built-in React state or Zustand would cover the actual requirements
• ✕Scattering business logic inside UI components instead of isolating a data layer, making later backend changes or native module swaps expensive
• ✕Building deployment architecture on a hosted OTA service with no exit plan, a risk the March 2025 CodePush shutdown made concrete for thousands of teams
• ✕Assuming permanent connectivity and bolting on caching later, instead of designing offline storage and sync conflict resolution before the data layer hardens

Frequently asked questions

Sources

• TO THE NEW Blog
• microsoft/react-native-code-push GitHub issue
• InfoQ
• SSOJet (State of React Native 2024 highlights)
• CatDoes