# React Native: What the Core Repository Actually Ships, and How to Start With It

> React Native renders React components to native platform UI on Android, iOS and out-of-tree platforms. This review covers the mechanism, the install path the README recommends, the upgrade cost, and where a framework or a different tool fits better.

**react/react-native** — A framework for building native applications using React

- Repository: https://github.com/react/react-native
- Website: https://reactnative.dev
- Stars: 126,724 · Forks: 25,286
- Language: C++
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/react-react-native

## The problem React Native solves, and who it is for

Cross-platform mobile development usually forces a choice. Share the UI layer and you get a web view that never quite matches platform behaviour. Write twice and you pay for two teams, two release trains and two sets of gesture and accessibility bugs.

React Native takes a third path. The README states that its primitives render to native platform UI, so an app uses the same native platform APIs other apps do, and that gestures, text scaling and accessibility behave the way users expect on each OS. The pitch line is "Learn once, write anywhere": create native apps for Android, iOS and more using React.

The audience is therefore specific. It is a team that already knows React and wants its component model, hooks and Suspense on mobile without learning Swift and Kotlin first. It is also a team that needs to reach platform code eventually, which is why the README points at Native Modules for calling platform code from JavaScript and at reactnative.directory for existing libraries. If you have no React experience and no plan to gain it, the framework's main advantage evaporates.

## How the JavaScript reaches native widgets

The README's one-line description is the clearest statement of the architecture: "Written in JavaScript, rendered with native code." Your components are JavaScript, and the rendering target is the platform's own view system rather than a browser engine.

That split explains the developer experience claim. Because the JavaScript layer is separate from the compiled native app, changes to JavaScript code are applied with Fast Refresh without rebuilding the native app. You rebuild the native binary when native dependencies change, not when you edit a component. The repository layout reflects the same division: the top level carries build.gradle.kts, gradle/, gradlew and Gemfile for the native and iOS toolchains, while packages/ holds the JavaScript packages and the rn-tester app that the monorepo scripts drive.

The primary language listed for the repository is C++, which is consistent with a project whose heavy lifting happens below the JavaScript boundary. The README also links a separate Architecture overview page, so the deeper rendering pipeline is documented there rather than in the repository front page. Treat that page as required reading before you make claims about how the runtime behaves under load; the README does not describe it.

## Installing React Native: the framework path the README recommends

The README is explicit that the best way to experience React Native is through a framework, described as a toolbox with all the necessary APIs to build production ready apps. Expo is named as a production-grade React Native Framework with file-based routing and a standard library of native modules. The documented command for a new Expo project is a single line:

```bash
npx create-expo-app@latest
```

Run it in a terminal and it scaffolds a project. The README then directs you to Expo's getting started guide to continue, so the next steps (starting the development server, opening the app on a device or simulator) live in Expo's documentation, not in this repository. Nothing in the React Native README documents the flags or templates that command accepts, so do not assume any.

The README's stated reason for this default is worth quoting in substance: navigation, native dependencies and platform tooling are problems the ecosystem has already solved, and most developers benefit from a framework. That is a recommendation from the maintainers, not a technical requirement.

## Going without a framework, and what the monorepo scripts are for

The README keeps a second door open. If a framework does not suit your app, it points to a Getting Started Without a Framework page and, separately, to Integration with Existing Apps for adopting React Native incrementally into an app you already ship. That second link matters for brownfield work: you can add React Native screens to an existing native codebase rather than rewriting it.

What you should not do is confuse the repository's own scripts with application tooling. The root package.json is marked private with the name @react-native/monorepo and version 1000.0.0, and its scripts exist to build and test React Native itself. The android script runs yarn --cwd packages/rn-tester android, build-android runs the Gradle task :packages:react-native:ReactAndroid:build, and test-android runs the corresponding test task. These are contributor commands. Cloning this repository to "install React Native" is the wrong move; the package you consume is published to npm, and the README links to its npm page.

One practical detail from the repository files: the package manager is pinned as yarn@1.22.22 and there is a preinstall script that runs node ./scripts/try-set-hermes-compiler-prebuilt.js. That preinstall step is part of building the core, not of using it.

## Where React Native is the wrong tool

The README is honest about one boundary and silent about several others. It says most developers benefit from a framework, which is an admission that the bare path carries setup cost the framework absorbs. If your team cannot take on navigation, native dependency management and platform tooling, the without-a-framework route will cost more than it saves.

The release cadence is the second constraint. The recent releases list shows 0.87.0 on 2026-08-11, 0.86.3 on 2026-08-24 and 0.87.1 on 2026-08-26. Two patch lines moving within the same month means a project pinned to an older minor will accumulate upgrade work. The README links an Upgrading page and there is a separate reactwg/react-native-releases discussion repository, but the README does not document rollback, so if you need a supported downgrade path, that is a question for those discussions rather than something you can read off the front page.

Finally, the framework is for native apps on Android, iOS and out-of-tree platforms. If your target is a desktop-only or web-only product, the native rendering model buys you nothing, and a plain React application is the smaller commitment.

## Flutter, and the actual difference in approach

The most common comparison people search for is React Native against Flutter, and the distinction is not cosmetic. React Native renders to native platform UI, as the README states, so a button is the platform's button and inherits its gestures, text scaling and accessibility behaviour. Flutter draws its own widgets through its own rendering layer, so appearance is consistent across platforms by construction rather than by mapping to each platform's controls.

That changes what you debug. With React Native, a platform-specific rendering quirk is often a question about the host platform. With Flutter, it is a question about the framework's own widget layer. It also changes your language bet: React Native is JavaScript with React, so an existing React web team transfers its mental model; Flutter is Dart, which is a new language for most teams.

Neither is universally better. The deciding factor is whether you want platform-native controls and an existing React skill base, or a single rendering model you fully control. React Native's README does not argue this case at all, which is why the comparison is worth making yourself before you commit.

## Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-08-26, the same day as the 0.87.1 release. The README states that React Native is developed and supported by many companies and individual core contributors and points to the React Foundation website for more. Release discussion happens in reactwg/react-native-releases, and larger proposals in react-native-community/discussions-and-proposals, so the project's decision-making is public even where the README is thin.

Upgrade cost is the number to budget for. The repository carries CHANGELOG.md plus CHANGELOG-0.5x.md, CHANGELOG-0.6x.md and CHANGELOG-0.7x.md, which tells you the project has kept per-line changelogs for years. The README links an Upgrading page. What it does not provide is a compatibility matrix for third-party native modules, and that is usually where an upgrade actually breaks.

The licence is MIT, as stated in the README and present as a LICENSE file at the repository root. MIT is permissive: it allows commercial and closed-source use, and it comes with no warranty. That is a statement about the licence text, not legal advice; if your organisation has policies about attribution or patent grants, have counsel read the file rather than relying on a summary.

## Conclusion

Adopt React Native when your team already writes React and you need one codebase for Android and iOS with genuine native widgets, and start through Expo unless you have a concrete reason to manage native projects yourself. Do not adopt it if you need a single binary for desktop and web only, or if you cannot absorb a release cadence that shipped 0.87.0 on 2026-08-11 and 0.87.1 on 2026-08-26. Before committing, verify two things yourself: run npx create-expo-app@latest on a clean machine and confirm the toolchain resolves, and read the Upgrading page and the react-native-releases discussions to see what a version bump will demand from your native dependencies.

## FAQ

### What is React Native vs ReactJS?

React is the library you use to describe UI in JavaScript; React Native uses that same model but renders to native platform UI on Android and iOS instead of to the browser DOM. The README states that React Native lets you build native apps using React, written in JavaScript and rendered with native code.

### Is React Native a coding language?

No. It is a framework for building native applications using React, and the README describes the code you write as JavaScript. The repository's primary language listing of C++ refers to the core implementation, not to what app developers write.

### How to install React Native?

The README recommends going through a framework and gives npx create-expo-app@latest as the command for a new Expo project, then directs you to Expo's getting started guide. It also links a Getting Started Without a Framework page for teams that do not want a framework.

### Is React Native frontend or backend?

It is a client-side framework: its primitives render to native platform UI on Android and iOS, and the README describes it as a way to build native apps rather than a server runtime. Native Modules let that client code call platform code directly.

### Is React Native easy to learn?

The README's selling point is that you learn React once and reuse components, hooks and Suspense across Android, iOS and other platforms. It does not make a claim about learning difficulty, and it recommends a framework partly because navigation, native dependencies and platform tooling are problems the ecosystem has already solved.

## Sources

- [Official documentation](https://reactnative.dev)
- [Official README](https://github.com/react/react-native#readme)
- [Project repository](https://github.com/react/react-native)
- [Release notes](https://github.com/react/react-native/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/react-react-native