iOS26.4 WKWebView loadurl error -1005

Thanks for the careful report and for setting out the four questions clearly — the structure helps.

NSURLErrorNetworkConnectionLost (-1005) surfacing through webView:didFailProvisionalNavigation:withError: is a generic outcome that can come from several distinct underlying conditions — TCP-level disconnects, HTTP/2 stream resets (RST_STREAM), idle-connection close races during connection reuse, transient network-path changes, or server-side behavior. Without captured diagnostics from a failure as it happens, there isn't a way to map your reports to a specific cause, and there isn't a known iOS 26.4.x regression we'd identify as a likely match.

The most productive next step is to capture per-request diagnostics during a failure and file a Feedback Assistant report:

❏ Web Inspector network waterfall.

Three things need to be enabled before this works:

1. iPhone: Settings → Apps → Safari → Advanced → "Web Inspector" toggle on.
2. Mac: Safari → Settings → Advanced → "Show features for web developers" enabled.
3. In your app: WKWebView.isInspectable must be set to true on the WebView you want to attach to. Starting in iOS 16.4, WKWebView is not inspectable from Web Inspector by default — apps must opt in (typically guarded by an availability check for iOS 16.4 or later).

Steps:

1. Run your app on the iPhone with the WebView visible and the failing URL loaded (or about to load).
2. With the iPhone connected by USB, on the Mac choose Safari → Develop → [Your iPhone] →. The submenu will contain entries for Safari and any inspectable WebViews; choose the one labeled with your app's name or the failing page's URL.
3. In Web Inspector, select the Network tab before reproducing the failure. The waterfall captures requests starting when the tab is open.
4. Trigger a navigation that reproduces the -1005. The failing main-frame request appears in the waterfall; clicking it shows which phase failed (DNS, TCP/TLS, Request, Response) and per-phase timings, plus whether earlier requests to the same origin shared a connection.
5. Click Export in the Network tab toolbar to save the capture as a .har (HTTP Archive) file. The HAR is the structured JSON export that contains the per-request timings, HTTP version, and connection identifiers used to render the waterfall — that's what to attach to the Feedback. HAR includes request and response headers, so redact anything sensitive (auth cookies, tokens) before sending if needed.

If reproducing this bug takes several attempts, leave the Network tab open across attempts so the waterfall accumulates the full sequence before you export.

❏ Networking diagnostic profile. Install the Networking profile from <https://developer.apple.com/bug-reporting/profiles-and-logs/?platform=ios>, reproduce the failure, and capture a sysdiagnose immediately after. The profile increases verbosity for CFNetwork and connection lifecycle logging that's included in the sysdiagnose bundle.

❏ Per-failure metadata. For each captured failure: the exact URL, a timestamp narrowed to a few seconds (so the relevant entries can be located inside the sysdiagnose), device model and iOS build, and the network conditions at the time — Wi-Fi or cellular, VPN or proxy in use, captive-portal environment, IPv4 or IPv6 path, and whether the failure coincided with a network transition. Several known -1005 patterns are environment-specific (e.g., IPv6-only paths, idle connection reuse after network change), so this metadata often narrows the search significantly.

On your specific questions:

❏ Public API for "did this request reuse an existing connection?" WKWebView doesn't expose per-request connection-reuse state to its delegates. URLSessionTaskMetrics provides that level of detail for tasks an app runs through its own URLSession, but the session WKWebView uses internally isn't exposed to clients.

Note that HTTP/2 can reuse connections aggressively to avoid the latency cost of repeated TLS handshakes — the protocol is designed to multiplex multiple requests over a single long-lived connection per origin where possible. On subsequent requests to a given host, connection reuse is common rather than exceptional, so the answer to "did this reuse a connection?" tends to be yes. The Web Inspector network waterfall shows this implicitly: a reused-connection request shows near-zero DNS / Connect / TLS phases in the per-request timing breakdown, while a fresh-connection request shows nontrivial time in those phases. The diagnostic question for your scenario is therefore less "did reuse happen" and more "did a reused connection get torn down between client and server without the client noticing in time" — which is the failure mode for the idle-close race and HTTP/2 stream-reset scenarios that can appear as -1005.

❏ One-time silent retry for main-frame -1005 GETs. That's a UX tradeoff rather than a recommended pattern. A retry can mask a transient network drop that would otherwise be visible; it can also hide a real underlying connection or server problem from your own telemetry. CFNetwork already retries some classes of HTTP/2 unresponsive-connection failure internally before -1005 is reported, so a client-side retry on top of that adds an extra recovery path rather than the only one available. Whether the tradeoff is worth it tends to depend on what proportion of these are transient versus persistent in your data, and whether the retry would remove an indicator you'd otherwise want to monitor.

If you're able to attach the HAR export, sysdiagnose, and a few timestamps to a Feedback, please post the FB number here so we can route it to the right team.