Most advice about free React Native boilerplates is either "they're great, use one" or "they're worthless, buy mine." Both are wrong, and in the same way: they treat a boilerplate as one thing.

It is two things. A boilerplate makes architectural decisions for you — folder structure, navigation, state, testing, CI — and separately it may or may not wire up the services your app needs to make money. Free boilerplates are genuinely excellent at the first job. Almost none of them attempt the second.

That is not a flaw. It is a structural consequence of what an open-source project can maintain. Understanding why tells you exactly when free is the right call.

Key Takeaways

• The two most popular free React Native boilerplates, Ignite (19.9k stars) and the Obytes starter (4.3k stars), both ship architecture, testing, and CI — and neither lists authentication, in-app purchases, or push notifications.
• That gap is structural, not lazy: payments and push require accounts, credentials, and a backend that an open-source repo cannot hand you.
• Free boilerplates save you the architecture argument. Infinite Red claims Ignite saves "two to four weeks" per project, which is their own figure, not independent research.
• The ongoing cost of any kit, free or paid, is SDK upgrades. Expo ships three SDK releases a year with a support lifetime of about one year.
• Free is the right choice when your app does not charge money, or when you want to learn the systems you are skipping.

What free boilerplates actually give you

Two projects dominate this category. Here is what each one states it provides:

Sources: the Ignite README and the Obytes starter README, read 14 September 2026.

This is a real contribution and it should not be undersold. Deciding how to structure a React Native codebase, which navigation library to standardise on, how to test, and how to wire CI is a genuine multi-day argument on a new team, and these projects have already had it and written the answer down. Infinite Red describes Ignite as "battle-tested" across "9 years of continuous development" and claims it saves developers "two to four weeks of time on average" at the start of a project. That is their own estimate rather than independent measurement, but the direction is credible: architecture is exactly the kind of work a boilerplate can carry.

What neither project claims to carry is the commercial layer.

The line almost every free boilerplate stops at

Payments is the clearest case, and the reason is worth spelling out because it explains the whole category.

An in-app purchase integration is not just code. It needs a paid developer account on both stores, products configured in App Store Connect and Google Play Console, signing credentials, a server endpoint to validate receipts, and a decision about what happens when a receipt is valid but the user reinstalled on a new device. A public repository cannot ship you any of that. It can ship you an example, but an example that nobody runs in production drifts out of date quietly, which is worse than no example.

The same logic applies to push notifications, which need provider credentials uploaded per platform, and to any backend, which needs an account and security rules that are specific to your data model.

So free boilerplates converge on the parts that are pure code and stop at the parts that need accounts. That is a rational boundary, not neglect.

It is also the expensive boundary. The store commissions you are working against are real: Apple's Small Business Program charges 15% for developers making up to $1M in proceeds in the prior calendar year, with the standard rate above that (Apple Developer), and Google moved US, UK, and EEA subscriptions to 10% plus a 5% billing fee from 30 June 2026 (Google Play Console Help). Getting billing right is not optional overhead; it is the mechanism your revenue flows through.

For a fuller inventory of what a blank project leaves you, I audited a fresh Expo install in what create-expo-app still leaves you to build — the answer there was 23 dependencies, two screens, and zero of the six systems.

The cost nobody prices in: staying current

Whatever you adopt, you inherit its upgrade schedule.

Expo ships three SDK releases a year, and Expo's own guidance puts the supported lifetime of any given SDK at approximately one year (expo/fyi). On top of that, both stores move their floor annually — Google Play has required new apps and updates to target Android 16, API level 36, since 31 August 2026 (Play Console Help).

This is where the free-versus-paid question gets more interesting than the feature list suggests. A boilerplate is a snapshot. The moment you clone it, it starts aging, and you own the diff.

You can see the effect in the category leader: Ignite's README lists Expo 55, while the current release is SDK 57. That lag is completely normal for a volunteer-maintained project and is not a criticism — three releases a year is a punishing cadence for anyone. But it is the single most important thing to check before adopting any kit, free or paid. A kit that tracked the SDK last year and stopped is not a head start; it is a migration you have agreed to perform.

The practical test: before you clone anything, look at the commit history rather than the feature list. A kit updated within the last SDK cycle is an asset. A kit two cycles behind is homework.

When free is clearly the right call

Free boilerplates are the correct choice more often than vendors like me admit. Use one when:

• Your app does not charge money. The entire paid-kit value proposition is the commerce layer. If you are building an internal tool, a client project billed hourly, or a free utility, you are paying for something you will delete.
• You are learning React Native. Inheriting a configured payments stack teaches you nothing about payments. Build it once, badly, on purpose. The understanding is the point.
• You have strong opinions about architecture. Ignite and Obytes make different, defensible choices. If you already know which you prefer, a free kit that matches your taste is better than a paid one that does not.
• Your constraint is time-to-prototype, not time-to-revenue. If you need something on a device this week to show someone, architecture is all you need.

When it stops being the right call

The calculation flips when the commerce layer is on your critical path and your time has a price.

A useful way to think about it: the US Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 as of May 2025 (BLS Occupational Outlook Handbook), which works out to roughly $65 an hour, so a week spent wiring auth, a paywall, and push costs about $2,600 of your own time. Those figures are arithmetic on the BLS median rather than a published statistic, and they understate true cost because a salary-derived rate excludes overhead — substitute your own number.

Set that against what you are buying. If a paid kit removes a week and costs less than a week of your time, the arithmetic is straightforward. If it removes two days and costs more, it is not.

Worth being honest about the other side of the ledger too: the payoff distribution for subscription apps is steep. Across a dataset of more than 115,000 apps, RevenueCat reports that 17.3% of newly launched apps hit $1,000 a month and 4.6% hit $10,000 a month in their first two years (State of Subscription Apps). Shipping the paywall faster improves your odds of finding out which bucket you are in. It does not move you between buckets.

Where our kit sits in this

To be direct about the bias in this article: we sell a paid one.

The CodeBaseHub React Native starter kit is built for the case the free kits deliberately leave alone — Firebase auth with email, Google, and Apple sign-in; RevenueCat subscriptions with a paywall; OneSignal push; Firestore with typed hooks; and EAS build profiles for both stores. It is a one-time purchase and you get the source.

If your app does not charge money, use Ignite or the Obytes starter instead. They are good, they are free, and you will not miss what we added. If it does charge money, the starter kit comparison sets out the criteria worth weighing before you pick anything.

Frequently asked questions

What is the best free React Native boilerplate?

Ignite and the Obytes starter are the two most widely adopted. Ignite has more history and a CLI with component generators; the Obytes starter is built on Expo Router with TailwindCSS and ships more CI tooling. Neither includes authentication, payments, or push, so the choice between them is about architecture preference, not capability.

Do free React Native boilerplates include in-app purchases?

Generally no. Neither Ignite nor the Obytes starter lists in-app purchases. The reason is structural: a working purchase flow needs store accounts, configured products, signing credentials, and server-side receipt validation, none of which a public repository can provide.

Is a paid React Native starter kit worth it?

It depends on one question: does your app charge money? If it does not, a paid kit is mostly selling you a layer you will delete. If it does, compare the price against what a week of your own time costs and whether the kit is being maintained against the current Expo SDK.

How do I tell if a boilerplate is still maintained?

Check the commit history and which Expo SDK it targets, not the README's feature list. Expo ships three SDKs a year, so a kit more than one cycle behind means you are inheriting an upgrade. This applies equally to free and paid kits.

Can I start free and switch to a paid kit later?

Migrating between boilerplates is usually harder than starting on the one you want, because architectural decisions propagate into every screen. It is more realistic to start free and add the commerce layer yourself than to swap foundations mid-project.

The short version

Free React Native boilerplates solve the architecture problem well and the commerce problem not at all, because the commerce problem needs accounts and credentials that an open-source repo cannot hand you. That boundary is the whole story of the category.

So the question is not "free or paid." It is whether your app charges money, and what a week of your time is worth. If it does not charge money, take Ignite or Obytes and get on with it. If it does, price the week honestly — and whichever way you go, check the commit history before you clone.