Getting started with WebView 2

Microsoft’s move to a new set of Windows controls as part of the WinUI 3 libraries is one sign of its rethinking how the Windows SDKs are developed and delivered. At heart it’s a decoupling of controls from APIs, a new method for both how they’re shipped and how you can package them with your code. Microsoft is changing its delivery model, no longer updating with Windows but as technologies change and as new features are developed.

One of the first new controls to get a release is an update to the familiar WebView. The original WebView used the EdgeHTML engine to embed HTML content in your applications. That meant it was limited to Windows feature updates for updates to HTML and JavaScript, with security fixes as part of Patch Tuesday. Relying on the Windows install for support ensured that you were tied to using the lowest common denominator set of features. Although you could use feature detection to work your way around CSS issues, more complex features required more code for fallbacks to lower specifications.

The new WebView release builds on the current Chromium-based Edge browser releases, offering the same features using the same process and resource model. With Microsoft pushing regular builds through multiple channels, you can be ready for new features before you ship code to your users.

Hybrid applications: Web and native

WebView 2 is an important piece of the modern application platform, providing a framework for embedding HTML, JavaScript, and CSS in your code as part of a hybrid app, somewhere on the spectrum between a native app and a Progressive Web App (PWA). With WebView 2 you can use a snippet of Web code to handle a specific UI case or wrap an entire website as an application, building your own .NET alternative to Electron.

Microsoft describes these as hybrid applications, mixing native code with Web where necessary. WebView 2 lets Web code access native APIs directly, rather than working through a PWA’s cross-platform APIs. If you’re prepared to build only for Windows, then you can do a lot more through a .NET UI shell and a WebView canvas, while taking advantage of all of Chromium’s UI capabilities.

The latest builds of WebView 2 are now generally available on most platforms, though the WinUI 3 version (like the rest of WinUI 3) remains in preview. With general availability you can start replacing the old EdgeHTML WebView control with the new version in your Win32, WPF, and WinForms applications.

Using WebView 2 in your code

Using WebView 2 is straightforward. If you’re working with Windows Presentation Foundation (WPF), you can use it with either the .NET Framework or .NET Core. The control SDK is on NuGet, so adding it adds any prerequisites and creates scaffolding code that can be used to quickly test compilation. HTML is added to the appropriate XAML namespace using the WebView control and a link to any source in a DockPanel block.

Once you have the basic control working, you’re able to add additional features to the DockPanel, for example adding a navigation bar to give you a basic browser. WebView 2’s content loading process raises events that can be consumed by the host application, allowing it to wait for content to load or errors to be indicated. This allows you to add code that controls what can be loaded, reducing the risk of hijacked content, as well as locking down external connections to HTTPS to lower the risk of interception.

Crossing the Web/native barrier

WebView 2 allows you to inject JavaScript code at runtime; this ensures that scripts can be bundled in your main application and injected as needed. They run before any JavaScript in loaded content, overriding actions and giving you more control. JavaScript in the control can communicate back to the host application via a postMessage method. This approach is two-way, and events can be sent back from the host to the Web content so the host app can drive operations in the control, delivering URLs and other data for in-page JavaScript to process and use.

Messages are an important tool for using WebView HTML content to control your application. Once parsed by the host app, they can trigger application functions. However, you do need to handle them as asynchronous, treating them as callbacks or similar message-based design patterns. If you send a message to the control and expect a response, you must ensure that you wrap the transaction in an await or similar construct.

Shipping WebView 2 with your apps

One of the more important features in WebView 2 is the idea of Fixed Version distributions. Instead of relying on users or IT departments to keep the underlying runtime up to date via Windows Update, you can choose a version of WebView 2 to bundle in your code along with its supporting Chromium bits. Yes, your install bundle will be bigger, but you don’t have to worry about support for incompatible versions of Edge, and you can build code that uses all the browser engine features you need.

Bundling your own copy of Chromium does move security responsibilities onto your shoulders. You will have to make and distribute new releases every time Microsoft ships an updated version of Edge (roughly every six weeks or so) and will need to factor that into any application support model. Using versions of Edge with known security bugs can be a governance issue for IT teams and can add risk to any business process relying on outdated, insecure browser components.

Even so, there are significant benefits to bundling known and tested components with your code. Conduct a full analysis of your application’s usage model and risk exposure before choosing to deliver a fixed bundle.

In most cases you’ll use what Microsoft calls Evergreen mode, where the underlying WebView 2 runtime platform is managed by Microsoft. This is shared by all WebView 2 applications and is a modified version of the Chromium-based Edge binaries, updating on the same schedule.

Users won’t see it as an application, and it’s installed separately from Edge, so you aren’t dependent on an installed browser. All you need to do is include a small snippet of bootstrapper code in your installer, which checks to see if the runtime is installed. If not, it will download the runtime prior to installing your application.

WebView 2 works anywhere the new Chromium Edge runs, so you can use it in code that works as far back as Windows 7. Be aware that support on older versions of Windows (especially on out-of-support versions such as Windows 7 and Windows Server 2008 R2) is limited to the Microsoft Edge support lifecycle, itself tied to the Chromium project and Google’s Chrome support model.

It’s an interesting road to modernizing applications, providing a consistent look and feel across different versions of Windows, helping you bring users on older operating systems to newer applications—and eventually to newer versions of Windows.