MAUI Blazor Hybrid
A .NET MAUI Blazor Hybrid app hosts Razor components — the same .razor files you'd use in a Blazor Server or WebAssembly web app — inside a native shell via the BlazorWebView control, which embeds a lightweight web view and runs your Blazor components locally through .NET, not over HTTP. This means the UI layer (components, CSS, routing) can be shared verbatim between a MAUI app and a Blazor web app in the same solution, while still giving you full access to native device APIs like the camera, geolocation, or SQLite from C# code behind those same components.
Cricket analogy: It's like a cricketer who can bat equally well in Test whites and T20 colors — the underlying technique (the Razor components) is the same skill, just deployed across two different formats (native app and web app) of the same game.
The BlazorWebView Control
BlazorWebView is declared in a MAUI page's XAML (or set as MainPage directly) with a HostPage pointing at wwwroot/index.html and a RootComponents collection specifying which .razor component to bootstrap first — under the hood it hosts a WebView2 control on Windows, WKWebView on iOS/macOS, and the Android System WebView on Android, all wired to a local .NET runtime running in-process rather than talking to a remote server. Because Blazor's component model, data binding, and dependency injection all run through the exact same Microsoft.Extensions.DependencyInjection container as the rest of the MAUI app, a Razor component can constructor-inject an IProductService registered in MauiProgram.cs exactly like a native view model can.
Cricket analogy: It's like a franchise league using the same central rulebook and scoring engine across every venue, even though the actual stadium (WebView2, WKWebView, Android WebView) hosting the match differs by city.
<!-- MainPage.xaml -->
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="MyApp.MainPage">
<BlazorWebView HostPage="wwwroot/index.html">
<BlazorWebView.RootComponents>
<RootComponent Selector="#app" ComponentType="{x:Type local:Routes}" />
</BlazorWebView.RootComponents>
</BlazorWebView>
</ContentPage>@* Components/Pages/ProductList.razor - shared between MAUI Hybrid and Blazor Web *@
@page "/products"
@inject IProductService ProductService
<h3>Products</h3>
@if (products is null)
{
<p>Loading…</p>
}
else
{
@foreach (var p in products)
{
<div class="product-card">@p.Name — @p.Price.ToString("C")</div>
}
}
@code {
private List<Product>? products;
protected override async Task OnInitializedAsync()
=> products = await ProductService.GetProductsAsync();
}Sharing Code Between Web and Native Targets
The typical project layout for a shared UI is a Razor Class Library (RCL) holding the .razor components, referenced by both a MAUI Blazor Hybrid head project and a Blazor WebAssembly (or Server) head project — each head only supplies its own MauiProgram.cs/Program.cs DI registrations and platform-specific service implementations behind a shared interface, so a ICameraService might use Microsoft.Maui.Media.MediaPicker in the MAUI head but silently no-op or fall back to a file <input> element in the web head.
Cricket analogy: It's like a national team's core tactical playbook being shared by both the senior squad and the A-team, while each squad's actual personnel (implementations) differ based on who's actually available to play.
Keep platform-specific APIs (camera, file system, SQLite) behind an interface defined in the shared RCL, with a MAUI-specific implementation registered in MauiProgram.cs and a web-specific (or stub) implementation registered in the WebAssembly/Server head's Program.cs — this is the same dependency-inversion pattern used for testable native view models.
BlazorWebView is not a full WebAssembly sandbox — it runs your Blazor component code as real .NET IL through the platform's native WebView control, so JS interop calls still cross a bridge and can be noticeably slower than in a pure Blazor WASM app; avoid chatty per-frame JS interop in hot rendering paths.
- BlazorWebView embeds Razor components inside a native MAUI shell, running .NET locally in-process rather than over HTTP to a remote server.
- It hosts WebView2 on Windows, WKWebView on iOS/macOS, and Android System WebView on Android, all bootstrapped from a RootComponents collection pointing at HostPage.
- Razor components in a Hybrid app use the exact same Microsoft.Extensions.DependencyInjection container as the rest of the MAUI app, enabling constructor injection of shared services.
- A Razor Class Library (RCL) is the standard way to share .razor components between a MAUI Blazor Hybrid head and a Blazor WebAssembly/Server head.
- Platform-specific APIs (camera, SQLite, geolocation) should sit behind an interface defined in the shared RCL, implemented differently per head project.
- JS interop in BlazorWebView crosses a native bridge and can be slower than in pure Blazor WASM — avoid chatty interop in hot paths.
- Blazor Hybrid is ideal when a team wants to maximize UI code reuse between a web app and a native app without duplicating component logic.
Practice what you learned
1. How does BlazorWebView execute Razor component code inside a MAUI app?
2. What underlying WebView control does BlazorWebView use on Windows?
3. What is the standard mechanism for sharing .razor components between a MAUI Blazor Hybrid app and a Blazor WebAssembly app?
4. Why should chatty, per-frame JS interop calls be avoided in a MAUI Blazor Hybrid app?
Was this page helpful?
You May Also Like
Dependency Injection
Understand how .NET MAUI's built-in dependency injection container wires up services, view models, and pages via MauiProgram.cs.
Consuming REST APIs
Learn how to call web APIs from a .NET MAUI app using IHttpClientFactory, System.Text.Json, and connectivity-aware error handling.
Publishing to App Stores
Walk through preparing, signing, and submitting a .NET MAUI app to Google Play and the Apple App Store.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics