What do the React Native docs recommend for starting a new app today, and why do they favour a framework over a bare project?
answer
- a framework is a toolbox
- Expo is the recommended framework
- you use one or build one
- routing, native modules, upgrades solved
- bare is for unusual constraints
basics
~20 sThe React Native docs recommend starting new apps with a framework, and Expo is the one they name, because it already solves routing, native dependencies, native builds and upgrades; a bare project means assembling and maintaining those pieces yourself.
solid answer
~50 sSince mid-2024 the official getting-started page says a new React Native app should start with a **framework**, a toolbox of the APIs a production app needs, and it names Expo (`npx create-expo-app@latest`). The reasoning is that every real app needs navigation, access to native APIs, native dependency management, native builds and a way to upgrade React Native; without a framework you either write those yourself or stitch libraries into your own framework, and then maintain it. The docs put it as: you are either using a framework or building your own. A project without a framework is still fully supported: `npx @react-native-community/cli@latest init` creates one that owns its `ios/` and `android/` folders. The docs reserve that path for apps with unusual constraints a framework does not serve, or teams that want to solve those problems themselves.
go deeper
Recall that the docs recommend starting new apps with a framework, name Expo, and that a no-framework app is created with the Community CLI.
Explain which problems a framework solves (navigation, native modules, builds, upgrades) and what owning native folders costs without one.
Argue the choice for a concrete team: skills, need for day-one React Native releases, native customisation, and the maintenance a bare project adds.
Frame the start as build-your-own-framework or adopt one, and weigh long-term upgrade ownership against flexibility for the organisation.
## The recommendation The React Native **getting-started page** opens with a clear recommendation: if you are building a new app, use a **React Native framework**. It names **Expo** as the framework and gives its command, `npx create-expo-app@latest`. This guidance dates from mid-2024, when the React Native team updated its onboarding; before that, the standard advice was to generate a project with the React Native CLI. A **framework** here means a toolbox with the APIs a production app needs, beyond React Native's own components. React Native core provides the runtime, the core components and the native build integration; a framework adds opinions and tooling on top. ## Why a framework The docs' argument is practical. Almost every app needs the same things: - **Navigation** between screens (Expo offers file-based routing). - **Access to native APIs** such as the camera, location or secure storage, through maintained modules. - **Native dependency management**: compatible versions of every library that ships native code. - **Native builds** for iOS and Android. - **Upgrades** of React Native and of the native project files between versions. Without a framework, a team either writes these solutions or pieces together libraries into what is effectively its own framework, then maintains that skeleton for the life of the app. The React Native team summarises it as: *you're either using a framework or you're building your own framework*. Building your own is legitimate, but most teams are better served by an existing one. ## What "bare" means A project created **without a framework** comes from the React Native Community CLI: ```bash npx @react-native-community/cli@latest init PetSitter ``` It produces a JavaScript app plus complete **`ios/` and `android/` native projects** that you own, edit and commit. You pick and wire your own navigation library, native modules, environment configuration and release process. The docs keep this path supported, alongside the Community Template and the Upgrade Helper, and list it for apps with **unusual constraints** a framework does not serve, or for teams that prefer to own those problems. ## A quick comparison | | Framework (Expo) | No framework (Community CLI) | |---|---|---| | Start command | `npx create-expo-app@latest` | `npx @react-native-community/cli@latest init <Name>` | | Native folders | can be generated from config | created once, owned by you | | Navigation, native modules | provided or curated | chosen and wired by you | | React Native version | follows the SDK (SDK 57 ships 0.86) | any release, including 0.87 on day one | | Upgrades | SDK upgrade tooling | Upgrade Helper diff and hand merges | Two details matter in interviews. First, a framework can lag the newest React Native minor: in September 2026 Expo SDK 57 runs React Native 0.86 while 0.87 is current. Second, choosing a framework does not forbid native code; you can still add custom native modules. ## Applying it: a startup's first app A small startup building its first pet-sitting app, with web-leaning React developers and no native specialists, is the textbook case for a framework: it gets navigation, device APIs, builds and upgrades without hiring for Xcode and Gradle expertise on day one. The bare route would spend its first weeks rebuilding what a framework already provides. ## What interviewers listen for - That you know the **current** recommendation and its source, rather than a 2022 tutorial. - That you can name the **problems** a framework solves, not just the brand. - That you treat bare as a **legitimate, supported** choice with specific triggers, not as "real React Native" versus a toy. - That you mention the **version lag** between a framework SDK and core releases when it matters. ## Common misconceptions - "Expo apps cannot use custom native code." They can. - "`react-native init` is the official way to start." It was removed in 0.77. - "Bare is unsupported now." It is supported; it is simply not the default recommendation.
- When is starting without a framework still justified?The docs name apps with unusual constraints a framework does not serve well, or teams that prefer to build those pieces themselves. Examples are embedding React Native in an existing native app, needing the newest React Native release before the framework supports it, or an organisation that already maintains its own native platform layer.
- Does choosing Expo stop you from writing native code?No. Expo projects can include custom native modules and native configuration; the framework changes how native projects are produced and maintained, not whether you may write native code.
Starting with a framework is like moving into a furnished flat: you can still repaint and swap the sofa, but you are not building the kitchen before you can cook. A bare project is an empty shell where you install every fitting yourself and maintain it afterwards.
saying these in an interview costs you the question
- The docs still recommend npx react-native init for new apps
- Expo apps can never contain custom native code
- Starting without a framework is no longer supported
- A framework always ships the newest React Native release on day one
- Frameworks only matter for web targets, not for mobile apps