Getting Started with NativeWebView

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.

What You Will Build

By the end of this section you will have:

An Avalonia window hosting NativeWebView.
Platform backend registration for the current runtime.
Runtime readiness checks before first navigation.
A working choice between Embedded, GpuSurface, and Offscreen render modes.

Choose the primary surface first:

Use NativeWebView when the browser must live inside an Avalonia layout.
Use NativeWebDialog when the browser should live in a separate desktop window.
Use WebAuthenticationBroker when the main goal is an auth callback flow.

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: