SwiftUI WebView

Displaying and controlling web content in SwiftUI. The deep API reference — native WebView/WebPage, navigation events, NavigationDeciding, JS interaction, URLSchemeHandler, find-in-page, the WKWebView/UIViewRepresentable path, coordinator pattern, and migration — lives in references/guide.md. This file is the decision and discipline layer: read it first, open the guide for specifics.

Dials

Set these explicitly at the start; they change what "correct" means.

1. BACKEND — native (iOS 26+ SwiftUI WebView + WebPage, default; no UIKit) · representable (WKWebView via UIViewRepresentable + Coordinator, required below iOS 26) · conditional (if #available(iOS 26, *) switching between the two — the real answer when your deployment target is < iOS 26).
2. CONTENT_TRUST — bundled (your own HTML/JS via URLSchemeHandler or load(html:baseURL:)) · first-party (your own web properties, fixed allowlist) · arbitrary (user-followable external links — this is the SFSafariViewController case, not a bare WebView).
3. JS_BRIDGE — none · read (Swift calls callJavaScript / evaluateJavaScript to read the page) · two-way (page posts to a WKScriptMessageHandler / native handler — every inbound message must be validated).

When to use

Embedding web content you control inside your own UI: rendered HTML, a bundled web app, a first-party page with a native chrome around it, or a Swift↔JS bridge. If the goal is to open an arbitrary URL the user tapped (external links, "open in browser", OAuth, marketing pages), reach for SFSafariViewController — App Review treats a bare WKWebView showing third-party content as a rejection risk.

Core rules