Why your React Native Windows build breaks when you changed nothing

The two sides, in one paragraph each

A React Native for Windows app is a JavaScript project and a native Windows project at the same time. The JavaScript half resolves through npm, the native half resolves through NuGet and MSBuild, and the build needs Visual Studio 2022 with specific workloads, a specific Windows SDK, Node, and a .NET SDK installed on the machine (system requirements).

A cross-platform .NET desktop app resolves through one package manager and builds with one SDK. The desktop head is a target framework in the project file, net10.0-desktop, the Uno.Sdk supplies the platform packages for it, and the output is produced by dotnet publish (using the Skia desktop). Uno Platform is the implementation used throughout.

What the build actually resolves

Here is the inventory, as each side documents it. Every row is something that has a version, and every version is something that can change without you.

One row deserves reading twice. The dependency list for React Native for Windows 0.84, released in June 2026, names the .NET 6.0 SDK, and .NET 6.0 reached end of servicing on 12 November 2024 (ending support in 2024). It is a build-time dependency rather than something shipped inside the app, and it is still a version of a .NET SDK that no longer receives fixes, required on every machine that builds the app.

What happens when something upstream ships

Three failures from the last eight months, each a different seam.

The first is a release-artifact mismatch between the two package ecosystems. React Native for Windows 0.81.3 was published to npm, the matching NuGet package was not, and builds failed until it appeared (NuGet packages are missing for 0.81.3). The npm half of the build moved and the NuGet half had not caught up.

The second is a transitive platform SDK break. A Windows App SDK 1.7.x patch generated an invalid library path, and the build failed at the linker with LNK1104 (WindowsAppSDK 1.7.x breaks React Native Windows build). The app did not reference that path, and the app did not choose that version.

The third is architecture-specific toolchain configuration. Release builds on ARM Windows failed over which Hermes binary the build selected, with the reporter overriding MSBuild properties to get past it (release builds fail on ARM Windows).

Read those as three mechanisms rather than as a reliability score. Three linked incidents are not a rate, and this article does not have one.

On the .NET side the equivalent surface is smaller because there are fewer independent publishers in it: package versions come from NuGet under one SDK, and the project file can pin them explicitly where a specific version matters, the way CommunityToolkitMvvmVersion pins the MVVM toolkit (using the Uno.Sdk). Fewer publishers is not the same as none, and a NuGet package can regress like any other.

Producing something you can ship

On the React Native for Windows side, a release build is npx react-native run-windows --release, which builds and installs locally. Producing a distributable package is a separate Visual Studio flow: configure the manifest, associate the project with a Store listing, set Release, and use Create App Packages, which produces a signed .appxupload that has to pass the Windows App Certification Kit before submission (publishing to the Microsoft Store).

On the .NET side, packaging is part of the standard publish workflow, and the same dotnet publish invocation that builds the app produces the platform package for the target you name (publishing your app). The command is in the row above; there is no second tool to open.

Where React wins

The JavaScript half of that toolchain is the one the team already runs. Metro, fast refresh, npm scripts, and the module graph are the same ones the web application uses, so a desktop build inherits tooling the team has already debugged and people who already know it. Both sides have an inner loop worth having, and Uno Platform documents full XAML and C# Hot Reload on Skia desktop targets (Hot Reload). What the React Native side does not ask for is a second toolchain to learn on the way to it.

Our own side has a coupling to admit, and it lands exactly where a reader with an existing codebase will hit it. The Uno Platform documentation states that as of version 6.0 the solution templates do not support being added to an existing solution, and gives a manual workaround (adding a project to an existing solution). If the desktop app has to live in a solution that already exists, that is a manual step on our side and not on theirs.

Choosing

For a team that owns its own CI and needs a desktop build that fails only when someone changes the application, I would build on cross-platform .NET. The reason is in the inventory table: one package manager, one SDK, no pinned IDE, and one command that produces the shippable artifact.

Conditions where that does not hold:

• The web application and the desktop application share a JavaScript codebase, and the duplication cost of a second stack outweighs the build surface described here.
• The team's iteration loop depends on fast refresh. See the concession above.
• Windows is the only desktop target and the app is already in the Microsoft Store, where the Visual Studio packaging flow is a path the team has walked before.
• Somebody else owns the build. If a platform team absorbs these upgrades, this article describes their problem rather than yours.