Refuse to boot a Tauri v2 app into a below-floor WebView engine, and say how to fix it — natively, before first paint.
The engine version is read natively during plugin setup, which Tauri runs before it creates the first WebView. Below the floor, the WebView's first navigation is refused — the app's bundle is never parsed.
The lifecycle
An Android AlertDialog names the WebView provider and opens its Play Store listing; on iOS an alert says to update iOS. Never "update this app" — the app is current.
The dialog copy
Chromium 111 on Android, iOS 16.4 on iOS, both configurable and inclusive. An unreadable version is Unknown, and the app boots.
Builder options
status() and openUpdate() are generated from the Rust command signatures by tauri-specta, with a tagged error type a frontend can switch on.
The API
| Android, Chromium 109 | Android, Chromium 113 |
|---|---|
 |  |
Both screenshots are the same debug APK, two Chromium majors either side of the default floor. Device verification has all four emulator arms, the iOS simulator, and what each run did and did not prove.
Register the plugin first in src-tauri/src/lib.rs:
tauri::Builder::default()
.plugin(
tauri_plugin_webview_guard::Builder::new()
.min_chromium(111)
.min_ios("16.4")
.build(),
)
// ...That is the whole integration. The guard is live the moment it is registered; to guard nothing, do not register it. Continue with Getting started.