Tauri's webview layer, version skew, and the mobile gaps the bundle list leaves open

Your frontend arrives over a custom protocol, not a local port

One feature bullet settles a question people usually ask late. Native WebView Protocol is listed with a parenthetical that spells out the whole mechanism: tauri doesn't create a localhost http(s) server to serve the WebView contents. Assets reach the window through a protocol handler rather than an HTTP origin. What that removes is concrete. There is no port to bind, so you cannot attach a proxy, a port forward, or a request log to your own asset traffic the way you can with a served build. What it also means is that the scheme, the origin it presents, and the boundary between what a page inside that window may reach and what it may not are not defined in the introduction. The document offered for how the pieces fit together is ARCHITECTURE.md. Consequence for a reader: if you have a policy that every byte your interface loads passes through an inspectable origin, this is the first line to check.

One version number does not cover the crates

The workspace pins each crate to its own track, so matching on a single version string will not validate a lockfile. A build dependency reading 2.7.4 is not an old Tauri release, it is the current tauri-build.

tauri = { version = "2.12.0", path = "./crates/tauri", default-features = false }
tauri-runtime = { version = "~2.12.0", path = "./crates/tauri-runtime" }
tauri-utils = { version = "~2.10.0", path = "./crates/tauri-utils" }

The newest releases listed are tauri-v2.12.5 and the CLI packages at 2.12.4, all on 2026-10-21, and the manifest above points at tauri 2.12.5. Consequence: a dependency tree that looks inconsistent is often correct.

The bundle formats stop at the desktop

The built-in bundler is described with an explicit list: .app, .dmg, .deb, .rpm, .AppImage, and Windows installers built with NSIS for .exe and WiX for .msi. Both iOS and Android appear in the platform table as supported for development and distribution, yet no .ipa, .aab or .apk appears anywhere in that list, and no Flatpak, Snap, MSIX or AppX does either. The mobile gap is the one that costs you planning time, because a store submission needs its own package format and its own signing step, and this list names the tooling for neither. Consequence for a reader: the artifact names you can verify here cover desktop packaging only. Anyone planning a phone release has to source the mobile packaging path separately instead of assuming the bundler already reaches it.

The self updater is marked desktop only

The README marks one feature desktop only and does not expand on it: built-in self updater (desktop only). Read literally, that leaves iOS and Android without the in-app update path the desktop builds get, which puts mobile updates wherever the platform already requires them to be. The feature list names no replacement for mobile, so there is no pointer here to a plugin, a store helper, or a periodic version check that would close the gap. The same bullet presents the updater as built in rather than as something you install, which means the mobile answer is not a package you add to your manifest either. Consequence: if your product depends on a controlled rollout, you source that on the mobile side yourself, and nothing in this list gives you an error message, a fallback, or a documented absence to plan around.

Linux builds are tied to one webkit2gtk generation

The platform table splits Linux by webview generation rather than by distribution. Tauri v1 wants webkit2gtk 4.0, with Ubuntu 18.04 given as the example, and Tauri v2 wants webkit2gtk 4.1, with Ubuntu 22.04 as the example. Moving a v1 application to v2 therefore raises the system library requirement instead of only bumping crate versions, and the row itself tells you a v1 build and a v2 build cannot share one old Linux baseline. No row describes a bundled or vendored webview, so there is no stated fallback for a distribution that ships neither generation. The renderer here is WebKitGTK, one of four system webviews named alongside WKWebView, WebView2 and the Android System WebView. Consequence: on Linux your minimum operating system is set by a system library rather than by your code, so a build that opens on your machine can fail on a machine one distribution older.

The quickstart lands on v2 docs while v3 is an alpha

The starting point is one command, and the prerequisites page comes first.

npm create tauri-app@latest

The command generates a project, but the documentation it points to is versioned, and the quickstart link is v2.tauri.app/start/prerequisites/ while the default branch is dev. Documentation is also deliberately kept out of this repository: the project states it prefers inline documentation in the Rust and JS source, and points to github.com/tauri-apps/tauri-docs for the site, with no docs directory in the root here. Two features are named only as descriptions, a GitHub action for streamlined CI and a VS Code extension, with no action name, extension name, or marketplace entry given. Consequence: the docs you land on can describe a different major line than the one you pinned, and wiring up CI or an editor means leaving this material and searching.

The code license and the logo license are different grants

Code is MIT or MIT/Apache 2.0 where applicable, held by the Tauri Programme within The Commons Conservancy, and the manifest states Apache-2.0 OR MIT. The logo is a separate grant, CC-BY-NC-ND, credited to three named designers. That split has a practical edge. Apache-2.0 or MIT place no restriction on commercial use of the code, but the two licenses are granted separately and the logo grant carries its own clauses: NC and ND mean the mark cannot be used commercially and cannot be adapted, so a rebrand, a recolor, or a dark mode inversion of the official logo falls outside what the code license covers. The repository license field also reports Apache-2.0 alone, so automated scanning reads one option where the licensing text names two. Consequence: attaching the Tauri logo to a commercial product is a licensing question the code license does not answer for you.

A Windows build inherits an unanswered WebView2 question

Windows 10 and above is the listed floor, and the renderer on Windows is WebView2. Those two lines sit next to each other in the README's own table and neither one explains the runtime. Nothing stated here says whether WebView2 must already be installed on the target machine, whether the application bootstraps it on first launch, or what a fixed version installer is called, and the Windows artifacts named are an .exe produced by NSIS and an .msi produced by WiX. That leaves a real unknown in a build story, because the GitHub action bullet promises streamlined CI without stating what the runner image is expected to carry. macOS by contrast names WKWebView, which is part of the system, and Linux names a library version outright. Consequence: for a Windows release, establish the runtime assumption yourself before trusting a clean machine, since both the platform table and the bundle list stop short of answering it.

Editorial conclusion

Tauri fits when you want a Rust backend and a thin binary, and you accept that the system webview sets your rendering floor, that the crate versions will not line up, and that mobile packaging and mobile updates both live outside what this repository lists. Before committing, work out which webkit2gtk generation your oldest Linux user has, find the mobile packaging path the bundle list does not name, and decide what replaces the desktop only self updater on phones. Read the logo license separately from the code license before you attach the mark to a commercial product.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes