# Page lifetime after a swipe-away on iOS 18
> On iOS 18.6.2 a Home Screen app's page was still alive about 6 s after a swipe-away in the App Switcher, so a notification tap focused that page.
import LabEvidenceLine from '@components/lab/LabEvidenceLine.astro';
import LabHarnessLinks from '@components/lab/LabHarnessLinks.astro';
import LabResults from '@components/lab/LabResults.astro';
import LabBacks from '@components/lab/LabBacks.astro';
import LabProvenance from '@components/lab/LabProvenance.astro';
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.
## Document identity across swipes
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.
## How to run
1. Add `https://openpwa.net/lab/device-tests/` to the Home Screen from Safari and open PWA Lab from its icon.
2. In the T7 and T8 section tap **1. Request permission** and allow notifications.
3. With Web Inspector, note `performance.timeOrigin` of the page (Mac Safari โ **Develop** โ your iPhone โ PWA Lab).
4. Tap **2b. Show in 5 s (then go Home)**. Open the App Switcher at once and swipe PWA Lab away.
5. When the banner appears, tap it. The app comes to the front.
6. 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.
7. Read `performance.timeOrigin` again. The same value as in step 3 means the same document survived the swipe.
8. For a longer interval, wait a set time between steps 4 and 5 and record it; this run did not do so.
## Results
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.
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).
## Window clients and the no-page bug report
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()`](https://w3c.github.io/ServiceWorker/#clients-matchall) and [`openWindow()`](https://w3c.github.io/ServiceWorker/#clients-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](https://bugs.webkit.org/show_bug.cgi?id=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](/reference/service-worker/clients-api/) and [Web Push on iOS and iPadOS (16.4+)](/reference/notifications/ios-safari-push/).
## Data
From the [iOS 18.6.2 data package](/research/2026-10-ios18-home-screen-web-apps/data/) (CC BY 4.0):
- [`raw/2026-10-20-ios18.6.2-step24b-app-lab-events.json`](/research/2026-10-ios18-home-screen-web-apps/data/raw/2026-10-20-ios18.6.2-step24b-app-lab-events.json) and its `.meta.json`: the N40 read (records 11 and 12, document identity).
- [`raw/2026-10-20-ios18.6.2-step24-app-lab-events.json`](/research/2026-10-ios18-home-screen-web-apps/data/raw/2026-10-20-ios18.6.2-step24-app-lab-events.json): the N38 relaunch (records 9 and 10).
- [`raw/2026-10-20-ios18.6.2-step11-app-demo-timing.json`](/research/2026-10-ios18-home-screen-web-apps/data/raw/2026-10-20-ios18.6.2-step11-app-demo-timing.json): the demo relaunch after a swipe (N16).
Notebook entries N16, N38, N39 and N40 are in [`2026-10-ios18-baseline.md`](/research/2026-10-ios18-home-screen-web-apps/data/2026-10-ios18-baseline.md), and the T8 section of [`REPORT.md`](/research/2026-10-ios18-home-screen-web-apps/data/REPORT.md) lists all six taps. Rows: [`/lab/results.json`](/lab/results.json). Cite as "OpenPWA device test, 2026-10-20, iPhone 16 Pro, iOS 18.6.2 (22G100), N40".
## Related reference entries
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.
## Limits
- 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.