This point of view always confuses me, because web developers already need to deal with platform differences. Especially if your app app also runs in a browser, like Slack and Discord — at that point, what issues do the differing system webviews cause that you don't need to deal with anyway just targeting browsers?

It's also funny to me as someone who's been building websites for 20+ years at this point, because the platform differences used to be much, much worse. Coincidentally, I just saw this article, which makes the case nicely: https://www.bram.us/2026/06/21/do-websites-need-to-function-...

The platform webviews are significantly older/worse than typical web browser versions, especially on macOS and Linux.

On macOS, the only way to upgrade your WebView is to upgrade your OS, which requires rebooting. Lots of people just don't bother. You can upgrade to the latest Chrome or Firefox just by downloading it (assuming they support your macOS version), and they auto-upgrade themselves pretty aggressively.

On the web, very old versions of Safari (6+ years old) are a tiny fraction of a percent of your traffic; many web developers just ignore them. In a desktop app based on a WebView, ancient WebViews can be as high as 10-15% of your macOS user base. Ignoring them is not an option.

On Linux, it's common for the major version of WebKitGTK to not upgrade at all except during major OS upgrades. Anyone on Ubuntu LTS 20 is going to have a 2020-vintage WebKitGTK with security patches. (And Ubuntu LTS 20's WebKitGTK was buggier than macOS WebKit, even in 2020, because Apple has more dedicated full-time developers and testers making sure that macOS WebViews work end-to-end.) If you're shipping an app based on WebKitGTK, you can expect to see double-digit percentages of your Linux users running really old WebKitGTK.

Maybe you're such a great developer that your web app works great on ancient browsers, but, if so, it's probably because you didn't need/use much JS in the first place. (Maybe you used HTMX or something.) In that case, is there even any benefit in shipping a "desktop app"? What's your desktop app even for? Offline support? (But your app is all server side…?)

If you have a JS-intensive app that works great on ancient, buggy browsers, then platform WebView might work for you. It's not nobody, but it's hardly anybody.

webkitgtk isn't just quirky, it's also much slower compared to more popular browser engines and is particularly bad with RAM usage.

Yes, we're used to platform differences, but that's kind of the benefit of shipping a desktop app, isn't it? So that we don't have to deal with the platform differences. If you bundle the browser, then that ought to all go away. No graceful degradation necessary, no polyfills.

> This point of view always confuses me, because web developers already need to deal with platform differences.

On Mac, I use Firefox and Chrome.

However, if I use a Tauri app on Mac, I have to use dated WebKit. It's out of a Tauri developer's control.