Why Apple Isolated SFSafariViewController Cookies in iOS 11

In iOS 11, Apple fundamentally changed how its in-app browser, SFSafariViewController, handles user data by isolating its cookies from the main Safari web browser and other apps. Previously, a shared cookie space allowed developers to offer seamless single sign-on experiences and persistent web sessions, but advertising networks quickly exploited this architecture to track users across different applications without their consent. This article explains the mechanics of how this shared cookie loophole was abused for covert cross-app tracking, why Apple intervened with strict data sandboxing in iOS 11, and how the company introduced new authentication frameworks to preserve legitimate login workflows while locking down user privacy.

The Original Design in iOS 9 and 10

When Apple introduced SFSafariViewController in iOS 9, the goal was to give developers a secure way to display web content inside their apps without forcing users to leave the app and open the main Safari browser. Before this, developers built custom in-app browsers using UIWebView or WKWebView, which gave the host app full access to the web view's data, including passwords and cookies.

SFSafariViewController solved this security risk by running in a separate process outside the host app's reach. Crucially, it shared a single "cookie jar" with the main Safari browser. If a user was logged into a website on Safari, they would remain logged into that website when opening a link inside a third-party app using SFSafariViewController. This shared state also made it easy for developers to implement Single Sign-On (SSO) and OAuth flows.

The Cross-App Tracking Loophole

Because SFSafariViewController shared cookies across the entire operating system, advertising technology companies and data brokers realized they could use it to bypass Apple's privacy controls, specifically the ability for users to limit ad tracking via the Identifier for Advertisers (IDFA).

Ad networks embedded within third-party apps began abusing SFSafariViewController through a technique involving hidden or imperceptible web views:

  1. Silent Loading: When a user opened an app containing a tracking SDK, the app would silently spin up a tiny, invisible, or 1x1 pixel SFSafariViewController instance in the background, pointing to a tracking domain owned by the ad network.
  2. Writing the Cookie: That domain would drop a unique tracking cookie into the browser's storage. Because SFSafariViewController shared storage with the main Safari browser, that cookie was now stored globally on the device.
  3. Cross-App Identification: When the user opened a completely different app that used the same ad network, that second app would also silently load an SFSafariViewController pointing to the same tracking domain. The domain would read the cookie dropped by the first app.

Through this method, trackers could easily build a comprehensive profile of every app a user opened, completely ignoring the user's system-level privacy settings and Apple's standard app sandboxing rules.

Apple's iOS 11 Intervention: Sandboxed Storage

To eliminate this covert tracking vector, Apple re-architected SFSafariViewController in iOS 11. They severed the link between the in-app browser and the main Safari browser.

Starting in iOS 11, every app using SFSafariViewController was given its own isolated, sandboxed cookie storage.

  • Cookies stored in the main Safari app could no longer be read by SFSafariViewController.
  • Cookies stored in App A's SFSafariViewController could no longer be read by App B's SFSafariViewController.

This immediately rendered the hidden web view tracking method useless. Even if an ad network loaded a hidden SFSafariViewController to drop a cookie, that cookie was trapped inside that specific app's sandbox, preventing any cross-app correlation.

Preserving Single Sign-On

While isolating cookies successfully stopped cross-app tracking, it broke legitimate use cases, particularly Single Sign-On. Users suddenly had to re-enter their credentials in every app rather than relying on their existing Safari sessions.

To solve this, Apple introduced a dedicated API in iOS 11 called SFAuthenticationSession (later replaced by ASWebAuthenticationSession in iOS 12). This API was built specifically for authentication flows and was allowed to access the main Safari cookie jar, but with one critical privacy safeguard: a mandatory system alert.

Whenever an app invokes this authentication session, iOS displays a prominent, un-spoofable dialog box asking the user for permission (e.g., "App" Wants to Use "example.com" to Sign In). Because this prompt requires explicit user interaction before the web view even loads, ad networks cannot run it silently in the background. By separating general web browsing from explicit user authentication, Apple successfully shut down covert cookie tracking while keeping seamless login experiences intact.