Unveiling WKWebView’s Loading Lifecycle: Deep Dive into WebKit Processes and Navigation Delegates

1. iOS WebKit Loading Framework

WebKit on iOS runs three separate processes that cooperate via inter‑process messaging:

NetworkProcess : Handles all network requests using NSURLSession, manages progress callbacks, caching, HSTS, and cookie policies.

WebContentProcess : Manages page resources, history, parsing, rendering, and notifies the UIProcess via delegates.

UIProcess : Runs in the same process as the app, configures WebView features, receives messages from WebContentProcess, and decides whether to initiate requests.

2. iOS WebKit Loading Flow

The UIProcess initiates loading with [self.webView loadRequest:request];. Only GET requests are supported; POST bodies are discarded during cross‑process transfer.

The UIProcess creates the NetworkProcess, which performs a pre‑connect (TCP handshake) to speed up subsequent requests.

The UIProcess forwards the request to WebContentProcess. WebContentProcess creates a DocumentLoader, cancels any pending requests from the previous page, and binds the current page ID to the NetworkProcess for later data correlation.

NetworkProcess reuses the pre‑connect via NSURLSession, streams data back to WebContentProcess, which parses HTML, CSS, JavaScript, images, fonts, builds the DOM and CSSOM, composes the render tree, and repeatedly calls checkAndDispatchDidReachVisuallyNonEmptyState to determine when the page can be displayed.

Rendering is considered complete when one of the following conditions is met:

Plain‑text data reaches a non‑empty size of about 200 bytes.

Image data exceeds 32 × 32 pixels.

If neither condition is satisfied, the main document is displayed after no further data arrives.

3. WKNavigationDelegate Overview

@protocol WKNavigationDelegate <NSObject>
@optional
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;
- (void)webView:(WKWebView *)webView didStartProvisionalNavigation:(WKNavigation *)navigation;
- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler;
- (void)webView:(WKWebView *)webView didReceiveServerRedirectForProvisionalNavigation:(WKNavigation *)navigation;
- (void)webView:(WKWebView *)webView didFailProvisionalNavigation:(WKNavigation *)navigation withError:(NSError *)error;
- (void)webView:(WKWebView *)webView didCommitNavigation:(WKNavigation *)navigation;
- (void)webView:(WKWebView *)webView didFinishNavigation:(WKNavigation *)navigation;
- (void)webView:(WKWebView *)webView didFailNavigation:(WKNavigation *)navigation withError:(NSError *)error;
- (void)webView:(WKWebView *)webView didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler;
- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView NS_AVAILABLE(10_11, 9_0);
@end

3.1 decidePolicyForNavigationAction

If the delegate returns cancel, the request is dropped entirely. If it returns allow, the kernel checks whether the link is a universal link; if so, it attempts to open the associated app and may cancel the request if the app handles it.

3.2 didStartProvisionalNavigation

This method signals the beginning of the provisional (temporary) loading state, before the page is committed to navigation history. The page becomes “committed” once the first data packet arrives, after which didCommitNavigation is invoked.

3.3 didFailProvisionalNavigation vs. didFailNavigation

Network errors are first reported to WebContentProcess. If the page is still in the provisional state, didFailProvisionalNavigation is called; if the page has already been committed, didFailNavigation is called.

3.4 didFinishNavigation

This method fires when NSURLSession reports that the network load has finished. Because the signal travels through two inter‑process messages (NetworkProcess → WebContentProcess → UIProcess), there is a slight delay, but it is unrelated to sub‑resource loading or the moment the page becomes visible.

4. Tips

Always relate the three processes when studying WebKit source code to build a process‑centric mental model.

Modify the source to test hypotheses, e.g., disable the didFinishNavigation trigger in the network layer and inject custom data to verify rendering conditions.

5. References

WebKit source: https://github.com/WebKit/WebKit

WebKit website: https://webkit.org/