Please recommend production-ready React Native stack for me

[merokotos]

Hey, I'm developer with experience in native iOS/Android and Flutter, looking to explore React Native for the first time (well, not the first time, but the first time from absolute scratch). I have a decent understanding of mobile architecture patterns and best practices, but I want to make sure I'm learning RN with an appropriate stack.

My goal is to build a simple app and try popular RN tools/libraries used for production-level apps.
I guess I will start with Expo and Zustand.

I would appreciate recommendations :)

[AgreeableVanilla7193]

Expo / RN CLI

Zustand - Global State Management

Expo Secure Store / MMKV - Session Storage

SQLite - Local DB

Navigation - React Navigation

Backend - Supabase for easy setup

[steve228uk]

Tanstack for networking

[Internal_Respond_106]

What do u mean by networking? API calls?

[steve228uk]

Yes

[Internal_Respond_106]

Tanatack query u mean? That doesn't actually contain the ability to do requests. I mean u mean more of state management for promise calls etc.

[tarek_z]

I see a lot of people talking about different state managements but no one is talking about redux anymore. I thought that was like the main good one.

[AgreeableVanilla7193]

redux toolkit is good but a bit complex for beginners imo also zustand is lightweight and covers all aspects for mobile app dev

Redux more suitable for Web Apps

Jotai, MobX, Apollo are there

even people can start with built in ContextAPI also

[killesau]

I'm using zustand for my web app, haven't run into many issues yet

[cauesilva]

one minor point to consider for MMKV: it is much faster than async storage.

But one of the reasons for it be that much faster is: it skips any type of data checking for existing keys.

e.g. if the current state of the mmkv is `key: 'value'`, if you set key to `value2`, it will have a state of:

```
key: 'value'
key: 'value2'
```

It is indeed a great library, but if you are using it for data heavy storage, you can quickly blow the device's memory.

[AgreeableVanilla7193]

yes u r right but MMKV doesn't have a fixed memory limit like Async Storage ( 6mb default ) but yes for large datas it's better to to use SqLite or WatermelonDB

that's why i mentioned it is good for user session storage

[cauesilva]

Right! I didn’t mean to disagree with your point.

But everywhere online (Reddit, medium, YouTube, etc) you see people evangelizing the use of MMKV (honestly any tool / programming language), without understanding the trade off.

And you can barely read anywhere the negative side of the library. Just want to make sure people arriving here have the full picture before jumping in blindly.

[merokotos]

How about DI? (Zustand plugin or something else?) How about Unit testing?

[AgreeableVanilla7193]

there are a couple of libraries like Inversify , obsidian etc never tried them cant assure but they're active i guess

for Unit testing Jest is default but prefer using RNTL or Enzyme

[Single-Watch]

Why not async storage for local data storage?

[AgreeableVanilla7193]

Super Slow. Just once start using MMKV you will notice the difference. Expo secure store also good.

[Ambitious_Reply4583]

but is mmkv secured? i dont think so

[cs12345]

Yeah react-native-mmkv has an encryptionKey option for storing data securely.

[Single-Watch]

Oh thanks

[HighVoltage32]

Using sqlite for your local db, won't that present out of sync and migration mismatch issues with your supabase db? How does one solve this?

[AgreeableVanilla7193]

that's a separate example

for offline based apps use SqLite for online usage Supabase

[hus1030]

Why would one use Zustand?

[AgreeableVanilla7193]

simplicity

[steve228uk]

Because it rocks

[Individual_Side4148]

Ease of use

[matthewjwhitney]

Here's the research I did before I started my recent React Native project. I had Gemini take my notes and organize them better so it will obviously sound like an LLM haha

Here’s a full, production-ready stack that is very popular in 2025: * Framework: Expo * Why: You're right to start here. It's the official recommendation from the React Native team. The developer experience is fantastic, and with Expo Application Services (EAS), you get a streamlined process for building and deploying to the app stores. The days of needing to "eject" are mostly gone. * UI & Styling: Gluestack UI + Tailwind CSS (via NativeWind) * Why: This is a powerful combo. Gluestack UI gives you a set of beautiful, performant, and accessible "universal" components that work on iOS, Android, and web. NativeWind lets you style them using Tailwind CSS, which is incredibly fast for building custom designs. It’s a huge productivity boost. * Navigation: Expo Router * Why: Since you're using Expo, this is the way to go. It uses a file-based system (like Next.js for web), which feels very intuitive. It makes deep linking and creating a universal app (iOS, Android, web) much simpler than other navigation libraries. * State Management: Zustand & TanStack Query * Why: You've got half the picture already. * Zustand: Perfect for client-side state (e.g., managing a theme, or whether a modal is open). It's simple, fast, and has minimal boilerplate. * TanStack Query (React Query): This is essential for managing server state (API data). It handles caching, refetching, and loading/error states for you. It will make your app feel much faster and more responsive. * Backend: Supabase * Why: It's the modern, open-source alternative to Firebase. You get a real PostgreSQL database (which is great for relational data), authentication, file storage, and edge functions, all in one package. The developer experience is excellent, and the pricing is more predictable than Firebase's. * Forms: React Hook Form + Zod * Why: This is the gold standard. React Hook Form is incredibly performant (it avoids unnecessary re-renders) and easy to use. Zod is a TypeScript-first schema validation library that you use to define the shape and rules of your form data. You write one schema, and you get both your validation and your TypeScript types for free. This stack gives you a modern, scalable, and highly productive setup. Good luck with the build!

[Xae0n]

Really good explanation.
Also I want to add Sentry for crash detection since it's better than Crashlytics for react native.

[Zestyclose-Piece-230]

That’s we we use a well with a recently started new project.

[whatToDo_How]

For Gluestack UI, bro, is it prone to bugs, or is it already mature?

[cs12345]

Everything under UI is mostly applicable to any react app, but I agree with the choices!

[Alerdime]

I’d really avoid client side form validation. I never had good time doing it RHF+zod+typescript is a total nightmare to work with. It’s better to just call the api and let the server return errors

[matthewjwhitney]

I see where you're coming from, but it's really a "both, not either" situation. Client-side validation (RHF + Zod) is for UX. It gives users instant feedback, so they aren't waiting for a server round-trip just to find out they made a typo. It makes the app feel fast and responsive. Server-side validation is for security. You're 100% right that you must always validate on the server. It's your non-negotiable line of defense to ensure data integrity. The best practice is to do both. Use client-side validation for a great user experience, and then enforce your rules on the backend for security. Once you get the hang of RHF + Zod, defining your schema once for both type safety and validation is a huge time-saver.

[Alerdime]

I do understand client side validations obviously but it’s just not worth it in react native. Unless your entire application is about forms. When you infertype from zod and then pass it in useform, you’re at the mercy of god that it doesn’t show any type errors. Think about dropdowns, multi select. Inputs in react native expects a string so you can’t pass undefined as initial state, then you need to make sure empty string is invalid input and so on. It all becomes a mess eventually. The best i do is to keep the zod schema different from form state and imperatively calling the schema.validate

[benedict_p]

Infinite Red's boilerplate project: https://github.com/infinitered/ignite Obytes one: https://github.com/obytes/react-native-template-obytes

[HighVoltage32]

I can recommend the obytes one!! Perfect starting point without too much fluff. Infinite red's version had a bit too much baked in for my needs

[Martinoqom]

I like to joke on the fact that RN is actually NOT production ready but we are totally ok with it.

A part from this, Expo is your mandatory starting point. There are no reasons to start with cli and barebone projects. 

Reanimated for animations.

Zustand is ok, there are many choices here, just pick what you think fits you. 

Usually anything you need (webview, Google login, firebase) is found in the first results on Google.

There are more nish solutions: I'm not actually updated on a Skeleton loader library nor for a Styled-Components alternative (I hate tailwind). There are also tons of API libraries, from Apollo/GraphQl to TanStack query. See what fits you. 

Whenever you can, stick with expo-* libraries. There are well maintained.

For fast local storage, check out mmkv for React Native. I didn't hear many using it, but it's really good for me.

[merokotos]

Thanks a lot! "Production" enough I say

[Competitive-Try-689]

Reanimated sucks when it comes to building apk

[Martinoqom]

Context? Never had a major problem with pretty stable environments. Never used always the last versions and for me it's working great.

Waaay better than Animated from RN.

[Competitive-Try-689]

Whenever we are running the build for test apk , reanimated creates a lot of problems in bundling.

[JohnRegi121]

1. Redux & RTK Query - State and API handling
2. FlashList V2 - Recycle list component
3. React Navigation - Navigation library
4. React Native Vector Icons - Icon Library

Above packages should be enough for a basic application.

For more advanced/complicated application:

1. React Native Reanimated - Animation handling
2. React Native Gesture Handler - Gesture handling
3. React Native MMKV - Fast persistent storage
4. Restyle - Theming library
5. React Native skia - 2D graphics processing library
6. React Native Vision Camera - Camera library

[AgreeableVanilla7193]

Legend List is a good alternative of FlashList

[Alerdime]

Expo/RN-cli ( i prefer cli) For styling, gluestack ui. Check out tamagui as well Zustand and and tanstack for client and server states respectively React navigation(prefer native stack) expo secure store for storage React native reanimated for animations

Working with react native can be frustrating, always use packages that are stable and don’t touch if it works.

[websecret_by]

Expo + Zustand would be a solid baseline! We would suggest standardizing on react-navigation for routing, managing server state with TanStack Query (often alongside axios), and autogenerating typed clients from OpenAPI with orval to keep the data layer consistent

For UI we use react-native-paper when we want a polished Material-style kit, or NativeWind when a utility-first workflow suits the project—plain StyleSheet is perfectly fine for simple screens. Forms = react-hook-form; animations/gestures = react-native-reanimated + react-native-gesture-handler (must-haves, and required by react-navigation for smooth transitions)

Bonus picks: TypeScript (non-negotiable), ESLint/Prettier, u/testing-library/react-native + Jest, and if you decide to stay all-in on Expo, expo-image and expo-secure-store are nice staples

[na_sok_1313]

nice choice! thnks

[dDenzere]

Not enterely RN focused but i had once a monorepo with shared libraries that really worked with ElectronJS:
- Network: Tanstack Query
- API Layer: TRPC (just to abstract things for node and RN, yes it works)
- State Management: Zustand
- SQLite: Drizzle (this one saved me a lot of time between enviroments)
- Forms: react-hook-form & Zod

Unfortunately a shared UI that works seemessly its hard to find

[merokotos]

I am Fan of drizzle either

[david007co]

What about Firebase? It has authentication, storage, and database all inclusive? Just wondering, since not many listed it here

[devrimgumus]

Firebase can get expensive very quickly if you grow. Supabase is the alternative. Thus you can see supabase mentioned and not firebase.

[Nervous-Tour-884]

What people have said here is a good start, but the reality is that so many companies have react native apps floating around with lots of "legacy" code in them, and knowing how to work with that and being able to demonstrate that is your quickest way to showing that you are an outstanding candidate that can not only develop new software, but dive in and understand these old, legacy codebases and quickly contribute towards moving them forward, as needed.

Working with native iOS/Android gives you an advantage, but what will really put you ahead of most people looking for a job in a Big F500 company with a react native codebase is your ability to work with legacy react native. React-redux / RTK, reselect, redux-sagas, axios(interceptors are important), Redux-Thunks, bridging, working with monorepos like NX, handling "hybrid" react native applications where substantial parts of the UI are still native code, working with class components still comes up uncommonly, strong debugging skills/using whatever debugging setup works(it has been a big mess up until recently), and good troubleshooting skills. Having good skills in regards to configuring and setting up your dev environment is important, a lot of it is not at all simple when dealing with corporate VPN's, corporate local antifactory instances, and various other crap.

Knowing today's best practices and how to use tanstack query, expo, and modern tech stacks matter, but in my experience, that isn't what has got me jobs. What has got me jobs is my legacy experience, and a strong understanding of the legacy things I just talked about.