WebViews Q&A

Hi, I see that on WebViews we don't get the same interface for allowing the user to use a saved password or passkey as in Safari or on an Authentication View. Can the same be accomplished on a WebView?

The new WKJSScriptingBuffer API allows Swift to define data buffers and make them available to JS code running in a WKWebView. Is there any API for passing an ArrayBuffer of data from a WKWebView to Swift code? Currently the usual workaround is to convert the buffer to a base64 string, but that is slow and can lead to exhausting memory depending on the size of the buffer. On the web, window.postMessage() has an argument that allows transferring ownership of ArrayBuffers to the receiver, but the webkit.messageHandlers.<name>.postMessage() API doesn't seem to support that.

Context: This is for a privacy relay in a browser, where the proxy is toggled on/off and rotated mid-session, so we can't lose the user's logged-in sessions when it engages. Connection pool behavior — is this expected? When we mutate proxyConfigurations on a live data store, the proxy only applies to newly-visited origins. Origins that already have established connections keep going direct — reloading the page, and even tearing down and recreating the WKWebView, doesn't move them onto the proxy. The only thing that reliably forces all traffic through the proxy is swapping in a brand-new WKWebsiteDataStore. Is that the intended behavior — i.e. is recreating the store the expected way to re-establish the connection pool — or is there a supported way to invalidate the existing connections so a mutated proxy config takes effect on already-loaded origins? What does fetchData / restoreData actually carry? To preserve the session across that store swap, we serialize the old store with fetchData(of: WKWebsiteDataStore.allWebsiteDataTypes()) and rehydrate the new one with restoreData(_:) (iOS 26). Passing the full allWebsiteDataTypes() set: Does this round-trip everything those types represent — cookies, localStorage, IndexedDB, service worker registrations, etc. — into a store created with init(forIdentifier:)? Does anything not enumerated by allWebsiteDataTypes() — per-site permissions, tracking-prevention/ITP state — get dropped silently?

I build a framework that has a function that returns a UIView with a web view inside. The app that uses the framework has control over the webview through the subviews API of my UIView. I do not want the framework consumer to utilise the web view's methods and properties. How do I limit access to web view methods like evaluateJavascript, navigation delegate etc?

Context: This is for a privacy relay in a browser, where the proxy is toggled on/off and rotated mid-session, so we can't lose the user's logged-in sessions when it engages. Connection pool behavior — is this expected? When we mutate proxyConfigurations on a live data store, the proxy only applies to newly-visited origins. Origins that already have established connections keep going direct — reloading the page, and even tearing down and recreating the WKWebView, doesn't move them onto the proxy. The only thing that reliably forces all traffic through the proxy is swapping in a brand-new WKWebsiteDataStore. Is that the intended behavior — i.e. is recreating the store the expected way to re-establish the connection pool — or is there a supported way to invalidate the existing connections so a mutated proxy config takes effect on already-loaded origins? What does fetchData/restoreData actually carry? To preserve the session across that store swap, we serialize the old store with fetchData(of: WKWebsiteDataStore.allWebsiteDataTypes()) and rehydrate the new one with restoreData(_:) (iOS 26). Passing the full allWebsiteDataTypes() set, does this round-trip everything those types represent — cookies, localStorage, IndexedDB, service worker registrations, etc. — into a store created with init(forIdentifier:)? And does anything not enumerated by allWebsiteDataTypes() — per-site permissions, tracking-prevention/ITP state — get dropped silently?