Currently there is no way for a website that has been loaded into a WebView to target links to open in the user's Default Browser rather than the current WebView. Often, native apps create embedded In-App Browser experience leveraging the WKWebView component, even for viewing shared links to external third-party websites. For example, Facebook, Instagram, LinkedIn, etc, all do this. Opening external websites in an embedded WebView could be considered a UX Dark Design Pattern - one that is constructed to, at best, inflate the containing app's engagement metrics, and at worst, to enable the containing app to spy on and extract data from the User's activity on third-party websites. User's are not aware of the potential for their activity to be tracked. Also, WebViews provide a diminished full browsing experience which is, again, not in the User's best interests. On iOS, app developers have the option of using the SFSafariViewController component (https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) to create a secure and full-featured In-App browser experience. However, if app developers are going to use WKWebView to load third-party websites, then those websites should have the ability to detect and break out of the containing WebView. One potential solution would be to have a URL scheme for opening URLs directly into Safari browser proper, or better still, open URLs into the User's chosen Default Browser with a browser-agnostic scheme.
Perhaps I'm misunderstanding something, but apps can already open URLs in the default browser if they choose to with something like UIApplication.shared.open(URL(string:"https://example.com/")!) If an app does not want to break out into the default browser, then they don't have to. Are you suggesting we remove that choice?
@Alex, thanks for looking at this. My suggestion is from the perspective of Website Developers, not the App Developers. For example, Facebook's App Developers have made the choice to open all external web links in an embedded WebView. Content they don't own, manage, or need to interact with, but they are choosing to still open in a WebView. As the owner / developer of a website or web app, I have no control over how Facebook opens links to my site. My site is stuck in Facebook's WebView. Due to complexity, security or feature support, Website owners may prefer their content to always be viewed in a proper web browser. It's possible for the website to detect that it's running inside a WebView and display messaging to encourage the user to open in their main browser. But it's not currently possible for that website to provide a quick and easy link to open the current website in the user's main browser. Thus, providing a url scheme for opening a URL in the default browser would allow websites / web apps to more seamlessly transfer users. Facebook, Instagram, LinkedIn are just some of the big social apps that do this. A notable exception is Twitter, which opens third-party websites in a SFSafariViewController component.
(In reply to Alex Christensen from comment #1) > If an app does not want to break out into the default browser, then they > don't have to. Are you suggesting we remove that choice? Just to directly answer your question: no, I'm not suggesting removing that choice ;)
<rdar://problem/93039935>
I didn't see anything at WWDC2022 that might address this. Any chance the original requestit can be taken under consideration?
The original request has been acknowledged.
(In reply to Alex Christensen from comment #6) > The original request has been acknowledged. Much appreciated. Cheers!
I have no appreciation for how complex it would be to implement this, but the ability to allow web developers to have links "break out" of WebKit into Safari would be incredibly valuable. As Miles writes, if webkit could include "a url scheme for opening a URL in the default browser [to] allow websites / web apps to more seamlessly transfer users." - that would make the entire internet's job of transitioning to seamless mobile experiences way easier. There a million different ways that the apps can choose to implement webkit, which basically means that a site owner needs to bear the burden of testing/supporting them all. With a way to break out of the app's default, the "interesting" parts of the site would only have to support iOS Safari to guarantee a consistent user experience.