@mmerterden/multi-agent-pipeline 20.6.0 → 20.8.0

package/pipeline/skills/shared/external/swiftui-webkit/SKILL.md

@@ -1,275 +1,229 @@
 ---
 name: swiftui-webkit
-description: "Embeds and controls web content in SwiftUI with WebKit for SwiftUI, including WebView, WebPage, navigation policies, JavaScript execution, observable page state, link interception, local HTML or data loading, and custom URL schemes. Use when building iOS 26+ article/detail views, help centers, in-app documentation, or other embedded web experiences backed by HTML, CSS, and JavaScript."
+description: "Web content in SwiftUI with WebKit for SwiftUI: WebView, WebPage, observable page state, navigation policies, link interception, JavaScript calls, local HTML or data, custom URL schemes. Use when an iOS 26+ screen shows articles, detail pages, help centers, in-app docs or other embedded HTML, CSS and JavaScript, or when replacing a WKWebView wrapper. Not for OAuth or deep-link routing."
 metadata:
-  source: "dpearson2699/swift-ios-skills (PolyForm Perimeter 1.0.0)"
+  source: multi-agent-pipeline
 ---
 
-# SwiftUI WebKit
+# WebKit for SwiftUI
 
-Embed and manage web content in SwiftUI using the native WebKit-for-SwiftUI APIs introduced for iOS 26, iPadOS 26, macOS 26, and visionOS 26. Use this skill when the app needs an integrated web surface, app-owned HTML content, JavaScript-backed page interaction, or custom navigation policy control.
+Starting with the 26 releases (iOS, iPadOS, macOS, visionOS), WebKit ships a SwiftUI
+surface of its own: `WebView` draws web content and `WebPage` is the
+observable model behind it. Everything below needs `import WebKit` and those
+OS versions.
 
-## Contents
+## Picking the container
 
-- [Choose the Right Web Container](#choose-the-right-web-container)
-- [Displaying Web Content](#displaying-web-content)
-- [Loading and Observing with WebPage](#loading-and-observing-with-webpage)
-- [Navigation Policies](#navigation-policies)
-- [JavaScript Integration](#javascript-integration)
-- [Local Content and Custom URL Schemes](#local-content-and-custom-url-schemes)
-- [WebView Customization](#webview-customization)
-- [Common Mistakes](#common-mistakes)
-- [Review Checklist](#review-checklist)
-- [References](#references)
-
-## Choose the Right Web Container
-
-Use the narrowest tool that matches the job.
-
-| Need | Default choice |
+| Situation | Use |
 |---|---|
-| Embedded app-owned web content in SwiftUI | `WebView` + `WebPage` |
-| Simple external site presentation with Safari behavior | `SFSafariViewController` |
-| OAuth or third-party sign-in | `ASWebAuthenticationSession` |
-| Back-deploy below iOS 26 or use missing legacy-only WebKit features | `WKWebView` fallback |
+| Web content that belongs to the app, shown inside a SwiftUI screen | `WebView` with a `WebPage` |
+| Sending the user to an outside site with Safari behaviour | `SFSafariViewController` |
+| OAuth or any third-party sign-in | `ASWebAuthenticationSession` |
+| Deployment target below iOS 26, or a capability only the old API has | a `WKWebView` fallback |
 
-Prefer `WebView` and `WebPage` for modern SwiftUI apps targeting iOS 26+. Apple's WWDC25 guidance explicitly recommends migrating SwiftUI apps away from UIKit/AppKit WebKit wrappers when possible.
+Apple's WWDC25 WebKit guidance points SwiftUI apps away from UIKit and AppKit
+web view wrappers wherever the new API covers the need. Sign-in never runs in
+an embedded web view.
 
-Do not use embedded web views for OAuth. That stays an `ASWebAuthenticationSession` flow.
+## Showing a page
 
-## Displaying Web Content
-
-Use the simple `WebView(url:)` form when the app only needs to render a URL and SwiftUI state drives navigation.
+The shortest path renders a URL and lets SwiftUI state decide which one:
 
 ```swift
 import SwiftUI
 import WebKit
 
-struct ArticleView: View {
-    let url: URL
+struct ReleaseNotesView: View {
+    let address: URL
 
     var body: some View {
-        WebView(url: url)
+        WebView(url: address)
     }
 }
 ```
 
-Create a `WebPage` when the app needs to load requests directly, observe state, call JavaScript, or customize navigation behavior.
+As soon as you need to issue requests yourself, watch state, run
+JavaScript or steer navigation, own a `WebPage` and pass it to
+`WebView(page)`. Deciding this up front is cheaper than retrofitting it.
 
 ```swift
 @Observable
 @MainActor
-final class ArticleModel {
+final class GuideModel {
     let page = WebPage()
 
-    func load(_ url: URL) async throws {
-        for try await _ in page.load(URLRequest(url: url)) {
-        }
+    func open(_ address: URL) async throws {
+        let events = page.load(URLRequest(url: address))
+        for try await _ in events { }
     }
 }
 
-struct ArticleDetailView: View {
-    @State private var model = ArticleModel()
-    let url: URL
+struct GuideScreen: View {
+    @State private var model = GuideModel()
+    let start: URL
 
     var body: some View {
         WebView(model.page)
-            .task {
-                try? await model.load(url)
-            }
+            .task { try? await model.open(start) }
     }
 }
 ```
 
-See [references/loading-and-observation.md](references/loading-and-observation.md) for full examples.
-
-## Loading and Observing with WebPage
+## Loading and observing
 
-`WebPage` is an `@MainActor` observable type. Use it when you need page state in SwiftUI.
+`WebPage` is an observable class isolated to the main actor. Its load
+methods:
 
-Common loading entry points:
-- `load(URLRequest)`
-- `load(URL)`
-- `load(html:baseURL:)`
-- `load(_:mimeType:characterEncoding:baseURL:)`
+- `load(_ request: URLRequest)` and `load(_ url: URL?)`
+- `load(html:baseURL:)` for a string of markup
+- `load(_:mimeType:characterEncoding:baseURL:)` for raw `Data`; the encoding
+  is a `String.Encoding` such as `.utf8`
 
-Common observable properties:
-- `title`
-- `url`
-- `isLoading`
-- `estimatedProgress`
-- `currentNavigationEvent`
-- `backForwardList`
+Each returns an async sequence of navigation events that throws when the
+navigation fails. Observable properties include `title` (a non-optional
+`String`), `url`, `isLoading`, `estimatedProgress`, `backForwardList`,
+`hasOnlySecureContent` and, from the SwiftUI overlay, `themeColor`.
 
 ```swift
-struct ReaderView: View {
+struct ArticleReader: View {
     @State private var page = WebPage()
+    let story: URL
 
     var body: some View {
         WebView(page)
-            .navigationTitle(page.title ?? "Loading")
-            .overlay {
+            .navigationTitle(page.title.isEmpty ? "Article" : page.title)
+            .overlay(alignment: .top) {
                 if page.isLoading {
                     ProgressView(value: page.estimatedProgress)
                 }
             }
             .task {
                 do {
-                    for try await _ in page.load(URLRequest(url: URL(string: "https://example.com")!)) {
-                    }
+                    let events = page.load(story)
+                    for try await _ in events { }
                 } catch {
-                    // Handle load failure.
+                    // show an inline error state
                 }
             }
     }
 }
 ```
 
-When you need to react to every navigation, observe the navigation sequence rather than only checking a single property.
-
-```swift
-Task {
-    for await event in page.navigations {
-        // Handle finish, redirect, or failure events.
-    }
-}
-```
-
-See [references/loading-and-observation.md](references/loading-and-observation.md) for stronger patterns and the load-sequence examples.
+To react to every navigation rather than sampling one property, iterate
+`page.navigations` with `for try await`. The released SDK has no
+`currentNavigationEvent` property; the event sequences are the way to follow
+progress. Details are in [page loading notes](references/loading-and-observation.md).
 
-## Navigation Policies
+## Navigation policy
 
-Use `WebPage.NavigationDeciding` to allow, cancel, or customize navigations based on the request or response.
+A type conforming to `WebPage.NavigationDeciding` can permit, cancel or adjust
+navigations by request or by response. Typical jobs:
 
-Typical uses:
-- keep app-owned domains inside the embedded web view
-- cancel external domains and hand them off with `openURL`
-- intercept special callback URLs
-- tune `NavigationPreferences`
+- keep the app's own domains inside the web view,
+- cancel links to other domains and hand them to `openURL`,
+- catch callback URLs,
+- adjust `WebPage.NavigationPreferences` for a request.
 
 ```swift
 @MainActor
-final class ArticleNavigationDecider: WebPage.NavigationDeciding {
-    var urlToOpenExternally: URL?
-
-    func decidePolicy(
-        for action: WebPage.NavigationAction,
-        preferences: inout WebPage.NavigationPreferences
-    ) async -> WKNavigationActionPolicy {
-        guard let url = action.request.url else { return .allow }
-
-        if url.host == "example.com" {
-            return .allow
-        }
-
-        urlToOpenExternally = url
+final class DomainGate: WebPage.NavigationDeciding {
+    var leaving: URL?
+
+    func decidePolicy(for step: WebPage.NavigationAction,
+                      preferences prefs: inout WebPage.NavigationPreferences)
+        async -> WKNavigationActionPolicy {
+        guard let target = step.request.url, let host = target.host() else { return .allow }
+        if host.hasSuffix("docs.example.org") { return .allow }
+        leaving = target        // opened outside the app by the view
         return .cancel
     }
 }
 ```
 
-Keep app-level deep-link routing in the navigation skill. This skill owns navigation that happens inside embedded web content.
-
-See [references/navigation-and-javascript.md](references/navigation-and-javascript.md) for complete patterns.
-
-## JavaScript Integration
+This skill covers navigation inside web content. Routing the app itself from
+a deep link belongs to the `swiftui-navigation` skill.
 
-Use `callJavaScript(_:arguments:in:contentWorld:)` to evaluate JavaScript functions against the page.
+## JavaScript
 
-```swift
-let script = """
-const headings = [...document.querySelectorAll('h1, h2')];
-return headings.map(node => ({
-    id: node.id,
-    text: node.textContent?.trim()
-}));
-"""
-
-let result = try await page.callJavaScript(script)
-let headings = result as? [[String: Any]] ?? []
-```
-
-You can pass values through the `arguments` dictionary and cast the returned `Any` into the Swift type you actually need.
+`callJavaScript(_:arguments:in:contentWorld:)` runs the string as the body of
+an async JavaScript function, so the script uses `return`. The result comes
+back as `Any?`; cast it to the Swift shape you expect straight away, and pass
+values through `arguments` rather than building them into the script text.
 
 ```swift
-let result = try await page.callJavaScript(
-    "return document.getElementById(sectionID)?.getBoundingClientRect().top ?? null;",
-    arguments: ["sectionID": selectedSectionID]
+let raw = try await page.callJavaScript(
+    "return [...document.querySelectorAll(selector)].map(n => ({ id: n.id, text: n.textContent }))",
+    arguments: ["selector": "h2"]
 )
+let headings = raw as? [[String: Any]] ?? []
 ```
 
-Important boundary: the native SwiftUI WebKit API clearly supports Swift-to-JavaScript calls, but it does not expose an obvious direct replacement for `WKScriptMessageHandler`. If you need coarse JS-to-native signaling, a custom navigation or callback-URL pattern can work, but document it as a workaround pattern, not a guaranteed one-to-one replacement.
+`callJavaScript` is not a message channel from the page to the app. For
+simple one-off signals, the page can navigate to a custom callback URL that
+the navigation decider intercepts; that is a workaround, not a full
+replacement for `WKScriptMessageHandler`. `WebPage.Configuration` does expose
+a `userContentController` (a `WKUserContentController`) for apps that need
+structured script messages. See
+[policy and script notes](references/navigation-and-javascript.md).
 
-See [references/navigation-and-javascript.md](references/navigation-and-javascript.md).
+## Local content and custom schemes
 
-## Local Content and Custom URL Schemes
-
-Use `WebPage.Configuration` and `URLSchemeHandler` when the app needs bundled HTML, offline documents, or app-provided resources under a custom scheme.
+For bundled HTML, offline documentation or resources the app generates,
+register a `URLSchemeHandler` on a `WebPage.Configuration`:
 
 ```swift
-var configuration = WebPage.Configuration()
-configuration.urlSchemeHandlers[URLScheme("docs")!] = DocsSchemeHandler(bundle: .main)
-
-let page = WebPage(configuration: configuration)
-for try await _ in page.load(URL(string: "docs://article/welcome")!) {
+var setup = WebPage.Configuration()
+if let scheme = URLScheme("manual") {
+    setup.urlSchemeHandlers[scheme] = ManualFiles()
 }
-
+let page = WebPage(configuration: setup)
+// later: page.load(URL(string: "manual://getting-started"))
 ```
 
-Use this for:
-- bundled documentation or article content
-- offline HTML/CSS/JS assets
-- app-owned resource loading under a custom scheme
-
-Do not overuse custom schemes for normal remote content. Prefer standard HTTPS for server-hosted pages.
-
-See [references/local-content-and-custom-schemes.md](references/local-content-and-custom-schemes.md).
-
-## WebView Customization
-
-Use WebView modifiers to match the intended browsing experience.
-
-Useful modifiers and related APIs:
-- `webViewBackForwardNavigationGestures(_:)`
-- `findNavigator(isPresented:)`
-- `webViewScrollPosition(_:)`
-- `webViewOnScrollGeometryChange(...)`
-
-Apply them only when the user experience needs them.
-
-- Enable back/forward gestures when people are likely to visit multiple pages.
-- Add Find in Page when the content is document-like.
-- Sync scroll position only when the app has a sidebar, table of contents, or other explicit navigation affordance.
-
-Apple's HIG also applies here: support back/forward navigation when appropriate, but do not turn an app web view into a general-purpose browser.
-
-## Common Mistakes
-
-- Using `WKWebView` wrappers by default in an iOS 26+ SwiftUI app instead of starting with `WebView` and `WebPage`
-- Using embedded web views for OAuth instead of `ASWebAuthenticationSession`
-- Reaching for `WebPage` only after building a plain `WebView(url:)` path that now needs state, JS, or navigation control
-- Treating `callJavaScript` as a direct replacement for `WKScriptMessageHandler`
-- Keeping all links inside the app when external domains should open outside the embedded surface
-- Building a browser-style app shell around WebView instead of a focused embedded experience
-- Using custom URL schemes for content that should just load over HTTPS
-- Forgetting that `WebPage` is main-actor-isolated
-
-## Review Checklist
-
-- [ ] `WebView` and `WebPage` are the default path for iOS 26+ SwiftUI web content
-- [ ] `ASWebAuthenticationSession` is used for auth flows instead of embedded web views
-- [ ] `WebPage` is used whenever the app needs state observation, JS calls, or policy control
-- [ ] Navigation policies only intercept the URLs the app actually owns or needs to reroute
-- [ ] External domains open externally when appropriate
-- [ ] JavaScript return values are cast defensively to concrete Swift types
-- [ ] Custom URL schemes are used only for real app-owned resources
-- [ ] Back/forward gestures or controls are enabled when multi-page browsing is expected
-- [ ] The web experience adds focused native value instead of behaving like a thin browser shell
-- [ ] Fallback to `WKWebView` is justified by deployment target or missing API needs
+Ordinary remote content should come over HTTPS, not through a custom scheme.
+Handler implementation and cancellation are covered in
+[scheme handler notes](references/local-content-and-custom-schemes.md).
+
+## View modifiers
+
+- `webViewBackForwardNavigationGestures(_:)`: turn on swipe back and forward
+  when people will visit several pages.
+- `findNavigator(isPresented:)`: Find in Page for long, document-like content.
+- `webViewScrollPosition(_:)` and `webViewOnScrollGeometryChange(for:of:action:)`:
+  sync scrolling only when there is a sidebar, a table of contents or another
+  explicit navigation control.
+
+The HIG asks for back and forward support where it helps, but an app's web
+view should not grow into a general-purpose browser.
+
+## Common mistakes
+
+- Reaching for a `WKWebView` wrapper in a SwiftUI app that targets iOS 26+.
+- Running OAuth inside an embedded web view.
+- Starting with `WebView(url:)` and bolting on `WebPage` later once state,
+  JavaScript or navigation control turns out to be needed.
+- Treating `callJavaScript` as if it were `WKScriptMessageHandler`.
+- Keeping every link in the app when other domains should open outside it.
+- Building a browser shell (address bar, tabs) around the web view.
+- Using a custom scheme for content that should load over HTTPS.
+- Touching a `WebPage` off the main actor; the type is `@MainActor`.
+
+## Review checklist
+
+- [ ] iOS 26+ screens start from `WebView` plus `WebPage`
+- [ ] Sign-in goes through `ASWebAuthenticationSession`
+- [ ] A `WebPage` exists wherever state, JavaScript or policy control is needed
+- [ ] The navigation decider only intercepts URLs the app owns or reroutes
+- [ ] Other domains open outside the app where that is the better experience
+- [ ] JavaScript results are cast defensively
+- [ ] Custom schemes serve only genuine app-owned resources
+- [ ] Multi-page browsing has back and forward gestures or controls
+- [ ] The screen offers something native and specific, not a wrapped website
+- [ ] Each remaining `WKWebView` has a reason: an older deployment target or a missing API
 
 ## References
 
-- Loading and observation: [references/loading-and-observation.md](references/loading-and-observation.md)
-- Navigation and JavaScript: [references/navigation-and-javascript.md](references/navigation-and-javascript.md)
-- Local content and custom schemes: [references/local-content-and-custom-schemes.md](references/local-content-and-custom-schemes.md)
-- Migration and fallbacks: [references/migration-and-fallbacks.md](references/migration-and-fallbacks.md)
+- [page loading notes](references/loading-and-observation.md): URL-only views, controlled loading, progress and title, navigation events, ephemeral pages, user agents
+- [policy and script notes](references/navigation-and-javascript.md): deciders, external links, calling JavaScript, arguments, page-to-app signals
+- [scheme handler notes](references/local-content-and-custom-schemes.md): scheme handlers, responses, bundled files, cancellation
+- [migration notes](references/migration-and-fallbacks.md): moving off `WKWebView` wrappers, Safari and sign-in boundaries, testing

package/pipeline/skills/shared/external/swiftui-webkit/references/loading-and-observation.md

@@ -1,151 +1,140 @@
-# Loading and Observation
+# Loading and observing pages
 
-## Contents
-- Simple `WebView(url:)`
-- Controlled `WebPage` loading
-- Observing progress and title
-- Observing navigation events
-- Ephemeral pages and custom user agents
+Part of the `swiftui-webkit` skill ([../SKILL.md](../SKILL.md)). All code
+needs iOS 26, iPadOS 26, macOS 26 or visionOS 26 and `import WebKit`.
 
-## Simple `WebView(url:)`
+## The URL-only view
 
-Use `WebView(url:)` when the app only needs to display a URL and does not need explicit page control.
+When all you need is to show a page and let people move back and forth,
+`WebView(url:)` plus the gesture modifier is the least code:
 
 ```swift
-import SwiftUI
-import WebKit
-
-struct MarketingPageView: View {
-    let url: URL
+struct PolicyPage: View {
+    let link: URL
 
     var body: some View {
-        WebView(url: url)
+        WebView(url: link)
             .webViewBackForwardNavigationGestures(.enabled)
     }
 }
 ```
 
-This is the lowest-friction path for embedded content.
-
-## Controlled `WebPage` loading
+## Loading through a WebPage
 
-Create a `WebPage` when the app needs to drive loading itself.
+A model that owns the page can keep the last failure for the UI:
 
 ```swift
 @Observable
 @MainActor
-final class ArticleModel {
+final class HelpCenterModel {
     let page = WebPage()
-    var lastError: String?
+    var failure: Error?
 
-    func load(_ url: URL) async {
+    func show(_ address: URL) async {
+        failure = nil
         do {
-            for try await _ in page.load(URLRequest(url: url)) {
-            }
+            for try await _ in page.load(URLRequest(url: address)) { }
         } catch {
-            lastError = error.localizedDescription
+            failure = error
         }
     }
 }
 ```
 
-```swift
-struct ArticleDetailView: View {
-    @State private var model = ArticleModel()
-    let url: URL
+The other load entry points return the same kind of event sequence:
 
-    var body: some View {
-        WebView(model.page)
-            .task {
-                await model.load(url)
-            }
-    }
-}
+```swift
+_ = page.load(address)
+_ = page.load(html: "<h1>Offline</h1><p>Try again later.</p>")   // baseURL defaults to about:blank
+_ = page.load(markupData,
+              mimeType: "text/html",
+              characterEncoding: .utf8,
+              baseURL: bundleFolder)
 ```
 
-You can also load:
-- `for try await _ in page.load(url) { }`
-- `for try await _ in page.load(html: htmlString, baseURL: baseURL) { }`
-- `for try await _ in page.load(data, mimeType: "text/html", characterEncoding: "utf-8", baseURL: baseURL) { }`
+Iterate the returned sequence (or ignore it) depending on whether the caller
+cares when the load ends. `characterEncoding` takes a `String.Encoding`, not a
+string like `"utf-8"`.
 
-## Observing progress and title
+## Progress, title and other state
 
-`WebPage` is observable, so SwiftUI can bind directly to its state.
+Besides `title`, `url`, `isLoading`, `estimatedProgress` and
+`backForwardList`, a page reports `themeColor` (the page's theme colour, if
+any) and `hasOnlySecureContent`.
 
 ```swift
-struct ReaderView: View {
-    @State private var page = WebPage()
+struct DocsPane: View {
+    @State private var model = HelpCenterModel()
+    let home: URL
 
     var body: some View {
-        WebView(page)
-            .navigationTitle(page.title ?? "Loading")
+        WebView(model.page)
+            .navigationTitle(model.page.title)
+            .toolbarBackground(model.page.themeColor ?? .clear, for: .navigationBar)
             .overlay(alignment: .top) {
-                if page.isLoading {
-                    ProgressView(value: page.estimatedProgress)
-                        .padding()
-                }
-            }
-            .task {
-                do {
-                    for try await _ in page.load(URLRequest(url: URL(string: "https://example.com/docs")!)) {
-                    }
-                } catch {
-                    // Handle load failure.
+                if model.page.isLoading {
+                    ProgressView(value: model.page.estimatedProgress)
+                        .padding(.horizontal)
                 }
             }
+            .task { await model.show(home) }
     }
 }
 ```
 
-Useful properties:
-- `title`
-- `url`
-- `isLoading`
-- `estimatedProgress`
-- `themeColor`
-- `hasOnlySecureContent`
-- `backForwardList`
-
-## Observing navigation events
+## Following navigation events
 
-Use `currentNavigationEvent` for a lightweight current-state view. Use `navigations` to observe the full sequence of navigation events.
+`load` returns the events of that one navigation; `page.navigations` delivers
+the events of every navigation the page makes, including link taps. Both are
+throwing sequences. The event cases are `.startedProvisionalNavigation`,
+`.receivedServerRedirect`, `.committed` and `.finished`. Failures are not
+events: they arrive as thrown errors, typically a `WebPage.NavigationError`
+such as `.failedProvisionalNavigation(_:)`, `.webContentProcessTerminated`
+or `.pageClosed`.
 
 ```swift
 @MainActor
-func observeNavigations(for page: WebPage) {
-    Task {
-        for await event in page.navigations {
+func watch(_ page: WebPage) async {
+    do {
+        for try await event in page.navigations {
             switch event {
             case .finished:
-                print("Navigation finished")
-            case .failed(let error), .failedProvisionalNavigation(let error):
-                print("Navigation failed: \(error)")
+                await collectHeadings(from: page)   // follow-up work goes here
             default:
                 break
             }
         }
+    } catch WebPage.NavigationError.failedProvisionalNavigation(let reason) {
+        report(reason)
+    } catch {
+        report(error)
     }
 }
 ```
 
-This is the right place to trigger follow-up work like parsing headings after a finished navigation.
+The finished event is the right moment for work that needs the loaded
+document, such as reading its headings. For lightweight UI, the observable
+properties (`isLoading`, `estimatedProgress`) are usually enough; there is no
+separate "current event" property.
 
-## Ephemeral pages and custom user agents
+## Throwaway pages and custom user agents
 
-Use `WebPage.Configuration` when you need a nonpersistent page, custom user agent, or tighter loading rules.
+For a quick metadata fetch or an isolated session, configure a page that
+keeps nothing around:
 
 ```swift
 @MainActor
-func makeMetadataPage() -> WebPage {
-    var configuration = WebPage.Configuration()
-    configuration.loadsSubresources = false
-    configuration.defaultNavigationPreferences.allowsContentJavaScript = false
-    configuration.websiteDataStore = .nonPersistent()
-
-    let page = WebPage(configuration: configuration)
-    page.customUserAgent = "MetadataBot/1.0"
+func makeScratchPage() -> WebPage {
+    var setup = WebPage.Configuration()
+    setup.loadsSubresources = false
+    setup.defaultNavigationPreferences.allowsContentJavaScript = false
+    setup.websiteDataStore = .nonPersistent()
+
+    let page = WebPage(configuration: setup)
+    page.customUserAgent = "ExampleReader/2.1"
     return page
 }
 ```
 
-Use nonpersistent pages when you want an isolated web session or metadata fetch path without shared cookies or long-lived website data.
+A non-persistent data store means no shared cookies and no long-lived website
+data, so each such page is its own sealed session.