Tauri 2
Use Tauri 2 when you want a small desktop app with web UI speed and native OS access, and you are willing to design a narrow Rust-backed authority boundary.
Good fits:
- Local-first desktop tools with SQLite, file access, tray/menu integration, notifications, or native dialogs.
- AI-native utilities that need to manage local model servers, MCP servers, CLIs, or other sidecar processes.
- Internal tools where the desktop app is the product and mobile is a later smoke path, not the first market.
- Cross-platform desktop apps where smaller bundles and OS-managed webviews matter more than identical rendering across every machine.
Weak fits:
- Mobile-first consumer apps that need deep native APIs, background services, store-policy nuance, and low-end-device performance from day one.
- Apps where pixel-identical rendering is more important than bundle size. Electron can be simpler when one Chromium engine is a product requirement.
- Apps that need many broad shell, filesystem, HTTP, asset, or localhost permissions but cannot justify and test each one.
- Teams that cannot test release artifacts on the actual target OS.
Stack Shape
| Layer | Default | Why |
|---|---|---|
| Frontend | Vite plus React, Svelte, Vue, Solid, or plain TypeScript | Tauri behaves like a static web host; Vite keeps SPA builds predictable |
| Native core | Rust under src-tauri/ | Commands, state, plugins, windows, sidecars, secrets, and OS authority live here |
| IPC | Typed frontend wrapper over invoke | Keeps the webview from knowing raw command names and payload details everywhere |
| Security | Capabilities, permissions, scopes, CSP, and asset-protocol review | Tauri 2 access control is explicit per window/webview and per plugin command |
| Persistence | Rust state plus Store, SQL, filesystem, or app-specific data layer | Keep secrets and trusted state out of the renderer |
| Native integration | Official plugins first, custom plugins when commands become a reusable boundary | Plugins are the long-term boundary for native APIs and mobile bridges |
| Sidecars | Desktop-only until proved otherwise | Sidecars add process, update, signing, antivirus, and permission complexity |
| Release | OS signing plus separate updater signing | Code signing and Tauri updater signatures solve different problems |
| Testing | Rust tests, frontend IPC mocks, WebDriver smoke, release artifact smoke | Dev-server success is not release evidence |
First Pages To Read
- Docs index
- Decision guide
- Starter shape
- Commands
- Quality gates
- Pitfalls
- Agent guardrails
- Process and trust boundaries
- Rust backend and commands
- Frontend and webview model
- Capabilities, permissions, and scopes
- Plugins, sidecars, and mobile
- Package, sign, and update desktop
- Test Tauri apps
- Mobile maturity and plugin gaps
Recommended Default
Start desktop-first:
- Build a Vite frontend that emits static assets.
- Put OS authority behind a few Rust commands.
- Wrap
invokein typed frontend functions. - Add one capability file for the main window and keep permissions narrow.
- Add plugins only when a maintained official plugin fits the job.
- Add sidecars only after you can name the binary, arguments, lifecycle, logs, cleanup, and release packaging plan.
- Treat Android/iOS as a separate platform proof, not an automatic extension of desktop success.
Gotcha: A Tauri app is not just a website in a window. The Rust core has full system access. The webview should receive only the commands, plugin permissions, URLs, and file scopes that the current window actually needs.
Minimum Done Criteria
Do not call a Tauri feature or app ready until the relevant gates are true:
| Area | Proof |
|---|---|
| Architecture | Command, plugin, sidecar, and frontend responsibilities are documented |
| Rust backend | Commands validate inputs and Rust tests cover core logic |
| Frontend | IPC wrapper has unit tests with mocked Tauri IPC |
| Security | Capabilities, permissions, scopes, CSP, asset protocol, and remote URLs were reviewed |
| Sidecars | Target-triple binaries, allowed args, spawn/execute permissions, logs, and cleanup are tested |
| Desktop release | Release artifact was built and smoke-tested on the target OS |
| Signing | OS signing and updater signing state are explicit, even if unsigned for internal builds |
| WebView2 | Windows install mode and clean-machine behavior are recorded |
| Mobile | Android/iOS plugins, permissions, signing, store policy, and device smoke were verified separately |