SFSafariViewController vs WKWebView
One gives you control over the experience, the other gives your users a working browser. The choice is not subtle.
6 August 2026 ยท PAD team
The difference in one table
| SFSafariViewController | WKWebView | |
|---|---|---|
| Shares Safari cookies | yes | no |
| Opens store links | yes | no, unless you implement it |
| You can read the page | no | yes |
| You can style the chrome | barely | fully |
| Apple Pay and 3-D Secure | works | usually fails |
When to use SFSafariViewController
Any time you are showing content you do not own: a support page, an external article, a payment flow, a login with a third-party provider. The user gets a real browser with their sessions intact, and everything works.
Apple also requires it, or the real browser, for OAuth flows in many cases, so this is not purely a preference.
When WKWebView is right
When the content is yours and the app needs to interact with it: a hybrid interface, an embedded editor, anything where JavaScript needs to talk to native code. You are building part of your app in HTML rather than displaying the web.
The pattern that causes trouble
Using WKWebView to display external links because it looks nicer or keeps the user inside. That is the choice Instagram and Facebook make deliberately, and it produces every problem described across this blog.
If you do it, implement the scheme hand-off so at least store links work. It is a dozen lines and your users will never know why the app feels less broken than its competitors.
And if your link is the one being opened in someone's WKWebView, we handle the rest.