6 ms·

More: - you can't uninstall Safari. The DMA clearly requires Apple to allow uninstalling it. - the Share Sheet for in-app webview privileges Safari (Safari-sp

More: - you can't uninstall Safari. The DMA clearly requires Apple to allow uninstalling it. - the Share Sheet for in-app webview privileges Safari (Safari-specific "Add to Reading List", "Add Bookmark" at the top) regardless of default browser. - 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. - confusing to change defaults. There's no central "Default Apps" screen in Settings. You have to go in the Settings app, scroll way down to a given browser, and then you can change the default. So the default browser setting is weirdly treated as an app-specific setting rather than a system setting. - If Safari is not the default, you can change your default browser within "Settings.app >> Safari". If Safari is the default, you can't change your default browser there at all. Whereas the default browser selection menu will always be shown in the Settings.app submenu of third-party browsers.

throwaway-blaze 3y ago
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.
noway421 3y ago
> 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.
- st3fan 3y ago
  > 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/ 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.
  - nani8ot 3y ago
    > [...] 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.
- concinds 3y ago
  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.
jwells89 3y ago
> 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.
- deleted 3y ago
  [deleted]

throwaway-blaze 3y ago

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.

noway421 3y ago

> 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.

st3fan 3y ago
> 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/ 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.
- nani8ot 3y ago
  > [...] 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.
concinds 3y ago
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.

jwells89 3y ago

> 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.

deleted 3y ago
[deleted]