iOS Storage Isolation: Safari vs. Home Screen Web Apps

This article explains how iOS handles data sharing between the main Safari web browser and standalone Progressive Web Apps (PWAs) saved to the Home Screen. In short, both cookies and local storage are completely isolated between the two environments. Below, we cover the exact storage mechanisms affected, how this strict sandboxing impacts user authentication, and practical strategies developers can use to create a seamless user experience despite these limitations.

The Core Rule: Complete Sandboxing

Yes, cookies and local storage are strictly isolated between the Safari browser and standalone Home Screen web apps on iOS.

When a web application includes a Web App Manifest with the display property set to standalone (or fullscreen), or uses the legacy apple-mobile-web-app-capable meta tag, iOS does not open the saved bookmark in Safari. Instead, it launches the web app in a separate, dedicated WebKit environment. Apple enforces a strict security sandbox around this environment, treating the Home Screen web app as an entirely separate application from Safari.

Furthermore, if a user adds the same web app to their Home Screen twice, iOS isolates the storage between those two individual Home Screen instances as well.

What Data is Isolated?

Because the standalone web app runs in its own isolated container, no client-side storage is shared with Safari. This isolation applies to:

• Cookies: Session cookies and persistent cookies set in Safari cannot be read by the Home Screen app, and vice versa.
• Local Storage and Session Storage: Any key-value pairs saved via localStorage or sessionStorage in the browser are completely unavailable in the standalone app.
• IndexedDB: Databases created in Safari do not exist in the Home Screen app's context.
• Cache API and Service Workers: Service workers must be registered again when the user launches the Home Screen app, and cached assets are not shared.

How This Impacts User Experience

The most noticeable consequence of storage isolation is interrupted user authentication.

A common user flow involves a person discovering a web app in Safari, creating an account, logging in, and then deciding to add the app to their Home Screen. When the user closes Safari and taps the newly created Home Screen icon, they will find themselves logged out. Because the authentication token (stored in localStorage) or the session cookie (stored in Safari's cookie jar) did not transfer to the standalone environment, the user is forced to log in a second time.

Workarounds for Developers

While you cannot bypass Apple's sandboxing rules to directly merge local storage or cookies, you can design your onboarding and authentication flows to minimize friction:

1. Prompt Installation Before Authentication The most effective strategy is to ask the user to add the app to their Home Screen before they log in. If the landing page detects that the user is on iOS Safari (and not yet in standalone mode), display instructions to install the web app first. Once they open the app from the Home Screen, they can log in directly within the isolated environment.

2. Leverage iCloud Keychain and Passkeys While browser storage is isolated, the operating system's password manager is not. If you properly configure your login forms with standard autocomplete attributes, or implement Passkeys (WebAuthn), iOS will allow the user to authenticate in the Home Screen app with a single tap via Face ID or Touch ID, using the credentials they just saved in Safari.

3. Pass a One-Time Token via the URL Just before a logged-in Safari user adds the app to their Home Screen, you can dynamically append a unique, short-lived token to the page's URL using the History API (history.replaceState) or by dynamically generating the Web App Manifest start_url. When the user launches the Home Screen app for the first time, it opens that specific URL. Your server can read the token, authenticate the user in the new standalone environment, and immediately invalidate the token for security.