> It should obviously use the webview facility provided by the default browser

Android doesn't do that either. You get Android System WebView which is always WebKit/Blink.

Windows didn't provide any browser engines apart from Trident through mshtml.dll either.

It would make iOS development harder - instead of getting a web view working just for WKWebView, you would need to get it working for every WebView out there. Given that they are not full browsers, it's not as simple as following web standards/caniuse. For example, service worker support in in-app browsers is limited.

If this actually gets implemented, every app out there will most likely pin the in-app browser engine to WKWebView OR bundle a binary blob with their own browser engine directly into .ipa. Bundled browser engine in .ipa has privacy implications - the app will be able to fully read secure HTTPS cookies of the sites that user visits - something that's currently protected.

> Android doesn't do that either. You get Android System WebView which is always WebKit/Blink.

Not if the application uses Custom Tabs to start a web browsing activity.

https://developer.chrome.com/docs/android/custom-tabs/

Firefox fully supports this and if you set it as a default browser you will many apps open content in a Firefox powered webview. (Activity)

Apple can do the same. Not trivial but definitely possible.

> [...] if you set [Firefox] as a default browser you will many apps open content in a Firefox powered webview. (Activity)

This is great because the Firefox webview allows to break it out in to a proper Firefox tab in the app. Also, the Firefox webview also uses extensions installed in Firefox app, e.g. uBlock Origin.

Thanks to you and others for pointing these out. I want to make clear that this isn't the EU's list and is just stuff I could observe disregarding my default browser choice. But if there's good reasons, by all means, don't make developers' lives hell.

> apps with in-app webviews can roll out a custom engine, but otherwise it uses WebKit regardless of default browser. It should obviously use the webview facility provided by the default browser, if it offers one.

This has massive potential to break an unbelievable number of things, first-party and third-party alike. WebKit is used in all sorts of places people wouldn’t expect, for example at one point UILabel (the native control responsible for displaying non-scrolling text and labels) used WebKit under the hood for rendering attributed strings.

The default browser has no technical ability in iOS (currently) to supply an in-app component to replace WKWebView or SFSafariViewController, and frankly as an app developer I shudder at the idea of having to test our use of in-app browsers against every browser, every release.

I think that in-app browsers that are solely used to render the app, and not separately accessible web pages, should be considered an implementation detail of the app. That also means that apps should be free to bring their own browser engine for that purpose (à la Electron). However, where apps provide access to web sites that are also accessible outside the app, the user should be able to configure the browser for that (possibly different from the system default). That should pose no particular problem for app developers, as those external web sites need to work under different browsers anyway.

> as those external web sites need to work under different browsers anyway

You say that but many sites essentially only support Chrome (and Edge by extension). If you install Firefox, or keep Safari, and the external sites just continues to assume everyone downloads Chrome you get nice broken web views. Or if a user changes the default browser (and thus web view engine) after the fact.

> many sites essentially only support Chrome

Yes, but they shouldn’t, and it’s not that difficult, so I have no sympathy. It’s also not that many.

I don’t see why the situation for viewing public websites from within apps should differ from the situation on the desktop. People choose which browser they use on the desktop, and live with any difficulties that may or may not bring. (E.g. I’m using Firefox and have few problems.) So the same would be the case for browsers in mobile apps.

Firefox isn't a transitive dependency on the desktop. If an app uses a WebView[0] control on Windows, Firefox has no effect on its behavior and performance. It uses the Edge engine to power WebViews. On iOS WKWebView currently uses WebKit.

The EU apparently wants to change this behavior on iOS. A WKWebView would be backed by the system's default browser selection if it made claim to support WKWebKit views. So your third party app with no direct connection to Firefox that uses a WKWebKit view now depends on Firefox handling the loaded pages in the view. If they don't work in Firefox or whatever browser the user has selected the third party app is affected by the choice of browser. This also has an affect on web apps on the Home Screen.

The issue with Chrome is it already dominates the web. App vendors will drop Safari WebKit support as soon as WKWebKit no longer mandates the site work in Safari WebKit. Without iOS enforcing support for Safari WebKit by being the only option for the non-trivial number of iOS users of the web, Chrome will be the only supported browser in apps and the wider web.

[0] https://learn.microsoft.com/en-us/microsoft-edge/webview2/?f...

...apps don't use WebViews on Windows (or MacOS really, for that matter) because they are unstable APIs that Microsoft and Apple both break in nonsensical ways. It's why Electron is king, in many respects. The only desktop software that use WebViews afaik are the "native apps" which really ought to be handled with a leaner library anyways.

> App vendors will drop Safari WebKit support as soon as WKWebKit no longer mandates the site work in Safari WebKit.

Some will. Wanna guess why?

"It’s fixable so it should be fixed, and even if it’s not fixed, it doesn’t matter," is a pretty good summary of how much thought the pro-regulators are bringing to the topic.