Decision Guide
Pick Tauri when the product is desktop-first, the UI can be a static web app, and the native authority surface can stay small.
Default Recommendation
For lab projects, choose Tauri 2 for local-first desktop tools and AI/native utilities. Do not choose it as the first mobile stack unless desktop is already the primary product and mobile is a constrained companion.
Stack Comparison
| Option | Choose it when | Avoid it when |
|---|---|---|
| Tauri 2 | You want small desktop bundles, web UI velocity, Rust commands, plugins, and native sidecars | Mobile-first native APIs, rendering uniformity, or broad shell/filesystem authority dominate |
| Electron | You need one bundled Chromium engine, mature desktop ecosystem, and predictable rendering | Bundle size, memory, or Chromium patch responsibility are unacceptable |
| Native desktop | Platform-native UX and OS APIs matter more than shared UI | You need one cross-platform UI codebase quickly |
| PWA | Web reach, installability, and no desktop installer are enough | You need native filesystem/process/tray/integration beyond browser APIs |
| React Native or Expo | Mobile-first Android/iOS with one JavaScript UI is the goal | Desktop native integration is the first product surface |
| Flutter | You want a shared custom-rendered UI across mobile, desktop, and web | You need native webview semantics or minimal desktop shell size |
| Android Kotlin Compose | Android is the main product and Play policy/native behavior matter | Desktop is the main product |
| Windows App SDK | Windows-first desktop and deep Windows APIs matter | macOS/Linux support is required in v1 |
Strong Tauri Shapes
| App shape | Why Tauri fits |
|---|---|
| Local-first desktop utility | Rust commands own files, SQLite, exports, backups, and OS dialogs |
| AI model manager | Rust core can supervise local sidecars and keep tokens out of the renderer |
| Internal operator console | Vite UI ships fast, native shell stays small, installer can be internal-only |
| Cross-platform desktop companion | Same UI plus platform-specific config and capabilities |
Weak Tauri Shapes
| App shape | Better default |
|---|---|
| Mobile-first app with background work, deep permissions, and store complexity | Android Kotlin Compose, SwiftUI, Expo, or Flutter |
| Pixel-perfect cross-platform desktop app with heavy canvas/rendering needs | Electron or Flutter |
| Web admin tool with no native authority | PWA or normal web app |
| App that must execute arbitrary user commands | Re-scope the product; broad shell authority is a security design problem |
Decision Checklist
Answer these before choosing Tauri:
Primary surface: desktop, mobile, or web?
Native authority: which exact OS operations are needed?
Frontend output: can the UI build to static assets?
Security boundary: which commands/plugins/scopes does each window need?
Sidecars: can every binary, argument, port, and cleanup path be justified?
Release: which target OS can produce and smoke-test the artifact?
Mobile: which plugins and permissions are verified on Android/iOS?If any answer is unknown, Tauri may still be right, but the next step is research or a prototype, not app implementation.
Gotcha: Tauri’s smaller app size comes from using the OS webview. That is a tradeoff. You gain smaller bundles and OS/runtime webview patching, but you must test WebView2, WKWebView, WebKitGTK, and Android WebView behavior separately.