How to choose a React Native boilerplate in 2026

To choose a React Native boilerplate, check five things: that it is on a current Expo SDK and the New Architecture, that its libraries are maintained, that its features can be removed cleanly, that authentication and payments are actually finished, and that a coding agent can work in it safely, with written conventions, tests and type checks it can run.

A boilerplate gives you a project where navigation, state, sign-in and the rest are already answered. You are taking on a set of decisions someone else made. Good ones save you weeks; bad ones cost more than starting from scratch would have.

Which is the whole problem with choosing one.

Start from what is current in October 2026

A boilerplate is a snapshot of a dependency tree on the day it was last updated. So the first check is the date on that snapshot.

As of October 2026, the latest Expo SDK is 57, which targets React Native 0.86 and React 19.2 (Expo SDK reference). React Native itself is at 0.87 (React Native versions); Expo SDKs trail React Native by a release, which is normal.

Expo's version table: each SDK pins a React Native and React version. Source

The bigger line to check is the architecture. React Native 0.82 was the first release that runs entirely on the New Architecture, and Expo SDK 55 and later cannot turn it off. Expo SDK 54 is the last SDK that still allows the old one. A boilerplate on SDK 54 or earlier is not broken, but upgrading it is the first job you inherit, and it is not a small one if any of its native libraries never migrated.

Three other things should be there by default now:

• Expo, not the bare CLI. React Native's own docs recommend starting with a framework, and Expo is the one they name. We argued the details in Expo or bare React Native.
• Expo Router. File-based routing, which works the way routing works in Next.js. It is what create-expo-app gives you today.
• Development builds and EAS. A development build is your own version of Expo Go with your native libraries compiled in. EAS Build compiles iOS binaries in the cloud, so you do not need a Mac. A boilerplate should ship working build profiles for both.

React Native's own setup guide recommends starting with a framework, and names Expo. Source

The libraries you are inheriting

Every boilerplate picks your dependencies, and you live with them for as long as the project lasts. Three choices matter more than the rest.

Styling decides how much of your CSS knowledge transfers. Tailwind-style classes are now the common answer. NativeExpress uses Uniwind, which brings Tailwind CSS v4 to React Native and compiles through Metro; NativeWind is the other well-known option. Either is fine if it is current.

Components decide what your screens are made of. HeroUI Native ships accessible components styled with Tailwind, which is a short step if you already build for the web. A boilerplate with no component library is not wrong, but you will build buttons, sheets and inputs yourself.

Server data and forms. React Query for server state, React Hook Form or TanStack Form with Zod for validation. These are boring, widely used and well documented, which is what you want here.

Beyond the picks themselves, look at whether each library is maintained. An unmaintained dependency becomes your problem on the day React Native changes underneath it.

Free React Native boilerplates are a real option

Before you pay for anything, look at the free starters. They are good, and for some projects they are the right answer.

Starter	What it gives you	Good for
create-expo-app	Expo's official template: Expo Router, TypeScript, an AGENTS.md	Learning, or a project where you want every decision yourself
Ignite	Infinite Red's boilerplate since 2016: generators, theming, Jest and Maestro, MIT licensed	Teams who want a proven structure and a CLI to scaffold screens
Obytes starter	Expo Router, Uniwind, Zustand, React Query, TanStack Form, Jest, Maestro, CI workflows, MIT licensed	Developers who want a well-tooled base and plan to build auth and payments themselves

What the free ones mostly leave to you is the part with wrong answers: sign-in with Apple and Google, purchases and restore, a paywall the server enforces, row-level security, and a store submission route. That is the gap a paid kit is meant to fill, and the comparison on our React Native starter kit page is laid out line by line.

The structure you are inheriting

Organize around features rather than technical layers. A folder per feature that owns its screens, components, hooks, API calls and tests beats a folder of every screen and a folder of every hook, because a change to one part of the app then stays in one place.

Most projects claim this and few of them mean it. There is a test that settles it: can you delete a feature?

Each feature in NativeExpress lives in src/features/<name>/ and implements one type:

export type Feature = {
  id: string;
  tabName: string;
  tabLabelKey: string;
  starterLabelKey: string;
  icon: LucideIcon;
  Preview: ComponentType;
  startRoute: (isTablet: boolean) => Href;
  getRecents: (limit: number) => Promise<FeatureRecent[]>;
};

Features import shared infrastructure and never one another, and yarn check:features fails the build if one tries. On the server, each feature keeps its own edge function directory and its own SQL block in the migration, fenced between -- feature:chat:start and -- feature:chat:end.

The payoff is that deleting one is a command rather than an afternoon:

yarn remove:feature create

That pulls the registration, the directory, the route files, the edge function, the SQL block and the Maestro flow. There is a --dry-run for reading the damage first.

You do not need our exact commands. You need to check that whichever boilerplate you pick can do the equivalent. If it cannot remove one of its own example features cleanly, its boundaries are decorative, and everything it ships that you do not want is now yours to unpick by hand.

Two smaller checks while you are in there. Configuration should be per environment, so development, preview and production behave predictably. And the dependency list should contain only what the project uses, because every library is one more thing to update.

Authentication is the part to check hardest

Authentication is where a weak boilerplate costs you most, because it is the part you are least likely to rewrite and the part that leaks user data when it is wrong.

What to check in the implementation you are inheriting: tokens go into secure device storage rather than ordinary storage; every API call uses HTTPS; the server validates the token rather than trusting the client; and errors tell the user what went wrong without describing your internals.

Then check the store rules, because Apple enforces two of them at review. If the app offers Google sign-in, it must also offer an equivalent privacy-focused option such as Sign in with Apple (guideline 4.8). And if it lets people create an account, it must let them delete it from inside the app (guideline 5.1.1(v)). A boilerplate that ships sign-in without account deletion has handed you a rejection.

Sign-in with Google, Apple and email

Editing a profile

Free quota and a paywall the server decides

Is the boilerplate ready for a coding agent?

This section did not exist when we first wrote this post. It is now the one we would check first, because more and more people starting an app now have Cursor, Claude Code or Codex write most of it.

An agent working in a codebase it does not understand writes code that compiles and does not fit: a second styling approach, a feature that imports another feature, a Supabase call from the client that should be on the server. The boilerplate's job is to make the right way the obvious way. Four things to look for:

Written instructions the agent loads

Look for an AGENTS.md or CLAUDE.md at the root. Claude Code loads CLAUDE.md into every session and can read AGENTS.md too. Even create-expo-app now writes an AGENTS.md that points agents at the docs for your SDK version, and Obytes ships a claude.md. A file that only says "use TypeScript" is not much; a good one says where code goes and what not to do.

Expo's agent docs: create-expo-app writes an AGENTS.md, and Expo ships skills and an MCP server for agents. Source

Skills for the jobs that repeat

Agent Skills are an open format: a folder with a SKILL.md that an agent reads when a task matches it. Cursor, Codex, Claude Code, Gemini CLI and GitHub Copilot all support them. Expo publishes its own skills for Expo and EAS work, which you can add to any project.

The useful question is whether the boilerplate's skills describe its code or React Native in general. NativeExpress ships skills for setup, design, conventions, Uniwind and HeroUI Native, plus store-assets and submit skills for Claude Code, all written against the release you cloned. yarn skills:doctor reports what is configured.

Checks the agent can run

An agent is only as good as its feedback loop. If the boilerplate has strict TypeScript, a test suite and a single command that runs every check, the agent can verify its own work before you look at it. NativeExpress has yarn ci, twelve checks in one command, with Jest and React Native Testing Library for units and Maestro for flows on a device. Without something like that, you are the test suite.

One convention per problem

Agents copy what they see. A codebase with two ways to fetch data will get a third. Fewer, firmer conventions matter more for an agent than for a person, because a person asks and an agent guesses.

For the first time, I felt like I was actually going to make it to the App Store with my idea.

Judging one before you commit

Read the source of the parts you would not write yourself, which for most people means auth, payments and anything touching native code. If you cannot follow it on a first pass, you will not be able to fix it under pressure. Or ask your agent to explain it to you, which is a fair test of the agent instructions as well.

Then run it. Clone it, make a development build, sign in on a real phone and try a purchase in the sandbox. A boilerplate that takes a day to get running will take a day every time something changes.

We build NativeExpress on the practices above: Expo SDK 57, Supabase for auth and data, RevenueCat for purchases, three removable AI features and skills for your agent, bought once with the full source on GitHub. Whether you use ours or someone else's, read that code before you build a project on top of it.

FAQ

What is the best React Native boilerplate?

There is no single best one; it depends on what you want to own. create-expo-app is best if you want every decision yourself, Ignite and Obytes are strong free bases if you will build auth and payments yourself, and a paid kit makes sense when you want those finished. Whatever you pick, check that it is on a current Expo SDK.

Should I use Expo or the React Native CLI for a new project?

Expo. React Native's own documentation recommends starting with a framework and names Expo, and development builds removed the old limits on native code. We cover the remaining reasons to go bare in Expo or bare React Native.

Is a paid React Native boilerplate worth it?

It is worth it when it saves you the parts with wrong answers: sign-in with Apple, purchases and restore, a server-side paywall, account deletion and store submission. If you only need navigation and a theme, a free starter does that well and a paid one is not worth the money.

Can I build a React Native app with Cursor or Claude Code?

Yes. It goes much better in a codebase with written conventions, agent skills and checks the agent can run, so it can verify its own changes. You still make the product decisions, sign in to services and test on your phone.