How WKWebView Manages Cookies: Storage Location & Sync Mechanics

1. Introduction

When a browser loads network resources it uses HTTP, a stateless client‑server protocol. Because HTTP is stateless, client‑side storage mechanisms such as cookies are used to keep state across requests.

2. Cookie Overview

According to MDN, an HTTP cookie is a small piece of data stored locally by the browser and sent with each request. Cookies are mainly used for:

Session state management : login status, shopping cart, game scores, etc.

Personalized settings : user‑defined preferences, themes, etc.

Browser behavior tracking : analyzing user behavior.

3. Basic Cookie Usage

3.1 Front‑end JavaScript

Reading and writing cookies follows the MDN syntax:

// Read all cookies accessible from the current page
allCookies = document.cookie;

// Write a new cookie
document.cookie = "someCookieName=true; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=/";

3.2 Backend Set‑Cookie Header

When the server returns a Set‑Cookie header the cookie can be inspected with tools such as Charles.

3.3 iOS Cookie API

iOS provides WKHTTPCookieStorage with the following methods:

@interface WKHTTPCookieStore : NSObject

- (void)getAllCookies:(void (^)(NSArray<NSHTTPCookie *> *))completionHandler;
- (void)setCookie:(NSHTTPCookie *)cookie completionHandler:(void (^ __nullable)(void))completionHandler;
- (void)deleteCookie:(NSHTTPCookie *)cookie completionHandler:(void (^ __nullable)(void))completionHandler;

@end

4. WebKit Cookie Technical Principles

4.1 Processes and Scenarios

WKWebView consists of three processes:

UIProcess : the app process. Calls WKHTTPCookieStorage which forwards operations to NetworkProcess via inter‑process communication.

WebContent : the renderer. Executes JavaScript cookie actions; each page keeps an in‑memory cookieCache synchronized with NetworkProcess.

NetworkProcess : the central cookie store backed by NSHTTPCookieStorage. It holds persistent and session cookies and broadcasts changes.

4.2 Coordination

Cookie coordination works as follows:

UIProcess does not store cookies directly; it forwards operations to NetworkProcess, which is the authoritative store.

WebContent registers listeners for cookie changes broadcast by NetworkProcess, keeping its cookieCache up‑to‑date.

When JavaScript calls setCookie, the string is parsed into an NSHTTPCookie, stored in cookieCache, then synchronized to NetworkProcess for persistent storage.

On cold start, NetworkProcess loads persisted cookies from disk into an in‑memory dictionary ( allCookies) and notifies WebContent processes.

Any modification from client or server triggers a broadcast, prompting all WebContent processes to refresh their caches.

5. Summary

Cookies are simple to use but involve complex coordination inside WebKit. UIProcess, WebContent, and NetworkProcess determine where cookies reside (memory vs. disk) and how they are synchronized across JavaScript, HTTP headers, and iOS APIs. Developers should handle modifications carefully to avoid unintended side effects.

Supplement: Cross‑Origin Cookie Restrictions

iOS 14 disables cross‑origin requests from carrying cookies (see https://webkit.org/tracking-prevention/).

Reference Links

WebKit source: https://github.com/WebKit/WebKit Apple Swift implementation of NSHTTPCookieStorage:

https://github.com/apple/swift-corelibs-foundation/blob/main/Sources/FoundationNetworking/HTTPCookieStorage.swift

MDN documentation:

https://developer.mozilla.org/zh-CN