Behaviour · Measured 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100) · A, Instrumented read · Agrees with WebKit
When a site is added to the iOS 18.6.2 Home Screen, which of Safari’s localStorage, IndexedDB and cookie values reach the new web app, when does that copy happen, and does any later write cross between Safari and the app, or between two Home Screen apps of the same site, in either direction?
On 2026-10-20, the cookie copied once and then stayed separate in each app on an iPhone 16 Pro running iOS 18.6.2 (22G100). Neither localStorage nor IndexedDB copied into the lab apps.
We wrote two markers in Safari before installing any apps:
- For the demo marker, the language toggle on
/demo/ stores openpwa-demo-lang in localStorage. The Safari tab was set to zh (N08).
- For the lab marker, Write marker here on
/lab/device-tests/ writes one value, starting TAB- in Safari or APP- in an app and followed by the UTC time, to three stores at once: localStorage, IndexedDB and the cookie openpwa_lab_marker, set by document.cookie with path=/lab/device-tests/; max-age=31536000; SameSite=Lax; Secure. Safari wrote TAB-2026-10-20T07:13:46Z (N09).
Three Home Screen apps were then added from Safari between about 07:16 and 07:20 UTC. These were the demo (/demo/), PWA Lab (/lab/device-tests/, with a service worker) and Lab no-ATI (/lab/device-tests/t3/manifest-only/, its own manifest and scope, no service worker, inside the cookie’s path). An agent read the markers over USB in each context after each step. Most steps were set up so that sharing and isolation predict different values; one demo step could not tell them apart (N14) and was followed by checks that could (N16, N17). The two hypotheses for the cookie (copied once, or one shared live jar) were written into the notebook before the deciding read (N18).
To time the cookie copy, Lab no-ATI was left unlaunched while Safari wrote a new value, and the app was launched for the first time 7 s later (N21, N22).
Remove earlier PWA Lab, Lab no-ATI and OpenPWA icons to start fresh. Keep Safari’s website data throughout the test.
- In Safari, open
https://openpwa.net/lab/device-tests/#t6 and tap Write marker here. Note the TAB-… value.
- Share → Add to Home Screen → Add (PWA Lab). Also add
https://openpwa.net/lab/device-tests/t3/manifest-only/ (Lab no-ATI), and do not open it yet.
- Open PWA Lab from its icon and read the T6 marker panel.
null in a store means nothing was copied into it; TAB-… means Safari’s value is there.
- In the app, tap Write marker here (
APP-…). Switch to Safari and reload the lab page. If Safari still shows TAB-… in all three stores, the app’s write did not reach Safari.
- In Safari tap Write marker here again (a new
TAB-…). Wait at least two minutes, then open Lab no-ATI for the first time. The old TAB-… value points to a copy at Add to Home Screen; the new one points to a copy at first launch.
- Compare Lab no-ATI’s cookie with PWA Lab’s
APP-… value to see whether two apps of the same site share a cookie store.
- With Web Inspector, the marker can also be read in the console of each context with
document.cookie and localStorage.getItem('openpwa-lab-marker').
On iOS 18.6.2 localStorage and IndexedDB were not copied into either lab app and stayed separate in both directions, while the cookie was copied from Safari into each app once and was independent afterwards (A, N18 to N22):
| Time (UTC) |
Context |
localStorage |
IndexedDB |
cookie |
Notebook |
| 07:13:46 |
Safari writes |
TAB-07:13:46Z |
TAB-07:13:46Z |
TAB-07:13:46Z |
N09 |
| about 07:16 |
PWA Lab and Lab no-ATI added |
|
|
|
N11 |
| 07:34:15 |
PWA Lab, first read after launch |
null |
null |
TAB-07:13:46Z |
N18 |
| 07:37:40 |
PWA Lab writes |
APP-07:37:40Z |
APP-07:37:40Z |
APP-07:37:40Z |
N20 |
| 07:38:18 |
Safari reload |
TAB-07:13:46Z |
TAB-07:13:46Z |
TAB-07:13:46Z |
N19 |
| 07:45:25 |
Safari writes |
TAB-07:45:25Z |
TAB-07:45:25Z |
TAB-07:45:25Z |
N22 |
| 07:45:32.575 |
Lab no-ATI, first launch |
null |
null |
TAB-07:13:46Z |
N21 |
Each Home Screen app had its own cookie store. Lab no-ATI did not see PWA Lab’s APP-… cookie, although the cookie path covered both and both ran in the same web-app process (A, N21). Lab no-ATI received the value Safari held when it was added. It did not receive the value Safari wrote 7 s before its first launch. This is consistent with a copy at Add to Home Screen; the timing is rated moderate. The demo marker agrees. The demo app started in English with empty localStorage and no cookies (A, N13), a later language change in Safari did not reach it (N16) and the app’s own later write did not reach Safari (N17); in N16 and N17 the reading side is instrumented (A) and the other side rests on the operator’s report (O). Service worker registrations did not cross either. The demo app listed only a /demo/ registration and not Safari’s lab registration (A, N13), and PWA Lab did not list the demo app’s registration although both apps ran in the same process (A, N18). The confidence label is A.
2026-10-20, iOS 18.6.2
localStorage and IndexedDB were not copied from Safari into the Home Screen apps and stayed separate in both directions. A first-party cookie was copied into each app once and was independent afterwards; each app had its own cookie store. The copy time is consistent with copy at Add to Home Screen, with moderate strength (7 s gap). The pre-registered expectation was no copy at all, so the result is recorded as differs; it matches WebKit's Safari 17.2 post.
- Date
- 2026-10-20
- Device
- iPhone 16 Pro
- OS and build
- iOS 18.6.2 (22G100), release
- Context
- Safari tab and Home Screen app
- Result
- Differs from the expectation
- Key values
localStorageCopied: falseindexedDbCopied: falsecookieCopiedOnce: truecookieCopyTiming: consistent with copy at Add to Home Screen (moderate)cookieIndependentAfterCopy: truecookieStorePerApp: true
- Confidence
- A, Instrumented read
- Tests
- T6
- Notebook entries
- N13, N18, N19, N20, N21, N22
- Study
- Read the study · Data package
- Harness
- Harness v1
Harness v1 files used (4), served SHA-256
/lab/device-tests/ 42c90845419f5ed3ad15d941bea04f649f4c5d350b1847292292fadd55871486/lab/device-tests/manifest.webmanifest cab4e60719fd1f9c84d04aada2ad6cd937f50615ce646c3ed20f14f0ca09832b/lab/device-tests/t3/manifest-only/ 1fe7e2a1d4aeb86fdf69b0f4546e28237dab65c53f2dc29a72148b99f1ec3920/lab/device-tests/t3/manifest-only/manifest.webmanifest b036cb4f6aca01703f5e4ad9ae009d623d8072378c7db3ebeb3132746d3e4f15
WebKit’s tracking-prevention page says that “the website data of home screen web applications is kept isolated from Safari” (Tracking Prevention in WebKit, webkit.org), and WebKit bug 181849 treats the separation as intended (Bug 181849, bugs.webkit.org). The Safari 17.2 post refines that for cookies on iOS 17.2. When a user taps “Add to Home Screen” and creates a web app, “the cookies are copied over, including the information about login state”, “No other kind of local storage is copied over”, and “After a user adds a web app to the Home Screen or Dock, no other website data is shared” (WebKit Features in Safari 17.2, webkit.org). Firtman’s notes list “Login cookies copied to the installed app” from 17.2 and storage as not shared with the browser (iOS PWA Compatibility, firt.dev).
The result agrees with WebKit’s Safari 17.2 description and replicates it on 18.6.2 with timestamps. Read alone, the tracking-prevention sentence omits the one-time cookie copy, so the two WebKit sources belong together. This run checked one kind of cookie and adds two measured details. Lab no-ATI received the value Safari held when it was added; the value Safari wrote 7 s before its first launch did not reach it (moderate, N22: a first-launch copy of a cookie store not yet written to disk is not excluded), and two apps of the same site do not share a cookie store, which the posts do not spell out. The study’s prior-art check classifies this result as a confirmation and finds no novelty. The isolation model for developers is described in Home Screen web app storage isolation on iOS.
From the iOS 18.6.2 data package (CC BY 4.0); reads from step 11 on also have a .meta.json sidecar (UTC time, tool hashes, selected page):
Notebook entries N08 to N22: 2026-10-ios18-baseline.md. Rows: /lab/results.json. Cite as “OpenPWA device test, 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100), N21”.
The result supports the cookie-copy and isolation statements for installed web apps on iOS.
Reference entries
Related issues and bugs
- One cookie type: first-party, set by
document.cookie, Secure, SameSite=Lax, with a path. Not tested: HttpOnly and other server-set cookies, SameSite=None, session cookies, partitioned cookies.
- Not tested: CacheStorage, the origin private file system, and adding from SFSafariViewController or another browser, which the 17.2 post also covers.
- Copy timing is moderate: with only 7 s between Safari’s write and the first launch, a copy at first launch from a Safari cookie store not yet written to disk remains possible. The stronger retest (add, write a new value in Safari, wait at least two minutes, then launch) is proposed in N22 and was not run.
- For the demo marker, one side of N16 and N17 rests on the operator’s report.
- The phone was not wiped. Automated WebDriver sessions, which get an empty store of their own, were not used for any storage step.
- One iPhone 16 Pro, one build, one operator; iOS 26 and later were not tested here.
Device steps performed by an OpenPWA operator on an iPhone 16 Pro. AI agent sessions read page state over USB, kept the notebook and drafted this text; automated gates and an AI fact-check checked it. No person reviews each entry.