WKWebView limitations

A reference for developers embedding a browser, and for anyone whose page keeps landing inside one.

6 August 2026 · PAD team

The component

WKWebView is the rendering engine apps embed to show web content. It is the same engine Safari uses, so pages look and behave identically at the rendering level. Everything below is about the container rather than the renderer.

URL scheme hand-off

The one that costs money. A WebView cannot open another app's URL scheme unless the host app implements decidePolicyFor and calls UIApplication.shared.open explicitly. Most do not, which is why itms-appss:// dies there.

// what a host app has to implement for store links to work
func webView(_ webView: WKWebView, decidePolicyFor navigationAction: …) {
  if let url = navigationAction.request.url,
     !url.scheme!.hasPrefix("http") {
    UIApplication.shared.open(url)
    decisionHandler(.cancel); return
  }
  decisionHandler(.allow)
}

Storage isolation

Cookies and local storage live in the app's data store, separate from Safari. Sessions do not carry over in either direction, and clearing Safari's data leaves the WebView's untouched.

Payments

Apple Pay through the web requires a merchant validation flow that most embedded WebViews do not support. Third-party 3-D Secure sheets often fail for the same reason: they expect to open a window the container will not provide.

Other gaps worth knowing

• No download manager, so file downloads fail or silently do nothing
• window.open is frequently ignored or opened in place
• Camera and microphone permission prompts may be suppressed entirely
• Print and share sheets depend on the host app implementing them

If you are the one embedding it

Implement the scheme hand-off. It is a dozen lines and it prevents your users from hitting blank pages on any store link they encounter. The apps that skip it are usually doing so deliberately to keep people inside, which is a product decision rather than an oversight.