Which React Native you actually get on Windows and macOS

The two sides, in one paragraph each

On the React Native side, Windows and macOS are out-of-tree platforms, each maintained by Microsoft in its own repository, and Linux has no maintained project at all. Our own framework comparison already states that much (5 best cross-platform frameworks for app dev in 2026), so treat it as the starting point rather than the finding. What follows is what the arrangement does to the version you can ship and the length of time it stays patched.

On the cross-platform .NET side, desktop is a target framework in the project you already have. One moniker, net10.0-desktop, covers Windows 7 and above, macOS 10.15 and above, and Linux under X11 or the framebuffer, and it moves when the rest of the application's .NET version moves (supported platforms). Uno Platform is the implementation used throughout this article.

Which version you can ship

React Native's own release policy supports the latest three minor series, and it is explicit about what falls outside them. As of this article's date that means 0.87.x and 0.86.x are Active, 0.85.x is at End of Cycle, and everything from 0.84.x down is Unsupported (React Native releases).

The desktop forks sit below that line. React Native for Windows is at 0.84 and React Native for macOS is at 0.81, where the merge-up to 0.83 is an open tracking issue rather than a shipped release (Road to 0.83).

Two different support statements are in play here, and conflating them would overstate the case. Microsoft's support for React Native for Windows 0.84 is Active. What is Unsupported is the upstream 0.84.x series that release corresponds to.

Every figure in that table has a shelf life, so here is how to rebuild it yourself:

npm view react-native version
npm view react-native-windows version
npm view react-native-macos version

Compare the second and third against the first, then check the first against the release policy page to see which series are still getting patches.

How long it stays patched

This is the number that binds a plan.

React Native for Windows publishes its phases: a stable version gets Active support until one month after the next stable version releases, then Maintenance support for two months, then it is Unsupported, and the same page states that a React Native for Windows version maps to the same React Native stable version (support policy). Roughly three months of patches per version, given as dates rather than estimates. On the day this article was drafted, 0.82 was in Maintenance with an end-of-support date of 31 August 2026, ten days out.

The .NET side publishes the same kind of policy at a different scale. Long Term Support releases are supported for a minimum of three years and Standard Term Support releases for two, with .NET 10 supported until 14 November 2028 (releases and support for .NET).

Both sides publish exactly what they will patch and for how long, in months on the React Native for Windows side and in years on the .NET side.

What the upgrade calendar looks like

React Native for Windows shipped 0.82 in March 2026, 0.83 in May, and 0.84 in June, which puts a new stable version roughly every two to three months (support policy). Combined with the support phases above, staying inside a supported version is a recurring commitment on the release train rather than a decision made once.

The macOS fork moves on its own schedule, and its current gap to upstream is the reason Expo gives for not offering first-class desktop support: a maintainer's reply in the long-running desktop request explains that the macOS fork trailing the current React Native version makes maintenance prohibitively expensive (Support for Windows and MacOS apps development). That is the React ecosystem describing the cadence problem in its own words, on its own repository, with 170 upvotes under it.

.NET releases once a year, in November, alternating Long Term Support and Standard Term Support (releases and support for .NET). An upgrade is an item you schedule, and on an LTS release the next one is three years out.

What adding a desktop platform means

On the React Native side, each desktop platform is its own repository with its own release stream, so Windows and macOS are two dependencies to track and two upgrade paths to keep in step, and Linux is not on the list.

On the .NET side, adding desktop means adding a target framework. The desktop head produces a single build output, and the shell is selected at runtime through a host builder that names the platforms the application supports, UseX11, UseLinuxFrameBuffer, UseMacOS, and UseWin32 (using the Skia desktop). The version of that desktop head is the .NET version of the application, which is the point: there is no separate desktop version to look up.

Where React wins

Microsoft's own Office organisation ships desktop with C++ and React Native, and not with .NET MAUI (devclass, May 2025). That is the strongest available evidence that the cadence described above is survivable at serious scale, by a team with every option available to it.

A mobile-first team feels none of this. iOS and Android get the newest React Native the day it ships, and the desktop cadence only binds a team that ships desktop from the same branch as mobile. If desktop is a separate product on a slower branch, the version gap is a fact about a dependency rather than a constraint on the roadmap.

And the .NET side asks a question React Native teams never have to answer, which is which .NET UI stack to build on. WinUI, WPF, .NET MAUI, and Uno Platform are all live answers with different reaches and different histories, the choice is made before the first screen exists, and getting it wrong costs more than a version lag does.

Choosing

For an application that has to ship on Windows, macOS, and Linux from one codebase, and that has to keep receiving security patches for longer than a year, I would build on cross-platform .NET. Two rows of the comparison above are the reason. The desktop version is the application's own .NET version rather than a separately maintained fork of it, and the support window is published in years rather than months.

Conditions where that recommendation does not hold, and they are not edge cases:

• The team is JavaScript and TypeScript end to end, and the desktop target is a secondary surface rather than the product. Retraining a team is usually a larger cost than tracking a dependency.
• The desktop build is a shell around an existing web application. What the reader is often choosing between on desktop is Electron or Tauri rather than React Native, and neither of those is what this article compared.
• Mobile is the product and desktop is a bonus. See the concession above.
• The existing desktop application is C++ Win32 and the job is embedding one new screen. That is the case Office demonstrates for React Native.