The request arrives from someone who does not know it is a hard question. A customer wants the app on Windows, or a sales conversation needs a macOS build, and the team has shipped iOS and Android from Expo for two years without leaving the managed workflow once. So the honest answer starts with a distinction: React Native runs on Windows and macOS, and Expo is a different question, because Expo is the workflow rather than the renderer.
Expo's own documentation draws the line. Support for platforms beyond Android and iOS goes through out-of-tree platforms, and the Expo Modules API currently supports macOS and tvOS. Windows is not named (additional platform support).
There is a version dimension to this too, and it belongs to which React Native you actually get on Windows and macOS rather than here. One sentence is its whole appearance: the macOS fork trailing upstream is the reason Expo's maintainers give for not funding first-class desktop support.
What your workflow is made of
The question worth answering is not whether pixels can reach a desktop window. It is which parts of the workflow the team actually depends on survive the trip. Here is that inventory, with what stands opposite each part on a cross-platform .NET desktop target.
| What you use today | What it does | On a net10.0-desktop target |
|---|---|---|
| EAS Build | Hosted service that builds app binaries, with iOS builds on macOS runners in Expo's infrastructure | No counterpart. You build on the machine, and a macOS .app bundle can only be produced on macOS (publishing for macOS) |
| EAS Update | Cloud service that updates the non-native pieces, JavaScript, styling and images, over the air | No counterpart for a bundle swap. An update ships as a new signed package through the platform's installer channels (publishing your app) |
| Snack | An in-browser development environment, with no tools installed on the phone or computer | No counterpart. The nearest thing clones a sample and builds it locally (Studio gallery) |
| Config plugins | Modify the native projects generated during prebuild, from configuration rather than by editing native files | UnoFeatures and MSBuild properties in the project file declare platform capability the same way (using the Uno.Sdk) |
| Expo Modules API | Native modules in Swift and Kotlin, with macOS and tvOS as the out-of-tree platforms | Platform-specific C# under conditional compilation, and native elements embedded in the Skia visual tree (platform-specific code) |
| Expo Router | File-based routing where every screen is automatically deep linkable | A registered RouteMap with regions, and deep linking on WebAssembly (navigation regions) |
Three rows say no counterpart, and they are not rows to skim past. They are the rows a team notices in week one.
Two rows deserve their exact wording. EAS Build is a hosted service for Android and iOS, so even inside Expo it is not a desktop build service. And the .NET side does have an update path, which is a new signed package rather than a bundle delivered over the air, so the row says no counterpart for a bundle swap rather than no way to update.
What the .NET side asks instead
Adding desktop on this side is adding a target framework to the project that exists. The desktop head is net10.0-desktop, one moniker covering Windows, macOS and Linux, and the project keeps its mobile and WebAssembly targets alongside it (supported platforms). Uno Platform is the implementation used throughout.
What leaving the managed workflow costs on the React Native side
Expo does not officially support React Native for Windows, and the tracking issue for what is missing has been open since August 2024 with 27 reactions, opened by someone documenting their own workarounds (Expo support).
Userland work exists. A community project provides support for using Expo with out-of-tree platforms, at 285 stars and actively pushed to (expo-desktop). Depending on it is a different proposition from depending on Expo: one maintainer's project, outside the support policy of either the framework or the platform fork.
Where React wins
Nothing on the .NET desktop side matches the managed workflow, and the gap is not close.
EAS Build gives a team binaries for platforms whose hardware they do not own, with iOS builds running on macOS runners in Expo's infrastructure. On the .NET side, producing a macOS .app bundle requires macOS, which means a Mac in the room or a Mac in a build pipeline, and that is a procurement problem rather than a configuration problem.
EAS Update ships a fix to users' devices without a store submission, because JavaScript, styling, and images are not native code and do not need re-signing. There is no equivalent on a desktop .NET target. A fix goes out as a new signed package.
Snack is an in-browser development environment that needs nothing installed on the phone or the computer, which makes it usable by a designer or a support engineer who will never run a build. Nothing on our side does that.
Choosing
For a team whose product is mobile and whose desktop request is one customer, I would not move the application. Keep the Expo workflow you have, and treat desktop as a separate question rather than a target to bolt on. Two paths worth pricing first: Mac Catalyst, which Expo's own maintainers point at as the cheaper route to macOS, and shipping the web build, since the request is sometimes satisfied by an application that opens in a browser.
For a team whose product has to exist on Windows, macOS and Linux as installed applications, with one codebase and a support horizon measured in years, I would build on cross-platform .NET, and pay the three costs in the concession above deliberately.
Conditions that change the answer:
- The team has no .NET experience and no appetite for XAML and C#. The mapping table is not the cost that matters in that case; the language and framework are.
- Over-the-air updates are load-bearing in how the product ships fixes. Nothing here replaces them.
- Snack-style sharing is part of how the team works with designers or support.
- The desktop build is a shell around a web application, in which case the comparison you want is Electron or Tauri and not this one.
Subscribe to Our Blog 
Subscribe via RSS
Back to Top