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/restoreDataactually 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?
