WKWebView explained: Apple's web view and how it differs from Safari
WKWebView is the view Apple's WebKit framework provides for showing web content inside a Mac or iOS app, and it runs the same WebKit engine Safari is built on. What it lacks is the browser around the engine: no tabs, extensions, bookmarks or Safari's settings, and its storage, user agent and inspector are whatever the app chooses. A Pake app on macOS is a native window around one WKWebView, so these choices decide how your site behaves in it.
What it is, and what it replaced
Apple describes WKWebView as an object that displays interactive web content, such as for an in-app browser. It belongs to the WebKit framework and has been available on macOS since 10.10. An app creates it with a WKWebViewConfiguration, and Apple says the view takes those settings only at creation, so they cannot be changed afterwards.
The older view was UIWebView on iOS, which Apple marks deprecated since iOS 12 and tells developers to replace with WKWebView. On macOS the legacy WebKit classes are deprecated as well, and Apple's page for WebFrame lists macOS 10.3 to 10.14. The practical meaning is that a modern Mac app that shows a website uses WKWebView, and wry, the library Tauri uses to draw web content, does the same on macOS: its README names WebKit and its source creates a WKWebViewConfiguration.
WKWebView, Safari and the engine
The engine is shared. The Tauri webview reference says macOS uses the web view preinstalled since 10.10, that the OS updates it, and that unsupported macOS versions do not receive WebKit updates. Its table pairs macOS releases with Safari versions, for example the macOS Sonoma 14.0 beta with WebKit 616.1.14.11.11 and Safari 17.0. So a page that behaves in Safari on your macOS version should behave in a WKWebView on that version, and the update path is the same: a macOS update.
What does not come along is the browser. Apple's Add to Dock page shows a web app whose toolbar carries buttons for the Safari extensions you have installed, and that is a Safari feature, not something a WKWebView has by itself. Within Pake, three effects show up in its docs:
- Passkeys and Touch ID sign-in are not available in Pake apps on macOS, because the system only offers them to browsers and to apps tied to the site's domain (Pake's FAQ).
- Native password-save prompts exist only on Windows.
--password-autosaveis ignored on macOS and Linux. - WKWebView does not provide its own HTTP 401 login dialog, so Pake offers
--basic-authto prompt for credentials on macOS, kept for the session only.
Processes: why it does not live in the app
Apple's WKProcessPool page says WebKit renders web view content in separate processes, not in your app's process space, for a more secure and stable experience. The class itself is deprecated, with the note that creating several pools no longer has any effect, so the page is useful for the process fact, not for configuration.
WebKit's own architecture notes describe three roles. The UI process brokers requests for system resources such as the clipboard, microphone and camera. Each page loads in a sandboxed WebContent process. A Networking process, which several WebContent processes can share, handles all network access, manages the disk cache and backs storage APIs like Web Storage and IndexedDB.
The page runs in WebKit's own processes, outside the app's process, and the data store decides what survives a restart.
Pake's FAQ names the process on macOS as WebContent and makes the same point for memory: it can use several hundred MB for a heavy single-page app such as Gemini, Slack or ChatGPT, governed by the engine and the page, not by Pake. The installer size and the memory are separate numbers, as Tauri vs Electron explains.
Data stores: where cookies and sign-ins live
A web view keeps cookies, caches and other site data in a WKWebsiteDataStore. Apple says a view uses the default store unless told otherwise, and that this default saves data persistently to disk. A non-persistent store keeps data in memory only and is meant for private browsing. Since macOS 14 an app can also ask for a persistent store by identifier, which Apple describes for profiles.
Pake maps its options onto these. In the wry library Tauri uses, version 0.54.2 used by Pake CLI 3.17.6, --incognito selects the non-persistent store, an identifier is used only if the app supplies one on macOS 14 or later, and otherwise the default store is used. Pake passes no identifier, so a normal app on a Mac uses the default store and an incognito app keeps nothing. The CLI docs say incognito means no cookies, local storage or history, which is why the WeChat gallery app asks you to scan a code on every launch.
On Windows and Linux Pake does something different: it sets a data directory under the system config folder, named after the product, so each app has its own profile there. Multiple accounts on one website describes what that means for two apps.
User agent
Apple's customUserAgent is nil by default, and applicationNameForUserAgent lets an app add its own name to the string. Pake passes a user agent to the window when it builds it, and wry applies it with setCustomUserAgent. In Pake CLI 3.17.6, a Mac app defaults to a Safari 26.0 string, and for Windows a Chrome 147.0.0.0 string. The string is a label, not the engine, which Setting a user agent explains in full.
Web Inspector for an app
Apple's isInspectable property controls whether Safari's Web Inspector can open a view. It defaults to false, exists on macOS 13.3 and later, and when true you pick the view from Safari's Develop menu. If that menu is missing, Apple's Safari help says to choose Safari > Settings, click Advanced and select Show features for web developers.
Pake does not enable it in normal builds. The wry code that sets it, and the developerExtrasEnabled preference, is compiled only in debug builds or with a devtools feature, and Pake's Cargo.toml does not turn that feature on. Pake's --debug flag builds in debug mode (tauri build --debug), which turns on the Toggle Developer Tools menu item, disabled in normal builds, and its shortcut Cmd Option I on a Mac. So to inspect a site inside a Pake app, build it again with --debug:
pake https://example.com --name Example --debugUse the inspector to check whether the page fails in the app but works in Safari, then fix that difference, and ship the app built without --debug.
The counterparts on Windows and Linux
Pake uses the platform's web view on each system, as Tauri's reference lists. On Windows that is WebView2, built on Edge's Chromium, which updates itself and is covered in What is WebView2. On Linux it is WebKitGTK, in whatever version the distribution ships, and Pake's FAQ names its helper processes WebKitWebProcess and WebKitNetworkProcess. Those names echo the WebContent and Networking roles above.
The result is that one Pake app is three different engines across three systems. A site that works in Safari usually works on a Mac, and the Windows build has to be tested separately, which How Pake works also says.
When a site misbehaves
Open it in Safari on the same Mac first. If it fails there too, the app is not the cause. If it works in Safari and not in the app, check these in order: sign-in (the sign-in guide; Google's OAuth guide says iOS and macOS developers may see disallowed_useragent when they open authorization requests in WKWebView, so a Google sign-in that works in Safari and fails in the app is expected), a Cloudflare or bot check, which Pake's FAQ says the system web view is often flagged by, and a missing camera or microphone permission, since Pake apps on macOS do not request them unless you pass --camera or --microphone.
FAQ
Is WKWebView the same as Safari?
It uses the same WebKit engine, but it is only the view. Safari adds tabs, extensions, bookmarks and its own settings.
Can a Pake app use Chrome's engine on a Mac?
Pake uses WKWebView on macOS, and a site that needs Chromium is a reason to look at a Chromium-based wrapper.
Does a WKWebView share cookies with Safari?
In Pake, website data stays in the app’s own store. A Safari sign-in does not carry over automatically, so sign in again in the Pake app. The “default” in WKWebsiteDataStore.default() refers to the app’s persistent store, not access to Safari’s sign-ins.