Ignite CLI: Infinite Red's React Native Boilerplate and Generator

What Ignite actually is, and who reaches for it

Ignite is not a library you add to an existing app. It is a starting point: a CLI that copies a prepared React Native project onto disk and then gets out of the way. The repository holds two distinct things in one package, a boilerplate directory that becomes your app and a src directory that is the CLI itself, published to npm as ignite-cli with bin entries for both ignite and ignite-cli.

The README states the boilerplate has been developed since 2016 and describes it as the oldest active third-party React Native and Expo app boilerplate. The same README says the Infinite Red team uses it day to day on client work, and that developers who use Ignite report saving two to four weeks on average at the start of a React Native project. Treat that number as a claim from the maintainers, not a measurement.

The audience is narrow and clear. It fits a team that wants a working app shell, a themed component set, navigation and persistence already wired, and generators that keep new screens consistent. It fits less well anyone who has already chosen a different navigation library, a different persistence layer, or a different approach to server state. Ignite's value comes from its opinions, so replacing several of them means you are paying the cost of the boilerplate without collecting the benefit.

The fixed stack Ignite commits you to

The README publishes the stack as a table, and the version numbers are the point: React Native v0.81, React v19, TypeScript v5, React Navigation v7, Expo SDK v55. Persistence is MMKV v3, the REST client is apisauce v3, the test runner is Jest v29, dates come from date-fns v4, animations from React Native Reanimated v4, keyboard handling from react-native-keyboard-controller v1, and edge-to-edge on Android from react-native-edge-to-edge v1. Reactotron RN v5 handles debugging, Maestro handles end-to-end UI testing, and Hermes is the JavaScript engine.

What matters is the coupling. React Navigation v7 and Expo SDK v55 are not independent choices in a generated app; the navigation setup, the font loading through Expo Font v14, and the localization through Expo Localization v17 all assume that pairing. MMKV v3 sits under the persistence layer, so anything you build on top of it inherits a native module that needs a rebuild when it changes.

The README's framing is explicit: nothing makes it into Ignite unless it has been proven on projects Infinite Red works on. That is a coherent policy and it explains why the stack trails the newest releases rather than leading them. It also means you cannot swap one piece without checking how the rest of the boilerplate depends on it. The component library under docs/boilerplate/app/components is tuned for custom designs and theming, per the README, so restyling is expected work; replacing the data layer is not.

Installing Ignite and generating a first app

The README lists two prerequisites: a recent version of Node to run the CLI, and a React Native environment set up for compiling and running in a simulator, following the official React Native documentation. There is no global install step in the quick start; the CLI is meant to be run through npx.

The interactive path walks through the prompts for the options that shape your new app:

# Get walked through the prompts for the different options to start your new app
npx ignite-cli@latest new PizzaApp

If you would rather take the defaults and start coding, the README gives a second form with the --yes flag:

# Accept all the recommended defaults and get straight to coding!
npx ignite-cli@latest new PizzaApp --yes

After the CLI finishes you have a new directory named after your app, and the README points to the Getting Started Guide at docs.infinite.red/ignite-cli/Guide/ for what comes next. The repository also ships a template.config.js at the top level and a template.config.js reference in the published files list, which is how the boilerplate is described to the generator.

Troubleshooting is documented, and it is worth reading before you file anything. The README advises uninstalling any global version with npm uninstall -g ignite-cli and running through npx instead, checking your Node version with node --version, and installing nvm followed by nvm install --lts if you need several Node versions. If an Xcode error about missing command line tools blocks the install, the README gives sudo xcode-select --install as the fix.

Where Ignite is the wrong tool

The clearest failure mode is a project that already has a stack. If your team standardised on a different navigation approach, or you have a data layer you like, Ignite asks you to either discard that work or spend the first week deleting its choices. The generators and the component library are built around React Navigation v7, so partial adoption is messier than it sounds.

A second constraint is the native surface. MMKV v3, Reanimated v4, react-native-keyboard-controller v1 and react-native-edge-to-edge v1 are native modules. That is fine for a standard React Native or Expo build, but it narrows your options if you were planning to stay inside a managed workflow with no native rebuild step, or if you need to support a platform where one of those modules is not available. The README does not discuss ejecting or removing individual native modules from the boilerplate.

A third is upgrade cost. The stack table is a snapshot tied to a release, and the releases are not frequent: v11.5.0 on 2026-03-18, v11.4.0 on 2026-01-06, v11.3.2 on 2025-10-09. The most recent push to the repository was on 2026-06-07. That cadence is reasonable for a boilerplate, but it means major React Native or Expo bumps arrive in batches, and you inherit the wait. If your app needs a React Native version ahead of what the current Ignite release pins, you are on your own for the upgrade path.

Finally, the licence file is present at the repository root but the repository metadata reports NOASSERTION rather than a recognised identifier, while package.json declares MIT. Those two signals disagree, and the README does not reconcile them.

Ignite compared with a bare React Native or Expo template

The honest alternative is the template that ships with the framework itself: npx create-expo-app or the React Native community template. The difference is not quality, it is where the decisions live. A bare template gives you a running app and leaves navigation, persistence, networking, testing, theming and linting to you. Ignite gives you all of those already chosen and already consistent with each other.

That shows up most in the parts that are tedious to assemble: React Navigation v7 configured, MMKV v3 wired for persistence, apisauce v3 set up as the REST client, Jest v29 configured with a working test script, Reactotron RN v5 attached for debugging, and Maestro listed for end-to-end UI testing. A bare template gives you none of that and no opinion about it.

The cost of Ignite's approach is that you inherit its opinions wholesale. A bare template is slower to reach a first feature but never asks you to remove something. If your team already has a house style for navigation and data fetching, the bare template plus your own conventions is the more direct route, and Ignite's generators will fight your conventions rather than support them.

Maintenance, upgrades and the licence question

The repository is not archived, and the last push was on 2026-06-07. Releases land in the v11 line: v11.5.0 on 2026-03-18, v11.4.0 on 2026-01-06, v11.3.2 on 2025-10-09. The README claims continuous development since 2016, and the release history is consistent with a project that moves deliberately rather than continuously.

Upgrade cost falls into two buckets. The CLI itself is versioned and published to npm, so running npx ignite-cli@latest new gets you the current template; the README's troubleshooting section warns against a global install precisely because a stale global copy will scaffold an old stack. Your generated app, by contrast, has no upgrade path from Ignite. Once the boilerplate is copied, it is your code. Future Ignite releases do not merge into it, and the only way to take a newer stack is to diff the current boilerplate against yours and port the changes by hand.

On licensing: package.json declares MIT, while the repository metadata reports NOASSERTION. The LICENSE file exists at the root but its contents are not reproduced in the repository files available here, so I cannot confirm which text governs. Read LICENSE yourself before you ship, and if the discrepancy matters for your organisation, ask the maintainers rather than assuming. That is a factual gap, not a legal opinion.

Support runs through the help channels the README links to, and it explicitly welcomes pull requests to improve the documentation.

Editorial conclusion

Adopt Ignite if you are starting a React Native or Expo app and want Infinite Red's stack, theming and generators in place on day one; the CLI is invoked with npx ignite-cli@latest new PizzaApp and the README says developers report saving two to four weeks at the start of a project. Do not adopt it if you have already committed to a different navigation, state or persistence layer, because the boilerplate bakes those decisions in. Before you commit, verify on your machine that the CLI runs under a recent Node release, that your simulator toolchain is set up per the React Native environment guide, and that the generated app builds on the platform you ship to.

Frequently asked questions

Official sources

1. infinitered/ignite on GitHub
2. Issues
3. Project website
4. README
5. Releases