NativeWebView is split into a small set of focused packages so you can compose only the browser surface you need:
NativeWebView: Avalonia NativeControlHost surface for embedding the native browser view.NativeWebView.Core: controller layer, diagnostics, capability model, and backend abstractions.NativeWebView.Dialog: dialog/window facade for desktop browser windows.NativeWebView.Auth: authentication broker facade for OAuth and sign-in flows.NativeWebView.Interop: native handle contracts and interop structs.NativeWebView.Platform.*: platform registrations and backend implementations.By the end of this section you will have:
NativeWebView.Embedded, GpuSurface, and Offscreen render modes.NativeWebDialog for desktop popup windows and WebAuthenticationBroker for auth callback flows.Choose the primary surface first:
NativeWebView when the browser must live inside an Avalonia layout.NativeWebDialog when the browser should live in a separate desktop window on Windows, macOS, or Linux.WebAuthenticationBroker when the main goal is an auth callback flow. The repo now ships runtime implementations across Windows, macOS, Linux, iOS, Android, and Browser.Mobile and workload-specific note: the iOS and Android runtime paths come from their platform-targeted backend assemblies rather than the default net8.0 contract build. Browser authentication is popup-based and does not provide NativeWebDialog.
Choose the render mode next:
Embedded: best native fidelity and input behavior.GpuSurface: composited capture path for reduced airspace issues while staying GPU-backed.Offscreen: fully managed composition path for overlays, captures, and host-controlled layering.NativeWebView assumes startup validation is part of the application contract: