Setting Up React Native: Everything I Wish I Knew
The setup decisions that will save you weeks of pain — from Expo vs bare workflow to monorepo structure and CI from day one.
Setting Up React Native: Everything I Wish I Knew
Stream #1 was me setting up the React Native project from scratch. I made several decisions I've since reconsidered, and a few I'm really glad I made. Here's the full breakdown.
Expo vs Bare Workflow
I went with Expo managed workflow and I'd make the same call again. The tradeoffs are real — you give up some native module flexibility — but for a social app that doesn't need custom native code, the developer experience is dramatically better.
The thing that convinced me: Expo's OTA (over-the-air) updates. Being able to push JS-layer fixes without going through App Store review is genuinely valuable when you're iterating fast. I've already used it twice to fix bugs that would have taken 3–5 days to ship through the normal review process.
If I needed custom camera processing, Bluetooth, or deep native integrations, I'd reconsider. For a social feed app, managed workflow is the right call.
Monorepo from Day One
This is the decision I'm most glad I made. The app shares a lot of code with the web backend — types, validation schemas, utility functions, API client logic. Having everything in a single repo with shared packages makes this trivial.
I'm using Turborepo for the monorepo setup. It handles caching and task orchestration well, and the setup cost was maybe half a day. The alternative — maintaining separate repos and publishing shared code as npm packages — would have been a constant source of friction.
TypeScript Everywhere
Non-negotiable. The app has a complex data model (users, posts, comments, reactions, follows, blocks, notifications) and TypeScript catches a huge percentage of bugs before they ever run. I've had zero "undefined is not a function" crashes in production because the types caught them at compile time.
The one thing I'd do differently: I'd be stricter about strict: true from the start. I enabled it halfway through and had to fix about 200 type errors. Not fun.
CI from Day One
I set up GitHub Actions on day one to run type checking and tests on every PR. This felt like overkill for a solo project, but it's paid off multiple times. The discipline of "nothing merges without passing CI" has caught several regressions that I would have shipped otherwise.
The CI pipeline runs in about 4 minutes: type check, unit tests, lint. Fast enough that it doesn't slow down development.
What I'd Do Differently
Navigation library: I went with React Navigation and it's fine, but I've been watching Expo Router mature and I think I'd use it if I were starting today. File-based routing is just a better mental model.
State management: I started with Zustand and it's been great. No regrets there. Redux would have been overkill.
Testing: I didn't write enough tests early on. I have good coverage on the business logic layer, but the UI components are undertested. This is coming back to bite me now that I'm refactoring.
The full setup stream is in the archive. It's 2h 55m but the first 45 minutes cover all the decisions above if you want the condensed version.
Explore Topics
Found this useful? Share it with your network.