skip to content

How do you create a React Native app without a framework in 2026, and what happened to the old react-native init command?

level: juniorimportance: should knowfreq 45%

answer

  1. npx, not a global install
  2. the Community CLI package runs init
  3. --version pins the React Native release
  4. --template picks a custom template
  5. react-native init removed in 0.77

basics

~10 s

Run npx @react-native-community/cli@latest init MyApp, optionally with --version to pin a React Native release or --template for a custom template. The old react-native init was deprecated in 0.75 and stopped working in 0.77.

solid answer

~40 s

A no-framework app is generated by the React Native Community CLI, run through `npx` rather than installed globally: `npx @react-native-community/cli@latest init PetSitter`. `--version 0.87.1` pins the React Native release the project is created with, and `--template` starts from a custom template instead of the default `@react-native-community/template`. The old `npx react-native init` was sunset in 0.75, when the template moved out of the `react-native` package into its own repository, and it stopped creating projects in 0.77. Since 0.76 `react-native` no longer depends on the CLI, yet commands such as `react-native start` and `run-android` still delegate to it, so bare apps list `@react-native-community/cli` in their own `devDependencies`. Any globally installed `react-native-cli` should be removed, because the docs warn it can cause unexpected issues.

code

bash · 4 lines
bash
npm uninstall -g react-native-cli @react-native-community/cli
npx @react-native-community/cli@latest init PetSitter --version 0.87.1
cd PetSitter
npm start

go deeper

for a junior

Recall the npx @react-native-community/cli init command, the --version and --template options, and that react-native init no longer works.

for a middle

Explain the 0.75 to 0.77 steps: the template move, the CLI dependency removal and the final removal of init, and why global CLIs cause problems.

for a senior

Standardise project creation for a team: pinned versions, a maintained custom template, and CLI dependencies declared in each app.

for a principal

Decide whether an in-house template or a framework starter should be the organisation's default, and who maintains it across React Native releases.

## The command today React Native apps that do not use a framework are created with the **React Native Community CLI**: ```bash npx @react-native-community/cli@latest init PetSitter ``` `npx` downloads and runs the CLI package for this one command, so nothing needs to be installed globally. The result is a new folder with a TypeScript app (`App.tsx`), a `package.json`, Metro and Babel configuration, and full **`ios/` and `android/` native projects**. Since 0.77 the iOS app in the template is written in Swift (`AppDelegate.swift`), although an Objective-C++ variant remains supported. ## Useful options | Option | What it does | When you use it | |---|---|---| | `--version X.Y.Z` | creates the project for a specific React Native release | matching a company's pinned version, or reproducing a bug | | `--template <name>` | starts from a custom template instead of the default one | an internal template with your navigation, linting and CI already set up | To pin both the CLI and React Native versions, the docs show the pattern `npx @react-native-community/[email protected] init AwesomeProject --version X.XX.X`. ## What happened to react-native init For years `npx react-native init` was the standard way to start. Its retirement happened in steps: 1. **0.75 (August 2024):** the default template moved out of the `react-native` package into the separate `@react-native-community/template` package, and `react-native init` began printing a deprecation warning. It was sunset on 31 December 2024. 2. **0.76 (October 2024):** `react-native` stopped depending on `@react-native-community/cli`. In a bare app the `react-native` commands (`start`, `run-android`, `run-ios`) and the default autolinking config command still delegate to that CLI, so the project lists it as its own dev dependency. 3. **0.77 (January 2025):** the deprecation was completed; `react-native init` no longer creates projects. The alternatives are a framework (`npx create-expo-app`) or calling the Community CLI directly. The reason was the framework-first recommendation: the React Native team did not want core to ship an opinionated starter, and moving the template out let it change without a React Native release. ## Custom templates The default template is deliberately minimal: an `App.tsx`, the native projects and tooling configuration. Teams that create several apps often maintain an **internal template** that already includes their navigation setup, lint rules, test configuration and CI files, and pass it with `--template`. The trade-off is ownership: a custom template must be updated for every React Native release, or each new app starts on an outdated native setup and inherits an upgrade on day one. The template format itself is documented by the Community CLI. ## Global CLIs cause trouble Older tutorials told you to `npm install -g react-native-cli`. The current docs say to remove any global `react-native-cli` or `@react-native-community/cli` install: ```bash npm uninstall -g react-native-cli @react-native-community/cli ``` A global install can shadow the project's own CLI version and produce confusing, version-mismatched output. ## After init - Start Metro with `npm start`. - Build and launch with `npm run android` or `npm run ios`. - On iOS, if dependencies are out of sync, `cd ios`, `bundle install`, then `bundle exec pod install`. ## Checking what you got 1. `package.json` lists `react-native` at the version you asked for, plus `@react-native-community/cli` in `devDependencies`. 2. `ios/` contains the Xcode project and a `Podfile`; `android/` contains `settings.gradle` applying the React Native settings plugin. 3. `npm run ios` and `npm run android` build and launch the app with Metro running. ## When not to use init The docs say you do not need it when you are integrating React Native into an existing native app (brownfield), when your project already uses Expo, or when you are adding Android support to an existing React Native project. Third-party starters exist too, but the Community CLI is the documented default for no-framework apps.

  • Why did the template move out of the react-native package?
    While it lived inside `react-native`, every template change needed a React Native release. Moving it to `@react-native-community/template` in 0.75 let the community update it independently, and matched the framework-first recommendation that core should not ship an opinionated starter.
  • A bare app on 0.87 prints a warning that react-native depends on @react-native-community/cli for CLI commands. Why?
    Since 0.76 the `react-native` package no longer depends on the CLI, but its `start`, `run-android` and `run-ios` commands, and the default autolinking config command, still delegate to it. When the project does not list `@react-native-community/cli` in its own `devDependencies`, `react-native` warns and asks you to add it.

saying these in an interview costs you the question

  • npx react-native init is still the supported way to create a project
  • The default template ships inside the react-native npm package
  • Installing react-native-cli globally is the recommended setup
  • react-native depends on the Community CLI, so no extra dependency is needed
  • --version sets the version of the new app itself, not React Native