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?

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?

I am trying to get universal links to work in our app Firefox iOS The Problem: I am not able to get universal links to work for our release app or beta app scheme locally or with a TestFlight build. I am able to get it working on our development scheme with a locally hosted app site association file. I also was able to get it working using our development scheme but setting the bundle id to the release app bundle id. I also built a demo app with the release app id and the release app development certificate. It succeeded there as well. Implementation Steps: Added associated domains entitlement to the production and beta schemes for our main app target (No associated domains entitlements or capabilities added for any extensions) Confirmed that the bundle ids associated with these schemes have the associated domains capability Added applinks:blog.mozilla.org to associated domains list Confirmed in code that user activities are being handled via SceneDelegate.swift Steps to Debug: I have gone through and validated every step in the provided Universal Link Debugging. All were successful: Associated Domains Development -> Diagnostics: Opens Installed App Validate AASA host and applinks match curl -v https://blog.mozilla.org/.well-known/apple-app-site-association returns the expected json file swcutil dl correctly downloads the AASA blob swcutil verify succeeds I have inspected the IPA of our beta build and confirmed the App ID and the associated domains is an entitlement. I have looked at the console logs filtering by swcd. I am not seeing any errors and I see the download for the AASA file kick off: Beginning data task AASA-4BABF039-3C69-4E36-AA4E-ECCDF3D14878 { domain: bl….mo….org, bytes: 0, route: cdn } There is only one error that appears in the console but our app is not enterprise-managed so I assume this is normal. Error getting enterprise-managed associated domains data. If this device is not enterprise-managed, this is normal: Error Domain=SWCErrorDomain Code=1701 "Failed to get associated domain data from ManagedConfiguration framework." UserInfo={NSDebugDescription=Failed to get associated domain data from ManagedConfiguration framework., Line=298, Function=<private>} I have run Sysdiagnos and identified for our App ID: Site/Fmwk Approval: approved I am at a loss as to what is preventing universal links from working even though all validation steps pass.