I wonder if it's possible to switch from NWJS to WebView2 in an already published Steam game?
I think the only serious problem is how to handle Local Storage specifically. Local Storage data goes in to a database somewhere in the app data folder. I don't think there's any good documentation on how it works - despite the fact both use the Chromium browser engine, I wouldn't be surprised if there were weird issues that come up with pointing WebView2 at an NW.js app data folder.
On the other hand, using files for storage will work with either kind of exporter. So if your project writes storage as files to some known folder that both NW.js and the File System plugin can access, then both can read/write safely to the same files.
If you have an existing project deployed using Local Storage though, this is a tricky migration to pull off. You'd probably have to go through three versions:
- Version A: existing NW.js export using Local Storage
- Version B: an updated NW.js export that uses files instead, and automatically copies any existing Local Storage to files for backwards compatibility
- Version C: a WebView2 export that only uses files and does not attempt to use Local Storage
This is tricky to set up so definitely test anything like this carefully and thoroughly. However with this approach so long as everyone updates A -> B -> C, it should continue working without anyone noticing anything. One particularly difficult problem though is that even long after version C is out, anyone updating directly from A -> C will lose their save data. With software updates it is very difficult to guarantee exactly 100% of people have updated - usually it approaches but does not meet 100%, going 99%, 99.9%, 99.99% etc. and a few people end up left out for whatever reason. One way to mitigate this is to move to version B as soon as possible, but I doubt that will completely solve the problem - you'll still have a few people who lose their data. Another way to mitigate that is to have explicit "export your data" and "import your data" options in the user interface, so you can document this and provide manual instructions for anyone left behind, ideally with instructions on how to roll back to version A if they need to.
We've gone through such migrations with Construct a few times over the years and they can be a challenge. My advice: approach with a great deal of caution and do it slowly over time.
The other option is: just stick to NW.js. It's a lot easier as it means not having to do anything different! I think we will continue to support it until the next LTS release, which should mean at least LTS support until the end of 2026. Even after that, if anyone had major published projects that desperately needed some change, we'd still do it if at all possible - I appreciate there's lots of long-term projects out there still using NW.js and we don't want anyone to be left stuck with problems out of support.