Behaviour · Measured 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100) · A, Instrumented read · No documented source
When a Home Screen web app is swiped away in the App Switcher on iOS 18.6.2, does its page end at once, and does a service worker that handles a notification tap seconds later still find a window to focus with clients.matchAll()?
The page survived about 6 s after the swipe, and the notification tap focused it. This happened on an iPhone 16 Pro running iOS 18.6.2 (22G100) on 2026-10-20.
The question came up inside the notificationclick test (T8). The lab’s service worker handles a tap by calling clients.matchAll({type: "window", includeUncontrolled: true}), then focuses a window it finds or calls clients.openWindow() when it finds none, and writes a record with the number of windows found and the outcome (“focused existing window” or “opened new window”) to IndexedDB. To reach the openWindow() path the operator tried to remove the window first by swiping the app away.
We identified the page from instrumented reads of the document: performance.timeOrigin, the navigation type and history.length. The inspector’s page list gave the process hosting the page. Three cases were read:
- In the deciding case, N40, the operator tapped 2b. Show in 5 s (then go Home) in PWA Lab, swiped the app away in the App Switcher at once, and tapped the banner when it appeared.
- In N38, the operator swiped PWA Lab away, relaunched it from its icon, then tapped 2b, went Home, and tapped the banner.
- In N16, the operator swiped the demo app away and relaunched it from its icon.
- Add
https://openpwa.net/lab/device-tests/ to the Home Screen from Safari and open PWA Lab from its icon.
- In the T7 and T8 section tap 1. Request permission and allow notifications.
- With Web Inspector, note
performance.timeOrigin of the page (Mac Safari → Develop → your iPhone → PWA Lab).
- Tap 2b. Show in 5 s (then go Home). Open the App Switcher at once and swipe PWA Lab away.
- When the banner appears, tap it. The app comes to the front.
- Read the newest entries in Notification event log: the listener’s record names the outcome (“focused existing window” or “opened new window”) and the number of windows found.
- Read
performance.timeOrigin again. The same value as in step 3 means the same document survived the swipe.
- For a longer interval, wait a set time between steps 4 and 5 and record it; this run did not do so.
- T8 notificationclick: exposure, handlers and a notification tap (5 min)
Harness v1: Open the test
On iOS 18.6.2 swiping the app away did not end its page within seconds. In N40 the notification was created at 08:43:03.022 UTC and tapped at 08:43:09; the worker’s listener found one window (windowsFound 1) and recorded “focused existing window” at 08:43:09.236Z, and the property handler recorded the tap at 08:43:09.245Z. The document read afterwards had the timeOrigin of the page loaded at the N38 relaunch (08:28:30.036Z against 08:28:29.978Z, within the rounding of timeOrigin across reads, history.length 1 in both), so the same document was still alive about 6 s later (A, N40). After a swipe-away followed by a launch from the icon, the page was loaded again: a new document with navigation type navigate and history.length 1 in PWA Lab (A, N38) and in the demo app (A, N16). The web-app process id, PID:24500, was the same before and after each swipe. The confidence label is A.
2026-10-20, iOS 18.6.2
The PWA Lab app was swiped away in the app switcher about 6 s before a notification tap, yet the document from its previous launch was still alive and clients.matchAll() found it. In an earlier swipe-away of the demo app the web-app process id survived while the page reloaded on relaunch. The test assumed a swipe-away leaves no window.
- Date
- 2026-10-20
- Device
- iPhone 16 Pro
- OS and build
- iOS 18.6.2 (22G100), release
- Context
- Home Screen app
- Result
- Differs from the expectation
- Key values
documentAliveAfterSwipeAwayS: 6clientsMatchAllWindows: 1processIdSurvivedSwipeAway: true
- Confidence
- A, Instrumented read
- Tests
- T8
- Notebook entries
- N16, N38, N40
- Study
- Read the study · Data package
- Harness
- Harness v1
Harness v1 files used (2), served SHA-256
/lab/device-tests/ 42c90845419f5ed3ad15d941bea04f649f4c5d350b1847292292fadd55871486/lab/device-tests/sw.js 0e7e6f34cb814d808edba644d664bac0f4337cc59a88dbb509d25a8e11fffc30
The process id says little on its own: PID:24500 hosted PWA Lab, the demo, Lab no-ATI and a page of another site at the same time (N18, N21, anomaly A3), so the process outliving one app’s swipe is expected. Because a window was alive at every tap, the clients.openWindow() path of notificationclick could not be reached by this method (could-not-run).
The Service Worker specification defines clients.matchAll() as returning the window clients that exist when it runs, and clients.openWindow() as opening a new top-level browsing context (Service Workers, matchAll() and openWindow(), w3.org). Neither it nor Apple’s or WebKit’s documentation states how long a Home Screen web app’s page stays alive after the user swipes it away.
WebKit bug 268797, “notificationclick events in serviceworkers not firing”, has status NEW and carries reports of the event not firing when the user taps a notification while no page of the app is alive (Bug 268797, bugs.webkit.org). This run fired notificationclick on every tap, but each time a page was still alive, so it neither confirms nor contradicts those reports.
No layer-1 source documents the lifetime itself, so the run has no source to agree or differ with. On iOS 18.6.2, swiping the app away does not reliably produce the “no window alive” state within seconds. To test that state, confirm with a read that no page exists before the tap, for example after a device restart. The study does not count this as a new finding; it is a method result recorded in REPORT §7.8. The worker side is described in Clients API and Web Push on iOS and iPadOS (16.4+).
From the iOS 18.6.2 data package (CC BY 4.0):
Notebook entries N16, N38, N39 and N40 are in 2026-10-ios18-baseline.md, and the T8 section of REPORT.md lists all six taps. Rows: /lab/results.json. Cite as “OpenPWA device test, 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100), N40”.
The result supports the service worker lifecycle and notificationclick statements that depend on whether an installed app’s window is still alive after a swipe-away.
- One deciding case (N40). The moment of the swipe was not timestamped; the interval rests on the notification’s creation and tap times and the notebook’s “about 6 s”.
- Longer intervals, a device restart, memory pressure and Low Power Mode were not tested, so the run does not show when iOS does end the page.
- In N16 and N38 the time between the swipe and the relaunch was not recorded, so the reload there is not compared with N40’s interval.
- The
clients.openWindow() path and notificationclose were not reached.
- 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.