Home-screen web app vs Safari tab: cookies, logins and storage

When you add a website to your iPhone home screen as a web app, iOS opens it in its own window with its own cookies and website storage, separate from Safari. WebKit, Safari's engine, documents the split: when you tap Add to Home Screen, the site's current cookies are copied into the new app, and after that no other website data is shared. The separation is good for privacy, but it is not secrecy.

Why does the same site behave differently as an icon?

A Safari tab and a home-screen web app load the same address; the difference is where your phone keeps the site's data. MDN describes an installed web app as a standalone window, without the address bar or back button, that still runs inside a browser. Apple's guide has you turn on Open as Web App before you tap Add; the icon then opens the website like an app.

The storage is what makes it separate. WebKit's notes for Safari 17.2 say that when you create a web app this way, the cookies are copied over, including the login state, but only if the login is stored in cookies; no other local storage is copied, and once the app is added, no other website data is shared. WebKit describes the copy as new in iOS 17.2, so an app added earlier, or from a tab where you were logged out, had nothing useful to copy.

If tapping the icon opens a Safari tab instead, you have a bookmark rather than a web app; Add a website to your iPhone home screen: setup and fixes explains why. If web app and PWA are new words, start with What is a PWA?.

What is shared and what is not?

Cookies cross over once and never again, and storage never does. If a site keeps you signed in with something other than a cookie, the installed app starts signed out; sign in once inside it, and from then on signing out in Safari does not sign out the app. A file that exists in one place and not the other is likewise expected, not a fault. Why a website login may fail inside a web-app wrapper covers the sites where the login step itself misbehaves.

What does this mean for your privacy?

The benefit is compartments: the installed app cannot read Safari's cookies for the site, a Safari tab cannot read the app's storage, and what you do in the app is not listed among your tabs or in History. Apple's Private Browsing page treats History as a Safari feature, and WebKit says no website data is shared with the app after it is added; neither says outright that the app's pages stay out of Safari's History, so expect it, but do not count on it.

The mistake is to read separate as secret. It is not:

• The website sees everything you do in it, in either window, and keeps whatever it normally keeps.
• The network sees the connection: whoever runs your Wi-Fi, and your carrier, can see which servers your phone talks to.
• Anyone holding your unlocked phone can tap the icon, and if the site keeps you signed in, it opens straight into your account.

The compartments keep one window's data from the other; they do nothing about who picks up the phone. That is the job of the passcode and, for an extra step before one app opens, of Apple's Face ID lock for apps or a separate password lock such as PWA Lock's. PWA Lock's makers wrote this article, so take that as a pointer, not a verdict; iPhone app locks, private browsing and PWA Lock compared weighs the options. Apple does not say whether its app lock covers home-screen web apps, so check your own phone.

Can a home-screen web app send notifications?

Yes, since iOS 16.4; as WebKit describes it, this is a feature of home-screen web apps rather than of Safari tabs. The app can ask for permission only after a direct action of yours, such as tapping a subscribe button. Once allowed, WebKit says the notifications work exactly like other apps': they appear on the Lock Screen and in Notification Center, follow your Focus settings, and can put a badge count on the icon.

For privacy, remember that a notification previews the app's activity on your Lock Screen for anyone who glances at the phone.

How much can it store, and can that data disappear?

WebKit's storage policy post covers what a site keeps through local storage, IndexedDB, the Cache API, service workers and the file system API; cookies are outside it. One site may use up to 60% of the disk in a browser app, and a home-screen web app gets the same quota as in a browser.

WebKit deletes a site's data as a whole, least recently used first, when the overall quota is exceeded, when the system is short of space, or when a site has gone unused for a long time. Every site starts in best-effort mode, so nothing is guaranteed to stay; a site can ask for persistent mode, and WebKit grants it using heuristics such as whether the site is opened as a home-screen web app. That makes the installed app a safer home for local data than a tab, not a safe one.

The unused-site rule differs too: WebKit's tracking prevention deletes a site's script-writable storage after seven days of Safari use without interacting with that site, but home-screen web apps are not part of Safari, count their own days of use, and WebKit does not expect their own data to be deleted this way.

None of this is a backup: clearing website data removes the storage, eviction can remove it, and Apple does not document what deleting the icon does to it or whether an iPhone backup includes it. Anything you would miss needs a copy elsewhere; Before clearing website data: protect your local web-app files explains how.

What does this mean for a PWA Lock app?

PWA Lock gives a web app a locked copy at its own address, which the setup guide has you add to your home screen. iOS then treats it like any other home-screen web app:

• The first launch may ask for your account login. Its cookies are its own, so it may not know you are logged in to pwalock.com even if Safari does. Log in once; the login lasts 7 days on that device, and the lock page appears.
• The unlock belongs to one window. Unlocking in a Safari tab does not unlock the installed app, or the other way round, because the unlock is kept in that window's own cookies and session storage.
• The vault lives inside the app. With a vault passcode set, downloads made inside the app are saved to the app's origin-private file storage on that device, so files saved from the installed app are not visible when you open the same locked address in Safari, and the reverse. PWA Lock does not encrypt them or back them up anywhere, and clearing website data deletes them.
• Relocking uses the browser's visibility signals. The page script listens for the Page Visibility API events that say the page has been hidden, waits a moment so a passing system sheet does not count, then ends the unlock; the next tap shows the cover again. An unlock also expires after 15 minutes.

The step-by-step version is Set up PWA Lock on your iPhone: the complete guide. The gate is at the locked address only; the original website stays reachable at its own address for anyone who knows it and has its login.