Engineering service
CEF and WebView2 Embedded Browser Development
We embed CEF, WebView2 or WKWebView in desktop software, kiosks and point-of-sale systems. We help you choose the engine, then build the native bridge, lock down what the page can do and agree with you who ships engine security updates.
- 11+ years of experience
- 300+ projects delivered
- Remote team, clients worldwide
- NDA on request
Overview
What it is and when it fits
An embedded browser puts a full browser engine inside your application. Your native code owns the window, and the web view renders content such as your interface, a hosted app or documents, with a channel between the two.
The main decision is which engine to embed, because it determines who ships security updates, how much control you have and which platforms you reach. We help you choose, then build the integration layer around it.
Who this is for
- Teams building a native application that needs to display web content or a web-based interface.
- Kiosk, point-of-sale and digital signage products that run a locked-down web UI.
- Companies moving off the old Internet Explorer-based WebBrowser control.
- Products that need a specific browser engine version or tight control over what pages can do.
How it works
Architecture at a glance
Embedding a browser in your app
Your application
Native UI, business logic and device integration.
Integration layer
The bridge between your code and the web view: messaging, custom schemes and permissions.
Browser runtime
- CEF
- WebView2
- WKWebView
- Qt WebEngine
The engine that renders web content inside your app.
Hardware and OS
Kiosks, POS terminals, signage and desktop machines.
- Your productWhat your users see
- Our engineeringWhat we build and maintain
- UpstreamThird-party code we build on
- Platforms and releaseBuild, sign and deliver
What we offer
What's included
Native-to-web messaging bridge
A message channel between your native host code and the embedded page, so native events, such as a scanned barcode or a printer status, reach the page and page actions reach native code.
Custom protocol and resource handlers
Bundled web assets served over a custom URL scheme instead of the file system, so the embedded page loads the same way in development and in the shipped app.
Off-screen and multi-view rendering
CEF off-screen rendering and multiple browser instances for apps that composite web content into a custom UI instead of showing a plain browser window.
Peripheral and device integration
Barcode scanners, receipt printers, card readers and other point-of-sale hardware connected to the embedded page through the native bridge.
Remote diagnostics
DevTools protocol access and remote debugging set up for field devices and kept off the public network, so issues on deployed kiosks and terminals can be inspected without physical access.
WebBrowser control to WebView2 migration
Host code moved off the legacy Internet Explorer-based WebBrowser control, script bridges replaced with WebView2 messaging, and your pages tested in a modern engine.
Deliverables
What you get
- 01
Engine recommendation
A written comparison of the embedding options for your platforms, with the reasoning behind our choice.
- 02
Integration layer
Code that connects your application to the web view, including two-way messaging, custom URL schemes and permission handling.
- 03
Locked-down configuration
Navigation limits, disabled features and content restrictions so the embedded page can only do what your product needs.
- 04
Update and security plan
A defined process for how the browser engine is updated, and who is responsible for shipping security fixes.
- 05
Offline and failure handling
Behavior for lost connectivity, crashed renderers and blank pages, tested on your target hardware.
- 06
Handover documentation
Build instructions, the messaging contract and notes on upgrading the engine later.
Compare
Choosing an embedded browser
The right option depends on your platforms, on how much control you need over the engine and on who maintains updates.
| Option | Platforms | Engine | Choose it when |
|---|---|---|---|
| CEF (Chromium Embedded Framework) | Windows, macOS, Linux | Chromium, bundled with your app | You need full control of the browser version and behavior, and you can ship engine updates. |
| WebView2 | Windows | Chromium via Microsoft Edge; Evergreen runtime or Fixed Version distribution | You target Windows only and want Microsoft to keep the runtime updated (Evergreen), or you need a pinned version (Fixed Version). |
| WKWebView | macOS, iOS | WebKit, part of the operating system | You build for Apple platforms and are content with the engine version the OS provides. |
| Qt WebEngine | Windows, macOS, Linux | Chromium, packaged through Qt | Your application is already built with Qt. |
| Electron | Windows, macOS, Linux | Chromium and Node.js, bundled with your app | The whole application is web-based and you want a single web codebase. |
Why it matters
What this gives you
Control of what the page can do
Navigation, context menus, developer tools and downloads are locked down unless your product needs them.
Tested on the hardware you deploy to
Tuning happens on the kiosk, POS terminal or signage box you ship, not only on a development machine.
A defined update owner
Before launch, we write down whether Microsoft, Apple or your team ships the engine's next security update.
A pinned engine version when you need it
With CEF or the Fixed Version WebView2 runtime, every device runs the engine version you tested, and you decide when to move. Evergreen WebView2 and WKWebView are updated for you by Microsoft and Apple instead.
Our approach
How we build an embedded browser integration
Requirements
We list your target platforms, the hardware, the content you will display and what the page must be prevented from doing.
You get: A requirements and constraints summary
Engine selection
We compare the options against those constraints and agree who is responsible for engine updates.
You get: A recommended engine and update model
Integration prototype
We connect a minimal version of your app to the web view and prove out messaging and permissions.
You get: A working prototype on your target hardware
Hardening and testing
We lock down navigation, handle offline and crash cases, and test on the devices you will deploy.
You get: A tested, restricted configuration
Release and handover
We package the app, document the engine update process and hand over the integration code.
You get: Release builds and maintenance notes
When this is not the right fit
- You only need to open links in the default browser. One system call is enough, with no engine to maintain.
- You cannot commit to engine updates for the product life. A bundled engine such as CEF becomes a security risk.
- The whole product is web-based and needs no native integration. A web app or Electron may be simpler.
Tech stack
Technologies we use
The engines, APIs and tools we use on this service.
Chromium
WebView2
WKWebViewQt WebEngine
C++C#SwiftWindowsmacOSLinuxFAQ
Common questions
It depends on your platforms and who you want to own updates. WebView2 is Windows-only and its Evergreen runtime updates itself, while CEF runs on Windows, macOS and Linux and gives you full control of the Chromium version. With CEF you bundle Chromium, so you are responsible for shipping its security updates.
Yes. We restrict navigation to approved addresses, disable features such as developer tools and context menus, and control what the page can access. Kiosk lockdown also involves the operating system, which we configure with your device setup.
Yes, if the content is bundled with the app or cached locally. We decide with you which content must be available offline, and design the app to handle lost connections without showing a blank page.
Yes. The legacy WebBrowser control uses the Internet Explorer engine (MSHTML), and WebView2 is the usual replacement on Windows. Migration means porting the host code, replacing scripting bridges with messaging, and testing your pages in a modern engine.
It depends on the option. Evergreen WebView2 is updated by Microsoft and WKWebView by Apple, outside your app. CEF and the Fixed Version WebView2 runtime are updated by you, when you ship a new build. We set up the update process during the project, so responsibility is clear.
Our services
Related services
Start a project
Choose the right embedded browser
Describe your application, platforms and hardware. We will recommend the browser engine that fits and plan the native integration.
