Keeping webviews up-to-date in deployed Blazor Hybrid apps

[MackinnonBuck]

We should add some documentation describing what steps can be taken to ensure that deployed Blazor Hybrid apps run with webview versions that meet the security/API requirements of the app. Following is a draft of what such a page might look like:

---

Keeping webviews up-to-date in deployed Blazor Hybrid apps

By default, the BlazorWebView control uses the currently-installed platform-specific native webview. Since webviews are periodically updated with support for new APIs and fixes for security issues, it may be necessary to ensure that your app is using a webview version that meets your app's requirements. This could be achieved in the following ways:

• Checking the webview version being used on the current platform and prompting the user to take any necessary steps to update (applicable for all platforms).
• Packaging a fixed-version webview within your app, using it in place of the system's shared webview (applicable only for Windows).

Platforms

Different platforms have various mechanisms for keeping the installed webview up-to-date and checking the current webview's version.

Windows (.NET MAUI, WPF, WinForms)

On Windows, the Chromium-based Edge WebView2 is required to run Blazor web apps. By default, the newest installed version of WebView2 (known as the Evergreen distribution) is used. If you wish to ship a specific version of WebView2 with your app, you can use the Fixed Version distribution mode.

See the WebView2 distribution docs for more information about selecting a WebView2 distribution mode and checking the currently-installed WebView2 version.

Android

The Android webview is distributed and updated via the Google Play Store. The webview version can be checked by reading the user agent string. The webview's navigator.userAgent property can be read using JavaScript interop and optionally cached using a singleton service if the user agent string needs to be made available outside of a Razor component context.

iOS/Mac Catalyst

iOS and Mac Catalyst both use WKWebView, a Safari-based control, which is updated by the operating system. Similar to the Android case, the webview version can be determined by reading the webview's user agent string.

---

Open questions:

1. It doesn't seem we have a more straightforward way to check the webview versions on iOS, Mac Catalyst, and Android than reading the user agent string via JavaScript interop. Am I wrong about this? Should we consider supporting a more streamlined way of doing this?
2. If the method I've described for checking the webview version is something we want to recommend, would it be worth providing a more concrete code sample?
3. Does anyone know if old versions of iOS can receive new WKWebView updates? If the WKWebView version is strictly tied to iOS updates, we might want to suggest checking the iOS version rather than the user agent string.
4. Are there any other details I'm missing?

@Eilon

[guardrex]

If the primary focus on keeping the WebView updated is for security, we have a planned doc for that looks like the right spot for this coverage, Blazor Hybrid Security and Identity Overview (blazor/hybrid/security/index.md). If the purpose goes beyond security (e.g., API requirements), then this seems like it should be a new topic, one that DR didn't list when we set up the list of topics (Blazor Hybrid tracking issue). I'm 👂 to know so that I can track this and work it into the right spot when the time comes for a draft (PR).

WRT the ❓s in the opening comment and further discussion: Please clearly identify specific additional doc sections/passages. It might be challenging for me to pick the relevant bits out of discussion.

[MackinnonBuck]

@guardrex The primary focus of this doc would be security, so it sounds like the spot you pointed out should work great 🙂

[guardrex]

Great! I'll hold for a bit so that we have answers on your discussion points ... and that might result in some added/changed sections and passages.

I'm planning on taking Thursday thru Tuesday off for rest and recharge 😩. I'm 🧠🔥 and need a little break. If the content is figured out by tomorrow, I'll rush it into a PR for final review+merge before my break. If it comes in during my break, I'll get it posted by Wednesday of next week.

[Eilon]

If you wish to ship a specific version of WebView2 with your app, you can use the Fixed Version distribution mode.

It wasn't our goal to support this model for the initial release. Does it actually work? We've added many features since our initial claims of what we'd support, so maybe it is possible now?

Tagging @javiercn who is looking into enabling app devs to access more WebView2 configuration. Javier - will we be offering access to CoreWebView2CreationProperties.BrowserExecutableFolder or anything else mentioned in the WebView2 Fixed Version docs?

[guardrex]

@MackinnonBuck ... I ended up moving my PTO from today (Tuesday) to Friday. Today is going to be nasty weather-wise. We're under a 🌪️ tornado watch 🌪️😨 right now. Friday looks 🌞, so that's a much better PTO day ... 🏃🌪️ IF I SURVIVE TO SEE IT! 😆

What's the status on this issue? It looks like you're still discussing the coverage.

Also, will this bit of doc work be blocked for the next preview release? If so, I'll work it a few days before release day as a draft PR along with Document security recommendations for remote resources in Blazor Hybrid apps (dotnet/AspNetCore.Docs 25461) that Safia put up. I'll also work Improved non-HTTP(S) link handling behavior (dotnet/AspNetCore.Docs 25432) as a separate draft PR around the same time.

[javiercn]

Tagging @javiercn who is looking into enabling app devs to access more WebView2 configuration. Javier - will we be offering access to CoreWebView2CreationProperties.BrowserExecutableFolder or anything else mentioned in the WebView2 Fixed Version docs?

Yes, I think this should be doable after my change.

We use https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2environment.createasync?view=webview2-dotnet-1.0.1150.38#microsoft-web-webview2-core-corewebview2environment-createasync(system-string-system-string-microsoft-web-webview2-core-corewebview2environmentoptions)

[MackinnonBuck]

@guardrex The part discussing the WebView2 "Fixed Version" distribution mode will only apply after Javier's changes, which will land in RC2, but that might be content we can add after the initial documentation is put up around the same time as Safia's content.

Unless others have any thoughts about the open questions I listed at the end of my first comment, I think this issue is ready to be handled 🙂

[mkArtakMSFT]

@guardrex, @MackinnonBuck should this issue be closed now?

[guardrex]

You can close this. The final update is tracked for RC2 by the docs issue at #25453, which will merely be to un-comment some text in the doc to finish coverage on this.

Sorry ... no ... leave this open. I thought your ping was on the PU issue. I need this for tracking the RC2 final update. It will close at RC2.