# React Native for Windows: Building Native Win32 and WinUI Apps with React

> React Native for Windows extends Meta's React Native to the Windows 10 SDK, targeting PCs, tablets, Xbox and mixed reality devices. This review covers what the Fabric renderer changes, how to install it, and where the toolchain will frustrate you.

**microsoft/react-native-windows** — A framework for building native Windows apps with React.

- Repository: https://github.com/microsoft/react-native-windows
- Website: https://microsoft.github.io/react-native-windows/
- Stars: 17,349 · Forks: 1,208
- Language: C++
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-react-native-windows

## What React Native for Windows actually solves

React Native gives you one JavaScript and React codebase for mobile. React Native for Windows extends that to the Windows 10 SDK, so the same component tree can render into a native Windows app instead of a web view. The README lists the device surface explicitly: PCs, tablets, 2-in-1s, Xbox, and mixed reality devices. That list is the point. If you are shipping a companion app for a mobile product and want it on the Microsoft Store without writing a second UI layer in C# or C++, this is the shortest path.

The audience is narrower than the topic count suggests. You need a team comfortable with React and with a Node and Yarn toolchain, and you need to accept a native build step. This is not a runtime you drop into a browser tab. The repository is a C++ project with a Yarn workspace layout, and the root package.json drives its build through lage, a task runner, rather than a single compiler invocation.

## Paper versus Fabric: two renderers, two architectures

The README draws a clear line between the two rendering systems, and it is the most important design fact in the project. The existing Paper renderer is built on UWP XAML and drops into native Composition as needed. The new Fabric renderer targets Composition from the start, with the ability to host islands of XAML for advanced native controls. Apps on the new architecture are WinAppSDK Win32 by default.

That is a real architectural fork, not a version bump. Paper inherits the UWP XAML control set, which is why the older path maps naturally onto UWP-style apps. Fabric inverts the relationship: Composition is the base, and XAML is something you opt into for specific controls. The practical consequence is that a Fabric app is a Win32 app built on Windows App SDK, which changes your packaging, your windowing model, and which Windows versions you can target. The README points to a pinned issue for the roadmap to Fabric, which tells you the migration is still being tracked publicly rather than finished.

If you are starting today, the choice is not cosmetic. Pick Paper and you inherit a renderer the project describes as existing; pick Fabric and you get the direction of travel but a narrower set of documented paths.

## Installing React Native for Windows and building a first app

The README does not inline the install commands. It points to the Getting Started Guide on microsoft.github.io/react-native-windows and to a separate System Requirements page for platform setup. The repository itself is a Yarn workspace, and its root package.json shows how the project is built internally, which is useful if you plan to build from source rather than consume a release.

On the repository side, the top-level scripts are the entry points. Building every workspace package goes through lage, and the postinstall hook runs the build automatically after a Yarn install.

```bash
yarn install
yarn build
```

The first command installs across the workspaces declared in package.json, which include packages/*, vnext, and the @react-native-windows and @rnw-scripts scopes. The second runs lage build. Expect a long first run: the workspace includes native C++ code, and the postinstall script means yarn install alone already triggers a build.

For an application rather than the framework itself, the Getting Started guide is the source of truth, and the README describes what it produces: using the CLI in that guide sets you up with a sample React Native for Windows app you can begin editing right away. The samples repository at github.com/microsoft/react-native-windows-samples holds standalone examples, and the React Native Gallery app is an interactive sample of available components, published on the Microsoft Store.

One repository script worth knowing about if you track upstream React Native: fork-sync:status reports the state of the fork against the dependency it mirrors.

```bash
yarn fork-sync:status
```

This runs the fork-sync script with the fmt dependency in status mode, which is how maintainers check drift between the vendored code and upstream.

## The Windows 10 SDK constraint and the macOS question

The README states the hard boundary plainly: you can run React Native Windows apps only on devices supported by the Windows 10 SDK. That is a runtime constraint, not a build constraint, and it rules out older Windows targets regardless of how modern your React code is.

There is a second boundary that trips people up. The website is titled React Native for Windows + macOS, and the README links to Windows and macOS documentation together. But this repository is described as adding support for the Windows 10 SDK. The macOS work lives under the same documentation umbrella, not in this repository's stated scope. If you read the site title and assume one codebase covers both desktops, you will be surprised when you go looking for the macOS implementation in this repo. The README does not document a shared macOS build path here.

The development environment is the other sharp edge. The System Requirements page exists as a separate document because the prerequisites are substantial: Windows SDK components, Visual Studio workloads, and the Node toolchain. The README does not summarize them, which is a reasonable editorial choice given how often they change, but it means you cannot judge setup cost from the README alone.

## React Native for Windows versus Tauri and Electron

The comparison people reach for is with web-shell desktop frameworks. The difference is in what renders the UI. Electron and Tauri both put a web engine in the window and your UI is HTML and CSS. React Native for Windows renders through native Windows UI: UWP XAML on Paper, Composition with optional XAML islands on Fabric. Your React components map to native controls rather than to DOM elements.

That distinction has consequences in both directions. Native rendering means the control set is whatever Windows provides, so you get platform behavior and accessibility semantics without reimplementing them, but you also cannot reach for the entire CSS ecosystem or a component library built for the browser. A web-shell app can render literally anything a browser can; a React Native Windows app can render what the Windows control surface and the project's component mappings expose.

Tauri differs from Electron in bundling size and in using the system webview, but it stays in the web-rendering model. Choosing between React Native for Windows and either of them is really choosing whether the Windows app should look and behave like a Windows app or like a web page in a frame. Neither answer is wrong; they are different products.

## Release cadence, licensing and upgrade cost

The release train is versioned in lockstep with React Native: 0.84.0 shipped on 2026-06-30, 0.83.0 on 2026-06-04, and 0.82.0 on 2026-03-17. The last push to the repository was on 2026-09-18, so development is ongoing rather than stalled. That cadence matters for planning: upgrading React Native in your app generally means moving the react-native-windows version to match, and the gaps between releases have run from roughly three weeks to about three months.

Version alignment is the upgrade cost. The repository maintains its own fork of parts of React Native, and the fork-sync tooling exists precisely because keeping that fork current is ongoing work. When you upgrade, you are not only picking up new components; you are tracking a project that tracks another project.

The license is the interesting wrinkle. The repository's package.json declares MIT, but the repository metadata reports the license as NOASSERTION, meaning GitHub could not classify it automatically. The LICENSE file is at the repository root. Treat the package.json declaration as the project's stated intent and read the LICENSE file yourself before you rely on it, particularly if you are redistributing a built app rather than consuming the source. Nothing here is legal advice.

## Where React Native for Windows is the wrong choice

If your Windows app is a thin wrapper around an existing web application, a web-shell framework will get you there faster and with fewer build prerequisites. The System Requirements page exists because the native toolchain is heavy, and that cost is only worth paying when you actually want native rendering.

If you need one codebase across Windows, macOS and Linux desktops, this repository does not provide it. The README scopes it to the Windows 10 SDK, and the documentation site's macOS coverage is a separate track. Teams that assume otherwise will discover the gap late.

If your app must run on Windows versions outside the Windows 10 SDK support matrix, you are out of scope entirely. And if you are on the Paper renderer with a large UWP XAML investment, the Fabric direction described in the README implies eventual migration work, with the roadmap tracked in a pinned issue rather than a published completion date. The README does not document a rollback path from Fabric back to Paper, so treat that choice as one-way until you confirm otherwise.

## Conclusion

Adopt React Native for Windows if your team already ships React Native on mobile and wants a shared JavaScript codebase on Windows 10 SDK devices, or if you are targeting Xbox and mixed reality where the UWP lineage still matters. Do not adopt it if your app is a small utility, a browser-based tool, or anything that needs to run on macOS and Linux from the same build, because the README scopes this repository to the Windows 10 SDK and points to a separate macOS track. Before committing, verify three things on your own machine: that your development platform passes the System Requirements documentation at microsoft.github.io/react-native-windows/docs/rnw-dependencies, that your target is WinAppSDK Win32 if you plan to use the Fabric renderer, and that the react-native-windows version you pin matches the React Native version your app already uses, since the release train is versioned in lockstep.

## FAQ

### Can React Native be used for Windows?

Yes. React Native for Windows adds support for the Windows 10 SDK to React Native, so you build native Windows apps with React and JavaScript. The README states this covers PCs, tablets, 2-in-1s, Xbox and mixed reality devices.

### What is React Native for Windows?

It is a Microsoft repository that extends Meta's React Native framework to the Windows 10 SDK, letting you build native Windows apps from a React and JavaScript codebase. The README describes two renderers: the UWP XAML based Paper renderer and the newer Fabric renderer, which targets Composition and produces WinAppSDK Win32 apps by default.

### How do I install React Native for Windows?

The README does not inline install steps. It directs you to the Getting Started Guide and the System Requirements page on microsoft.github.io/react-native-windows, and states that using the CLI in that guide sets up a sample React Native for Windows app you can edit immediately.

### How does React Native for Windows compare to Tauri?

Tauri renders your UI in a web engine, while React Native for Windows renders through native Windows UI: UWP XAML on Paper, or Composition with optional XAML islands on Fabric. The trade is native control behavior and accessibility semantics against full access to the web component and CSS ecosystem.

## Sources

- [Issues](https://github.com/microsoft/react-native-windows/issues)
- [microsoft/react-native-windows on GitHub](https://github.com/microsoft/react-native-windows)
- [Project website](https://microsoft.github.io/react-native-windows/)
- [README](https://github.com/microsoft/react-native-windows/blob/main/README.md)
- [Releases](https://github.com/microsoft/react-native-windows/releases)

---

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