ASWebAuthenticationSession cookie

I am curious why you need to rely on the domain:process mapping though, if you don't mind to share. Thanks for the response! We don't need to rely on domain:process mapping, but I'm trying to understand what we can rely on. For example, each domain is a separate account - things like cookies, caches, etc are probably not to be shared across accounts. I'm looking at the header for NSFileProviderDomain right now, and I see this comment: On the extension side, a separate instance of NSFileProviderExtension will be created for each @c NSFileProviderDomain registered. In that case, the @c NSFileProviderExtension.domain properties will indicate which domain the NSFileProviderExtension belongs to (or nil if none). This is what led me to believe that all of the calls for a particular domain would be routed to a single process. I'm finding that not to be the case - calls for any domain can come to any Files Extension process, which would seem to contradict that comment as I understand it. Is that as expected?

me too affected with this; for safari 17.6 on macOS 12.7.5 and iOS 18.5, won't send cookies(not even same site) while fetching images.

might not be supported Bug, check OS predisposition Cookies w/.

I think a few different concepts are getting mixed up here. There's the concept of Associated Domains, where you can form a two-way association between an app and a website. Setting this up when you control both the app and the website lets the system provide some additional security-sensitive features, like improved password AutoFill and passkey support. ASWebAuthenticationSession itself currently doesn't check anything with Associated Domains. It is mainly built for signing in to third party services, where the app and the website are owned by separate entities. The consent prompt for ASWebAuthenticationSession is because it allows the app to share data with Safari, which is something apps can't normally do without user consent. The only way to avoid the prompt is to set prefersEphemeralWebBrowserSession = true, though that also means no state can be shared. There are two potential other options worth exploring: If you own all the apps that you want to share state, you could use App Groups

ASWebAuthenticationSession is a full web browser instance, with access to web browser features and the web browser's cookies. WKWebView on the other hand is a way to embed web content inside another app. Conceptually, ASWebAuthenticationSession is managed by Safari, and WKWebView is managed by your app. There's no way to share cookies between the two. If you control the service you're signing in to, you could set up Associated Domains for your app and use WKWebView entirely. Using Associated Domains would mean you get the best AutoFill experience in your WKWebView, and have access to features like passkeys. If not, your options are more limited. If the service supports it, you may be able to use the auth token you receive from ASWebAuthenticationSession to bootstrap the session in the WKWebView, but depending on the service that may or may not be a viable option.