Embedded and desktop apps
Embedded browsers: CEF vs WebView2 vs WKWebView
By Daniyal Sheikh, Chromium Integration Engineer
Technically reviewed by Usman Khan, Lead Chromium Developer
Published Last updated 7 min read
If your point-of-sale terminal shows a web checkout, somebody has to patch the engine that renders it when the next Chromium security fix lands. With CEF, that is your team. With WebView2 or WKWebView, it is Microsoft or Apple. That single difference drives most of the decision, for kiosks, signage and native desktop apps alike.
Three engines, three update models
| Factor | CEF | WebView2 | WKWebView |
|---|---|---|---|
| Underlying engine | Chromium, bundled with your app | Chromium-based Microsoft Edge runtime | WebKit |
| Platforms | Windows, macOS, Linux | Windows 10 and 11 (preinstalled on Windows 11) | macOS, iOS and iPadOS |
| Update model | You ship and update the bundled engine yourself | Evergreen runtime updated by Microsoft, or a Fixed Version you bundle and update | Updates with the operating system (and with Safari updates on macOS) |
| Redistribution | You bundle Chromium binaries with your app | Depends on deployment mode: shared runtime or bundled Fixed Version | Not redistributed; part of the OS |
| Off-screen rendering | Explicitly supported and commonly used | No true off-screen buffer; visual hosting through DirectComposition is available | Built around a visible view |
| Typical fit | Kiosks, POS, custom compositing, cross-platform native apps | Windows-only native apps that want to reuse the Edge engine already on the machine | macOS and iOS native apps embedding web content |
No option is strictly better. They are three answers to one question: should the engine version be something you control precisely, or something the operating system manages for you?
Control has a cost. CEF builds track Chromium’s release branches, and Chrome now ships a new major version every two weeks. Choosing CEF means planning regular rebuilds, test passes and releases, or knowingly running an engine that lags behind published security fixes. It also adds a full Chromium build to your installer, so measure the size for your own app.
How an embedded browser fits inside a native app
Whichever engine you choose, the architecture around it looks similar: a host application with its own window and controls, a bridge that passes messages between native code and the embedded page, and the engine itself rendering only the content area.
Host application
Native window, menus, controls and any peripheral integrations, such as a barcode scanner or receipt printer.
Native-to-web bridge
A message channel so native events reach the page and page actions reach native code.
Embedded engine
CEF, WebView2 or WKWebView, rendering the web content itself.
Operating system
Windows, macOS or Linux, which determines which engines are available.
- Your product
- Our engineering
- Upstream: third-party code we build on
- Platforms and release
When CEF is the right choice
- You need one engine version across Windows, macOS and Linux. CEF ships the same Chromium build on every platform, which removes the differences that come with each OS’s native web view.
- Off-screen rendering is a requirement. Custom compositing, video walls and non-standard display pipelines are what CEF’s off-screen mode is built for.
- You deploy to a fleet you control. Kiosks and POS terminals where you already manage the update process benefit from CEF’s predictable, self-contained engine version. Our kiosk browser guide covers the lockdown side.
CEF also has wrappers for other languages, such as CefSharp for .NET and JCEF for Java. For Windows .NET apps, see CefSharp vs WebView2.
When WebView2 is the right choice
- The app is Windows-only. WebView2 avoids bundling a second copy of Chromium: the runtime ships with Windows 11, and Microsoft’s Evergreen bootstrapper installs it where it is missing.
- Install size matters more than engine-version control. The Evergreen mode does not require shipping Chromium binaries with the app.
- The app can follow Edge’s update cadence. Teams comfortable with the engine updating on Microsoft’s schedule, rather than their own, do not have to maintain that update path.
When WKWebView is the right choice
- The app is macOS or iOS only. WKWebView is Apple’s supported, OS-integrated web view on both.
- The app ships on iPhone or iPad. Outside the EU and Japan, iOS and iPadOS apps must use WebKit to show web content. In those two regions, Apple offers entitlements that let qualifying apps use another engine, with extra requirements. For most iOS apps, WKWebView is the only practical choice.
The Mac App Store has no such rule. macOS apps can embed CEF or be built with Electron and still be distributed through the store.
Cross-platform apps usually mean more than one engine
A native app that needs to run on Windows and macOS with an embedded browser will, in most cases, end up using two engines: something Chromium-based on Windows and WKWebView on macOS, since WKWebView is not available outside Apple platforms. Plan for testing both, not just the one used during initial development. Tauri makes the same tradeoff at the application-framework level; see our Electron vs Tauri comparison.
Other options you may meet
On Linux and embedded hardware, WebKitGTK and WPE WebKit are the usual native choices; WPE is designed for embedded devices such as set-top boxes and signage. Qt applications usually use Qt WebEngine, which is Chromium-based like CEF. On Android, the system WebView plays the role WebView2 plays on Windows: an engine the OS updates for you.
What to decide before choosing
- Which operating systems you must support.
- Whether off-screen rendering or custom compositing is a requirement, or a visible window is fine.
- Who owns updating the engine: your team, on your schedule, or the OS vendor, on theirs.
- What native functionality (peripherals, file access, printing) needs to cross the bridge into the embedded page.
Our embedded browser development page covers the integration work in more detail, including the native-to-web bridge, custom protocol handlers and remote diagnostics for fielded devices. For an example, see our CEF Transparency case study, an internal CEF build made for a company’s own use.
Final takeaway
The operating systems you target usually narrow this choice before preference does. After that, the question is who should own the engine’s update schedule: bundle it yourself with CEF for full control, or rely on the OS-provided runtime with WebView2 or WKWebView and accept its update cadence in exchange for a smaller footprint.
Frequently asked questions
Is CEF the same thing as Chromium?
CEF, the Chromium Embedded Framework, wraps Chromium in a C/C++ API designed for embedding inside another application. It ships its own Chromium binaries with each release rather than depending on one already installed, which gives you a known, testable engine version at the cost of shipping and updating that engine yourself.
Does WebView2 update automatically?
In Evergreen mode, yes: Microsoft updates the shared WebView2 runtime independently of your app, as it does Edge. The runtime is preinstalled on Windows 11; elsewhere, ship Microsoft’s Evergreen bootstrapper or installer rather than assuming it is there. In Fixed Version mode you bundle a specific runtime, and applying Chromium security fixes becomes your job, as with CEF.
How does this relate to Electron and Tauri?
Electron and Tauri are application frameworks built on the same choices. Electron bundles its own Chromium, similar in spirit to CEF, with Node.js included. Tauri uses the web view the operating system provides: WebView2 on Windows, WKWebView on macOS and WebKitGTK on Linux, with a Rust backend.
Embedding a browser in your app?
We integrate CEF, WebView2 and WKWebView into native applications, kiosks and point-of-sale hardware, and can help pick the right one before you start building. See our embedded browser development service.