WKWebsiteDataStore now decides both WKWebView's cookie isolation and its process count

The duplicate-store trap is the expensive one. Call `WKWebsiteDataStore(forIdentifier:)` twice with the same UUID and you get two distinct objects pointing at the same data on disk, and according to the dev.to post nothing crashes and nothing warns ^[6]. The cookies are shared, but as far as WebKit is concerned those web views are in different stores, so the processes are separate ^[6]. The fix in the post is a dictionary keyed by profile identity. It returns `.default()` for the standard profile, a named store for an isolated one, `.nonPersistent()` for ephemeral, and caches whichever object it built ^[7].

A browser with three profiles and four open tabs each, constructing a store object at the point of use, holds twelve distinct stores where the cache would hold three. Every distinct store is its own set of network and content processes ^[2]. The API surface looks the same in both cases. The disk layout is identical either way ^[6].

Deletion is where the ownership question becomes concrete. `WKWebsiteDataStore.remove(forIdentifier:)` throws while any reference to the store is alive, and that includes the cached object and a web view you pulled out of the view hierarchy but are still holding ^[8]. The author writes that he measured retrying on its own, and the retries fail for as long as the reference exists ^[9]. The sequence that works is to drop the cached object first, then retry up to five times with 250 millisecond sleeps to cover the gap between release and deallocation ^[10]. That is four sleeps, so about a second of waiting in the worst case ^[1]. On the fifth failure the snippet returns without throwing, so the caller cannot tell it from a success ^[3].

The default store cannot be removed at all; you empty it with `removeData(ofTypes:modifiedSince:)` instead ^[11]. Two code paths for one button labelled "delete everything", and an app with more than one kind of profile needs both ^[11].

The window.open delegate carries a different constraint. The new web view has to be built with the `WKWebViewConfiguration` WebKit handed you, or the opener relationship breaks. `window.opener` comes back null, named targets stop finding the window, and OAuth popups that post back to their opener fail silently ^[12]. So the creation helper takes a configuration parameter instead of making its own. Properties set on the `WKWebView` itself are fine there, but user scripts, message handlers and content rules attach at configuration time, which means they have to be attached inside that delegate ^[13].

For any of this to transfer, it has to hold in the WebKit you ship against. The post is one developer's account of a few months building a tabbed browser with per-workspace cookie jars, downloads and extensions ^[1], all of it on macOS, with the author saying most of it applies to iOS too ^[14]. He describes Apple's class references as accurate about the API surface and silent on what happens when several parts are used together ^[15].