실제로 출하되는 보일러 플레이트: 2026 React 네이티브 스타터에 포함 (및 절단) 할 내용

작성자

카테고리:

← 피드로
DEV Community · Hugo Rus · 2026-09-23 개발(SW)

Hugo Rus

Why most React Native boilerplates fail past week 2

Boilerplates optimize for the wrong number. The number that matters isn’t screens included. It’s time-to-first-paid-user. Every extra screen, every extra library, every unused abstraction is a tax you pay on the second refactor. The boilerplates that survive past week 2 keep the surface area small and the defaults opinionated.

The five must-includes

  1. Auth with session restore on cold start. Sign in with Apple wired, refresh tokens handled, and a password reset that doesn’t 404 in production. The scaffold that skips this rebuilds it under pressure in month one.

  2. Payments end to end. Stripe or RevenueCat, with one test charge working in TestFlight. Not a screen with a Buy button. A working flow. Payments is the plumbing every indie dev underestimates.

  3. EAS Build + Submit wired. eas.json filled with staging and production profiles. GitHub Actions or manual submit, either works, but the pipeline must exist. If your first submission takes longer than an hour, that’s a leading indicator of shipping never.

  4. A real error boundary. react-native-error-boundary or a custom top-level catch, plus a crash-log SDK like Sentry or Bugsnag. Silent JS crashes in prod are the number one reason indie apps ship a broken v1.

  5. OTA update channels. expo-updates with channel-level control. Push a JS bundle to a beta channel, promote to production without touching the app-store binary. This is where “faster to build” becomes “faster to fix”.

The five to cut by default

  • The navigation grab-bag. Pick one (expo-router with typed hrefs) and delete the others. Multiple navigators in one boilerplate is a smell.
  • Animation libraries “just in case”. Don’t ship reanimated + moti + lottie + a bespoke animation hook. Include one and document why.
  • In-house UI kits. Every custom Button component is a maintenance burden. Use platform primitives or a maintained design-system library (Tamagui, Restyle), not a hand-rolled kit that will diverge.
  • Redux for a v1 app. Zustand or Jotai handles it. Redux plus Redux Toolkit plus RTK Query is 300 lines of setup before your first fetch.
  • The “example” screens. Delete the calendar demo, the chat demo, the map demo. They confuse new devs and drift into stale APIs.

The rename-screen test

Here’s a one-minute audit for any starter you’re evaluating. Rename screens/Home.tsx to screens/Dashboard.tsx. Everything that survives without manual patching (router, deep links, typegen) is a real boilerplate. Anything that needs a find-and-replace is a demo dressed up as one.

A pragmatic 2026 stack

  • Framework: Expo SDK 53+, expo-router with typed hrefs
  • State: Zustand for client, TanStack Query for server
  • Auth + DB: Supabase (or tinbase for local-first and self-host)
  • Payments: Stripe SDK + Payment Sheet
  • Style: Restyle or unistyles, design tokens on day one
  • CI: GitHub Actions + EAS Build with staging and prod profiles

The folder-deletion principle

The best RN scaffold is one you can delete a folder from. Every project ships a subset, and your job as a maintainer is to make the deletion trivial. We built RapidNative to generate React Native + Expo apps that start from these defaults. Grab it, or clone your own. The principles matter more than the repo.

원문에서 계속 ↗