> This is an incorrect understanding of how web views are implemented.
No, it’s not. Nothing requires you to use SFSafariViewController.
As you yourself noted, WKWebView exists and grants the application effectively complete control over it.
UIWebView also still exists, and despite being deprecated, remains usable.
Finally, even if everything but SFSafariViewController were removed from the OS, nothing stops the application developer from embedding their own replacement webview implementation.
> However, it would be possible for the platform vendor to restrict use of the web view such that only certain more powerful APIs can be used by browser-style apps, while other less sensitive APIs can be used by all apps.
Such a restriction would be equivalent to the existing SFSafariViewController, but regardless, I must reiterate: absolutely nothing stops the application developer from embedding their own replacement implementation.
> This is because pretty much all of the APIs involve an IPC from the embedding process (e.g. an app under third party control) to another process that actually powers the view under the control of the browser engine (usually the content/renderer process).
Again, nothing stops the application developer from embedding a replacement for your hypothetical sandboxed webview API.
No, it’s not. Nothing requires you to use SFSafariViewController.
As you yourself noted, WKWebView exists and grants the application effectively complete control over it.
UIWebView also still exists, and despite being deprecated, remains usable.
Finally, even if everything but SFSafariViewController were removed from the OS, nothing stops the application developer from embedding their own replacement webview implementation.
> However, it would be possible for the platform vendor to restrict use of the web view such that only certain more powerful APIs can be used by browser-style apps, while other less sensitive APIs can be used by all apps.
Such a restriction would be equivalent to the existing SFSafariViewController, but regardless, I must reiterate: absolutely nothing stops the application developer from embedding their own replacement implementation.
> This is because pretty much all of the APIs involve an IPC from the embedding process (e.g. an app under third party control) to another process that actually powers the view under the control of the browser engine (usually the content/renderer process).
Again, nothing stops the application developer from embedding a replacement for your hypothetical sandboxed webview API.