4 ms·

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

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.

layer8 3y ago
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.
- giantrobot 3y ago
  > 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.
  - layer8 3y ago
    > 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.
    - shuckles 3y ago
      "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.
    - giantrobot 3y ago
      I'm not saying sites can't or shouldn't be fixed to support browsers other than Chrome. The fact of the matter is these sites exist and aren't incentivized to support anything but Chrome. When an overwhelming proportion of visits are through Chrome they only support Chrome, just like when those visits were IE6 and sites only supported IE6. Their advertisers love all of Google's web API proposals because they feed fingerprinting mechanisms. Sites that only support Chrome and have no need to support Safari (WebKit) will continue to support Chrome. Users that want to have a third party browser handle web views in apps or web apps won't have meaningful options as WebKit won't be a requirement so every site will code only to Chrome. The status quo at least requires a vendor support WebKit if for no other reason is to support web views in their iOS apps.
      - layer8 3y ago
        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.
        giantrobot 3y ago
        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/?form=MA13LH https://learn.microsoft.com/en-us/microsoft-edge/webview2/?f...

layer8 3y ago

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.

giantrobot 3y ago
> 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.
- layer8 3y ago
  > 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.
  - shuckles 3y ago
    "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.
  - giantrobot 3y ago
    I'm not saying sites can't or shouldn't be fixed to support browsers other than Chrome. The fact of the matter is these sites exist and aren't incentivized to support anything but Chrome. When an overwhelming proportion of visits are through Chrome they only support Chrome, just like when those visits were IE6 and sites only supported IE6. Their advertisers love all of Google's web API proposals because they feed fingerprinting mechanisms. Sites that only support Chrome and have no need to support Safari (WebKit) will continue to support Chrome. Users that want to have a third party browser handle web views in apps or web apps won't have meaningful options as WebKit won't be a requirement so every site will code only to Chrome. The status quo at least requires a vendor support WebKit if for no other reason is to support web views in their iOS apps.
    - layer8 3y ago
      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.
      - giantrobot 3y ago
        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/?form=MA13LH https://learn.microsoft.com/en-us/microsoft-edge/webview2/?f...