Really the only reason we use CEF on Linux is because Linux doesn't provide a built-in system webview (or at least nothing consistent enough to depend on) like WebView2 on Windows and WKWebView on macOS.
If we have two export options for the same platform it's twice as much as much work to develop, maintain, support, document etc. and that directly reduces our capacity to make other improvements to Construct, so overall I think such a move would overall be a bad outcome for Construct.
The Steam Overlay is a known issue, but:
- Steam has fallbacks to handle the in-game overlay not being supported - it shows the actual Steam UI instead
- I don't think that is a serious enough problem to warrant the large amount of work both up-front and on-going work it would take to have a secondary export option
- I couldn't actually get the Steam Overlay to work correctly on Linux desktop with CEF either - so even doing all that work is no guarantee it will end up working
- The Steam Overlay never actually worked that well with NW.js either - we had a bunch of hacks to get it working (and it would be the same for CEF), and those hacks could stop working at some point, which would leave us in the same situation needing Valve to fix it
- It's entirely possible that Valve could fix it for our existing export options and then it's all sorted with no need for secondary export options (and Valve fixing it would also make sure it works much better with NW.js/Electron/CEF)
- The Steam Overlay works fine on the Steam Deck, because it works differently (drawing in a layer over the game instead of intrusively modifying the game executable). So that demonstrates if desktop platforms worked the same, it would work fine there too.
In short, if there are two major features to do the same thing, it is a lot more work and a continual drain on our limited resources, and it's confusing for users too. In my view the best approach for the long term is to focus on one solution and resolve any problems with that. In other words: if you have one major feature and it has a problem, and your solution is to introduce a whole new second major feature, now you have two problems.
I found tons of reddit threads of people uninstalling their WebView from Windows because they don't like too many background processes.
Well, that's a crazy thing to do in my opinion, but our WebView2 exporter is designed to prompt the user to install WebView2 if it's missing, so it should not be a major problem - if someone uninstalled it, a Construct WebView2 export will prompt them to reinstall it.
Maybe as a side-note: are there plans for Scirra to also develop their own Mobile Wrappers?
At the moment Cordova does the job well, so I don't think there is any reason for us to do that. In particular there is a large existing ecosystem of Construct plugins using Cordova plugins, so moving off that would be far more painful than changing the desktop export technology.