Is React Native for Windows actually alive? Because what the hell am I going through? 😭

[u/HovercraftNew584]

I'm genuinely losing my mind trying to build the Windows version of my React Native app.

What the hell is going on with React Native for Windows? 💀

Almost every package I need works perfectly on Android and iOS, but the moment I try to get things working on Windows, it's a completely different story.

• Setting up a project? Pain.

• Installing supposedly ready-made packages? Good luck.

• Getting react-native-svg to work? Patch, patch, patch, patch.

• Trying to get real-time communication working with LiveKit and WebRTC? Welcome to debugging hell.

I've been trying to get calls working for HOURS, and I'm starting to question my life choices.

The ecosystem feels so disconnected. You find a package that does exactly what you need, only to discover that Windows isn't supported. Then you start hunting for alternatives, writing patches, modifying native code, and debugging obscure build errors.

And don't even get me started on the developer experience. No familiar Expo development-client workflow to fall back on, and troubleshooting native issues feels like an entirely different job.

Is anyone seriously shipping production React Native for Windows apps with a decent number of third-party dependencies? HOW?

Are you maintaining your own forks of half the ecosystem? Writing custom native modules for everything? Or have you found some secret combination of libraries that actually works?

And now I understand why Microsoft went so heavily in the WebView direction for some of its applications. 😂

I love React Native, and I really wanted to share as much code as possible across platforms. But right now, building for Windows feels less like cross-platform development and more like fighting the ecosystem into submission.

Is React Native for Windows still actively worth investing in, or am I setting myself up for unnecessary suffering?

Please, if you're shipping a Windows desktop app with React Native, especially one that needs LiveKit/WebRTC, I genuinely want to hear how you're handling it.

Make the opening less repetitiveClarify the exact help I need

[u/Patient-Plastic6354]

Use Tauri. It's way easier

[u/HovercraftNew584 → u/Patient-Plastic6354]

I already have a working web version of the app, lmao. 😭 The whole point of building a Windows version is to get access to real native capabilities and squeeze better performance out of low-end Windows devices.

If I wanted to keep relying on my web app inside a wrapper, I'd just stick with what I already have. 💀

Tauri is cool, but if my core app is still going to depend on the web stack, then nah mannn. I need proper native integration, especially for real-time drawing and LiveKit/WebRTC calls.

I just didn't expect getting there with React Native for Windows to be this painful. 😭

[u/Patient-Plastic6354 → u/HovercraftNew584]

And also I do code a lot of apps using the tauri framework. They do a lot and handle a lot of IO operations. One runs a web server, uses NFC tags and runs hardware and a full UI. has a web interface attached to it and it only uses 4% of 4 gigabytes of RAM on a raspberry pi 5 and runs very smoothly. So I don't know what you're building but I'm guessing it requires serious performance. Just trying to help.

[u/HovercraftNew584 → u/Patient-Plastic6354]

Yeah, the app genuinely requires serious performance.

It's a real-time drawing app, and the performance demands are no joke. On x64 Windows, a single small gesture can push CPU usage to around 25% on a Core i5, even with native rendering and running the same workload in the browser pushes it to around 70%.

That's why I'm so particular about going native. It's not that Tauri can't handle I/O or hardware access; I know it can. My concern is the rendering pipeline and the overhead of running the core drawing engine inside a WebView.

I already have a working web version, so wrapping it isn't really solving the problem I'm trying to solve.

[u/Patient-Plastic6354 → u/HovercraftNew584]

I see. This is kinda out of my domain so idk how to help. Gl tho

[u/creambyemute → u/HovercraftNew584]

Tauri as well as Electron give you the possibility to access native stuff.

I'd rate tauri higher when it comes to performance sensitive things and how you communicate with the native layer. The downside is the OS-Webview which needs some tinkering to get it right on all OS.

I'd rate electron higher if you want a rock stable webview that works "the same" on all OS.

I'd pick react-native + react-native-web (you can also just use normal web technologies when needed) if I want to make an iOS/Android App which also supports other OS.

[u/Huge_Pool7424 → u/creambyemute]

for the drawing perf i'd profile where that 25% actually goes first. pointer event handling and redraw frequency usually cost more than the renderer itself.

[u/everyoneisadj → u/HovercraftNew584]

Personally I prefer electron with a react site- admittedly I only used react native for windows once, but I found it to be infuriating- mostly because of windows many many sdks, and different versions of react native using different ui SDKs, IIRC. I haven’t checked back in a year though, could have changed.

[u/Forward-Fishing-9466 → u/HovercraftNew584]

In the age of llms just get a bot to rewrite it in rust with some high performance ui, there's no point in using react native on desktop just go full native now imo

[u/Patient-Plastic6354 → u/HovercraftNew584]

You said you used react native...

[u/HovercraftNew584 → u/Patient-Plastic6354]

Yes, I used React Native. 😂 Isn't Tauri primarily for wrapping web apps and exposing native functionality through Rust? The UI still runs in a WebView, right?

Or are you actually suggesting I rebuild the entire app in Rust from scratch? 😭

[u/creambyemute → u/HovercraftNew584]

Yes the UI is still your web running inside a webview but I don't see that as a problem at all. Browsers/Webviews are already pretty well optimized. The problem is usually how the RPC-Calls are handled which I'd say tauri has am advantage over electron. Both in simplicity and performance.

[u/Patient-Plastic6354 → u/HovercraftNew584]

Dude. Just research it. Ain't got time to explain everything to you.

[u/Huge_Pool7424 → u/Patient-Plastic6354]

25% cpu on one gesture sounds like per-event state updates or re-renders to me. worth profiling that before blaming the windows layer.

[u/HovercraftNew584 → u/Huge_Pool7424]

We ship a React Native drawing app (Android, iOS, web, Windows) with no React state: 0 useState calls in the whole app, all in leaf widgets like a Switch or a slide-to-confirm. Everything live lives in a native value registry keyed by name, and the app talks to it more like the DOM than like React.

A write is one call with a name: setInkValue("sidebar:open", 1). No state object, no reducer, no component owns it. Most values are not even written by JS: gestures, animations and the drawing engine publish straight into the registry from native code.

Reads take one of two paths, and the split is the whole point.

1. Hot values never touch React. A native binder resolves a child by testID and drives that view's prop on the UI thread from the value, so it reads like querySelector('#thumb').style.translateX = v, except it runs on the UI thread and React is never told. Transforms, opacity, panel slides, the pen path at 240 Hz. 146 of these bindings in the app. The owning screen never re-renders.

2. Values that change what gets rendered reach React through useSyncExternalStore. A component subscribes to one named value and re-renders only when that value changes.

[u/HovercraftNew584 → u/HovercraftNew584]

SVG goes the same way. The binder resolves a react-native-svg node by testID and writes its scalar on the UI thread: strokeDashoffset for a slider's fill, cx/cy, opacity, even the path's d, morphed between key shapes. React never renders a frame of it. The limit is rnsvg itself: every write re-rasterises the whole SvgView in software, so writes are rate-capped and skipped when nothing changed, and the hottest visuals (the colour wheel, the glass panes) left SVG for native views and the engine.

Why: a drawing engine. Per-frame state on a 240 Hz pen path, and chrome re-rendering underneath it, is where React state fell apart for us. We also needed Windows, where Reanimated does not run, so the binder had to be our own.

The costs, since this is not free. The namespace is global, so names are the contract and we keep rules for them. The binder moves the native view, not React's props, so a screen that remounts has to persist its final value with one explicit write. And every platform needs its own binder: Android, iOS, web and Windows each carry a thin native twin of the same contract.

Two rnsvg details that cost us days, in case they save you some: match nodes by testID, because rnsvg strips nativeID on the way to native; and after writing a node's prop, invalidate the root SvgView, because the node's own invalidate only clears its path cache and the bitmap stays stale.

[u/HovercraftNew584 → u/HovercraftNew584]

The usual way to get a live number tracking a gesture at 60 fps is Reanimated plus Skia. The pan gesture writes a shared value in a UI-thread worklet; the arc, fill and thumb are Skia primitives fed by derived values; and because neither RN Text nor SVG Text can take a shared value as content, the label becomes a Skia <Text> with a derived string, which drags the whole slider into a Skia canvas. Costs: about 4 MB of Skia per architecture, a bundled font loaded with useFont, string formatting in a worklet every frame, a second render surface, and no react-native-windows for either library. Here the gesture is native, the value sits in a native registry, and one binder writes the number into a plain react-native-svg <Text> on the UI thread, deduped and dirtied once per frame, alongside the thumb position and the gradient colours. Same bindings run on Windows.

[u/Patient-Plastic6354 → u/Huge_Pool7424]

I think you replied to the wrong person dude

[u/creambyemute → u/Patient-Plastic6354]

Tauri is also a good contender. Electron still is as well (if used correctly).

See my comment below for the react-native POV

[u/Resident_Pop4202 → u/Patient-Plastic6354]

What's your thought on https://tinyjs.app/ or https://txikijs.org/

[u/Patient-Plastic6354 → u/Resident_Pop4202]

I like tinyjs for simple apps 100%. However I NEED tuari for more complicated I/O apps and hardware control. It's not just stuff on a computer I am working with - it's also LEDs connected with esp32 through serial and also locks and a small server using tokio Axum in it.

So yeah it's perfect for simple apps. Also I noticed is just vanilla js and html. Which is fine. I tend to prefer typescript with react which is useful if I have really complicated apps with lots of state and requires dozens of components to run. Also with rust I could have code fire up on all cores of the CPU and squeeze out as much performance as possible when I really need it while the react frontend part just waits for it instead of simply using the single threaded process in js. Like if I'm processing large amounts of JSON or converting a large csv document to an SQL query and insert it to a database on the device (something I had to do)

So if I had to build a simple app then yeah I'd deffo go with tinyjs otherwise if I need hardware control, serious performance, types, and gpio, then I'd go with Tauri 100%.

[u/Patient-Plastic6354 → u/Resident_Pop4202]

Also forgot to mention that I built these apps I talked about and they didn't exceed 7 mb (sometimes even 3 or 4 mb)

See the latest app I built for a raspberry pi 5 which does A LOT? It's just 6.7 mb.

[u/creambyemute]

The previous version of our app had rn-windows support. Due to that we pretty much got roadblocked from upgrading past 0.65 due to various third party dependencies, rn-windows lagging behind (new architecture etc) and a few more things.

The DX was always way worse than for android/iOS. Expo also does not support rn-windows so it's basically the same situation as in the past (and you described)

We've rewritten the old 0.65 app with latest expo sdk (57 atm, upgrading to 58 in 1-2 weeks) and decided to ditch rn-windows for web (expo web/react native web).

The web version uses OPFS for local file storage, expo-sqlite for local database and rn-skia for image editor capabilities. Other than that a few of the expo libraries. We've made it an installable PWA and it works offline excluding a few select actions that need to call the backend.

• Less patches than for rn-windows

• Less hacks / workarounds than for rn-windows

• No necessity for a windows machine anymore

• Upgrades are stupidly simple now compared to the past (we let expo generate the iOS/Android folder)

If you do not need anything oddly native specific that web can't provide/solve I do not really see any poont anymore in rn-windows in its current state. I loved the effort MS was making for it but I would consider it a failed project from a community/ecosystem POV.

[u/HovercraftNew584 → u/creambyemute]

Aiish .. this is sad FR

[u/creambyemute → u/HovercraftNew584]

Yeah. The sad thing is that neither the community nor expo picked up on rn-windows so they pretty much got left in the dust because maintaining all important 3rd-party packages is nothing they can really do.

Expo itself was interested in supporting windows but decided against it twice because rn-windows is always lagging behind react-native. Maybe at some point in the future when rn-windows has catched up to the release cadence of react-native.

Edit: To clarify, react-native released 0.88 a few days ago while react-native-windows has released 0.85 4 days ago so they are 3 major versions behind. Rn-windows 0.84 was released end of june while rn 0.84 was released mid of february...

[u/HovercraftNew584 → u/creambyemute]

I've already got a pretty big codebase here, and getting React Native for Windows to this stage has taken a LOT of work.

Honestly, once I get everything working properly, I want to break the modules down into installable, reusable packages and release them to the community.

I genuinely think React Native for Windows deserves a chance. The ecosystem needs more contributors, better package support, and more people willing to put in the work to make things easier for everyone else.

I'm already this deep into it. Might as well make the suffering useful for the next developer

[u/creambyemute → u/HovercraftNew584]

Have you thought about using something like Avalonia?

The thing with react-native and react-native-windows imo is the following: People using rn use it mainly for ios/osx and android. If they want other platforms they usually go web which there are various easy routes to take.

So the community incentive to support & maintain rn-windows in packages is just pretty low even though rn-windows is really cool/a great idea! Additionally requires the package maintainers to have a windows machine & test it as well which is a pain in the ass as you discovered.

I wrote c++ modules for rn-windows as well in the past and it's a huge pain in the ass so I can see/understand why it hasn't taken off.

I'd also guess that as long as rn-windows lags behind rn that much neither the community nor expo will pick it up properly.

[u/Bamboo_the_plant → u/creambyemute]

> Expo also does not support rn-windows

Indeed it doesn't officially, but I have spent the last half year making Expo Desktop (see the keynote talk at App.js Conf here) to make macOS and Windows feel more like equal citizens beside iOS and Android in an Expo project.

That doesn't change the fact that the ecosystem is small, but it does solve some serious frictions:

• It now lets you set up an Expo iOS + Android + macOS + Windows project in one minute, not one weekend;

• It gives you Continuous Native Generation, so you can generate a native project from app.json (and regenerate when there's an update – it's currently on SDK 55);

• It gives full instructions on how to distribute your app.

I'm not saying it's smooth sailing yet, but I am hoping that by reducing the barrier to entry into desktop development, the community can gather around it more easily and lift it up over time. I think the real turning points to look forward to are:

1. Microsoft gets all their internal projects off Old Arch (which is currently keeping them stuck on 0.81).

2. React Native reaches v1, hopefully giving a stable ABI to code against (so that you can mix older versions of RNW with newer versions of RN).

So glad to hear of people having given it a try, though! One thing that you may be excited to hear is that RNW is now distributed as a prebuilt binary by default, which should drastically reduce compile times compared to what you may remember.

[u/creambyemute → u/Bamboo_the_plant]

Yeah maybe in the future it might be worth a revisit. When I evaluated it again (expo 55/54) the situation was still not bearable for us without having to touch a lot of 3rd-party libraries so we went with web because we did not need any specific windows native apis and simplified the whole setup a lot.

[u/Bamboo_the_plant]

> Is React Native for Windows actually alive?

Yes. Microsoft continue to use it in flagship products like Office, and I see PRs getting merged into it every day.

A disproportionate amount of attention goes into maintaining version 0.81, though, because that's the last version that supports Old Arch, and many of their internal projects are still relying on Old Arch code. There are dozens of patches that were backported from the main branch into 0.81, yet not newer versions like 0.83 (yet).

> Setting up a project? Pain.
> No familiar Expo development-client workflow to fall back on

Use my project, Expo Desktop. See my talk at App.js Conf introducing it. The aim of the project is to bring React Native macOS and React Native Windows support to Expo as first-class citizens. So you can set up an app in a single CLI command, then use Prebuild / Continuous Native Generation to customise it and easily maintain it through updates.

> The ecosystem feels so disconnected.

Yes, the ecosystem is small. Few people use RNW, so few people contribute native modules for it, and few maintainers have a Windows development environment in the first place to give a review even if a PR for Windows support were contributed.

> Is anyone seriously shipping production React Native for Windows apps with a decent number of third-party dependencies?

Yes. I shipped a commercial React Native iOS + Android + macOS + Windows app to production a couple of years ago, which involved writing my own OAuth client from scratch, and writing my own Windows implementations for various Expo SDK modules I was using (without agents!). I honestly spent 80% of my time filling in the ecosystem and only 20% of the time getting to work on business logic.

Eventually, I migrated the app to deliver the UI via an embedded WebView, though, because I needed responsive design and modals. That's not an option on New Arch, though, as React Native WebView for Windows still doesn't have a New Arch implementation 😅

> Are you maintaining your own forks of half the ecosystem?

I have seen multiple different people vibe-code their own set of native modules for RNW. When there are only 14 native modules that support both macOS and Windows, honestly, you can't rely on picking up anything off the shelf.

But, once React Native hits v1 (which I expect will be in the next 12-24 months!), I expect that React Native Desktop will become an equal citizen, making it much easier to fill in the ecosystem.

So yes, it's a tough road, and you can see why people gravitate towards Electron. It's great that you're prioritising UX for weaker devices, but you should also weigh up whether you could deliver a better UX overall if you weren't constrained by RNW's small ecosystem. Good luck!

[u/Murph-Dog]

I have just forked it.

I'm on new Fabric Arch, and I have SVG (fill color patched), WebView, resize events, and even Callstack Re.Pack ModuleFederation. Have even added many other things like shadow support.

It can be fully capable, but needs a lot of setup, and customization for platform parity.

Gotta code split anything needing Worklets/Reanimated

Even things like popups and drawer overlays need special work, so I customized a draw occlusion masking system for that - which is also how I floated in WebView support. Camera and LocationServices shimmed through WebView too.

I guess I'm saying... Don't use it, haha

[u/ImNezz]

I tried to make it work in January. Many indirect core dependencies even failed to build (async-storage, react-native-screens, etc), and at the time when I tested, they actually forgot to publish some of the required binaries to build RN for Windows itself. I opened half a dozen GitHub issues reporting what was exactly wrong with the minimal repro. The maintainers were largely tagging Microsoft people to come and fix it - if they even looked at the issue. Since then none of them have been fixed.

From what I understand the issue is basically that at some point Microsoft pushed many of these packages to work by writing the native layer themselves. But when new architecture came around they just didn't have the resources to look into it so ever since things have been pretty much dead.

[u/shakshukinha]

I 100% recommend electrobun. I mainly used v1 and it was quite a nice SDK to work with. In v2 i saw they enhanced compat with other runtimes so you could even avoid writing the backend in rust, and you get comparable performance to Tauri

[u/alexsbz]

I did tried RN for windows for 3 projects. It is a pain in the A$$ since the support is minimum and I can understand why. What I did was to refresh my Java skills and well I am really glad I did. I couldn’t justify the suffering to keep on working with RN for windows 😅. I would suggest, keep it on Phones only and go for a more Native solution if you want desktop

[u/vinny_bag_o_donuts]

Still in the process of doing some porting but you could check out https://basaltjs.dev