"I just want to build my app."
That sentence sounds simple. But if you've ever started a new React Native project, you know that is rarely what actually happens.
You open your terminal with excitement:
npx create-expo-app my-app
Five minutes later, you're already searching:
- "How to set up Tailwind CSS in React Native?"
- "Should I use NativeWind?"
- "How do I share components between mobile and web apps?"
- "Expo Router or React Navigation?"
- "How do people organize React Native monorepos?"
- "Should I use Turborepo?"
- "How do I keep multiple apps sharing the same UI?"
Before you have written your first screen... you have already spent hours making architectural decisions. Not product decisions. Not business decisions. Just project setup.
The Invisible Tax Every React Native Developer Pays
Imagine you are opening a restaurant. You have recipes. You have chefs. You know exactly what food you want to serve. But before opening the doors, someone tells you:
"First, build the kitchen."
So you start researching:
- which stove?
- Which oven?
- Which refrigerator?
- How should the plumbing work?
- How do multiple restaurants share ingredients?
Months later... you still haven't served a single customer.
Software development often feels exactly like that. We don't struggle because building apps is hard. We struggle because building the environment to build apps is hard.
Every New Project Starts With The Same Questions
Every engineering team eventually reaches the same crossroads:
"How should we organize this codebase?"
- Should every app have its own repository?
- Or should they share everything?
- Should design components live inside the mobile app folder, or inside separate workspace packages?
- What about authentication, API clients, themes, icons, and utilities?
Every answer seems correct... until six months later.
Then The Real Problems Begin
Imagine your company builds two applications: a Customer App and a POS App. Both need:
- Buttons & Forms
- A consistent design theme
- Icons & Typography
- Authentication plumbing
- A typed API client
At first, copy-pasting feels faster. Until the designer changes one button style. Now your codebase looks like this:
Customer App 👉 Updated ✅
POS App 👉 Outdated ❌
Next week, the typography changes. Then the color palette. Then spacing. Suddenly, you are spending your weekends maintaining two separate design systems that were supposed to be one.
"Let's Make a Shared UI Package"
Sounds easy. Until you actually try to set it up in a mobile environment. Now you are diving deep into:
- npm / pnpm workspaces
- Turborepo pipeline caching
- Package export maps
- Metro bundler configuration
- TypeScript path aliases & references
- Babel plugins & module resolution
You started because you wanted one shared button. Now you are spending your evening debugging why Metro cannot resolve an SVG icon.
Styling Was Supposed To Be Easy, Too
Most web developers already know and love Tailwind CSS. So naturally, they ask:
"Can I just use Tailwind in React Native?"
The answer is yes. Then comes another rabbit hole:
- Babel plugins
- Metro config adjustments
- Dark mode persistence
- Theme CSS variables
- Hot reload bugs
- And version compatibility.
When NativeWind v5 arrived, it solved many long-standing pain points and made styling feel much closer to the web Tailwind experience developers love. But getting everything configured correctly - and keeping it working smoothly across SDK upgrades - still takes considerable time.
The styling itself isn't the hard part. The boilerplate setup is.
Building Components Is Harder Than It Looks
Most production apps don't need fancy, animated components. They need consistent, accessible components. A button should always look and feel like a button. An input should always handle keyboard focus correctly. A modal dialog should behave predictably across iOS and Android.
Projects like React Native Reusables made this dramatically easier by bringing modern, accessible UI primitives into the React Native ecosystem. Instead of reinventing custom components for every project, you start with well-designed building blocks.
But even then... someone still has to integrate, theme, and wire everything together across version upgrades.
⚡ The NativeWind v5 Migration Gap (And How RNStack Solves It)
Right now, React Native Reusables officially targets NativeWind v4. If you try using it with NativeWind v5, you will immediately hit styling bugs and breaking changes.
In RNStack, I have already fully migrated all included components to NativeWind v5 (Tailwind v4) and pre-fixed common problem areas—especially complex components like
Icon,Button, andSelect—so they render seamlessly across iOS, Android, and web out of the box.
And Then Comes Scale
Your first app becomes successful. Now the business asks:
"Can we build another app for our internal team?"
Great! Except now your architectural requirements have multiplied:
📱 Customer App | 🛠️ Admin App | 🏪 POS App | 🚚 Driver App
Four applications. One engineering team. One design language. One backend API. One authentication system.
Should you create four separate repositories? Or one? This is where monorepos stop being a buzzword and start becoming a practical survival tool.
A monorepo isn't just about putting everything into one giant folder. It is about giving every project access to the exact same foundation: One shared UI. One shared API layer. One shared configuration. One source of truth.
But Monorepos Bring Their Own Challenges
Large repositories can easily become painfully slow. Without proper tooling, every build starts rebuilding everything from scratch, and every dependency install feels heavier.
That is where Turborepo changes the story. Instead of rebuilding the entire house every time you make a change, it only rebuilds the rooms you have actually touched.
The result is a development workflow that stays lightning-fast even as your codebase grows. Not because your apps became smaller—but because your tooling became smarter.
After Solving The Same Problems Again And Again...
I noticed a pattern. Every project I worked on looked different on the surface... but the foundational setup looked almost identical.
Every time I started a new React Native project, I found myself
- copying the same workspace files
- installing the exact same dependencies
- configuring the same Metro resolver fixes
- setting up the same TypeScript aliases
- building the same shared UI package
- and configuring Expo Router and NativeWind.
Over and over again.
Eventually, I stopped asking: "How do I start another project?"
Instead, I asked: "Why am I solving this plumbing problem every single time?"
That's Why I Built RNStack
RNStack isn't trying to replace Expo. It isn't another heavy UI library. It isn't a random collection of disconnected snippets.
It is simply the mobile-first, production-ready monorepo foundation I wished every new React Native project started with. A clean architecture where the difficult, time-consuming setup decisions have already been made for you. So you can focus on building your actual product instead of wrestling with build tools.
One Command To Start
You can scaffold a clean, production-ready project instantly using the create-rnstack npm package:
pnpm create rnstack my-app
A few moments later, you have a fully wired workspace that already includes:
| Category | Pre-Configured Tooling |
|---|---|
| Core Framework | Expo (SDK 56) + Expo Router |
| Styling & UI | NativeWind v5 + React Native Reusables |
| Architecture | Turborepo + pnpm Workspaces |
| Shared Packages | Pre-linked @repo/ui, @repo/api-client, and @repo/config
|
| Code Quality | Strict TypeScript, Biome, Husky |
| Reliability | Automatic Expo dependency validation & native bundle ID management |
No hunting through outdated Medium tutorials. No copy-pasting broken configurations. No wondering whether you forgot a crucial setup step.
Small Details Matter
The biggest improvements in developer experience are often the ones you never notice because everything just works. RNStack automatically handles the subtle details that are easy to forget but painful to fix later:
- ✅ Unique Native Bundle IDs: Every generated app automatically gets a clean, unique bundle identifier.
- ✅ Aligned SDK Versions: Expo dependency versions stay strictly aligned with your installed SDK.
- ✅ Immediate Git Hooks: Pre-commit formatting and linting work right out of the box.
- ✅ Zero Bloat: Projects start clean without shipping dozens of unnecessary boilerplate demo screens.
These aren't flashy marketing features. They are the quiet, architectural details that save dozens of hours over the lifetime of a production codebase.
The Goal Was Never To Build Just Another Boilerplate
There are already plenty of starters out there. But most of them stop right after generating a few static files.
RNStack tries to go one step further: it gives you an evolving foundation meant to survive far beyond your first commit. Something robust enough to build your next weekend side project on, scale into a startup MVP, or ship to thousands of production users.
Try It Out & Join The Journey
If you are starting a new React Native project this week, give RNStack a spin. I would genuinely love to hear your feedback—what feels intuitive, what feels awkward, and what could be improved!
Every issue opened, suggestion made, and pull request submitted helps make the mobile development experience better for the next engineer.
🔗 Get Started in Seconds
Scaffold your new project right now from your terminal:
pnpm create rnstack my-app
- 📦 NPM Package: Check out the CLI documentation on the create-rnstack npm page.
- ⭐ GitHub Repository: Explore the monorepo architecture, star the repo, or contribute on sanjaysah101/rnstack.
If RNStack saves you a few hours—or helps you skip a frustrating evening of configuration—that is exactly why I built it.
Happy building! 🚀
Top comments (0)