Frontend And Webview Model

Tauri is frontend-agnostic, but it is not frontend-magic. The safest default is a static Vite app loaded into a system webview.

Frontend Choices

Frontend	Fit
React plus Vite	Good lab default because existing React skills transfer
Svelte plus Vite	Good for small desktop UIs with less runtime code
Vue plus Vite	Good if the team already prefers Vue
Solid plus Vite	Good for small reactive UIs and low overhead
Plain TypeScript	Good for utilities and small control panels
Leptos/Trunk	Useful for Rust-heavy teams, but adds a different frontend learning curve
SSR meta-framework	Use only in static output or explicitly supported client-server mode

Static Output Rule

build.frontendDist should point at static assets produced by your frontend build. Do not assume a Node server runs inside the desktop app.

{
  "build": {
    "frontendDist": "../dist",
    "devUrl": "http://localhost:1420",
    "beforeDevCommand": "npm run dev",
    "beforeBuildCommand": "npm run build"
  }
}

Webview Backends

Platform	Webview	Practical effect
Windows	Microsoft Edge WebView2	Runtime install/update choice is part of release planning
macOS/iOS	WKWebView	Safari/WebKit behavior affects CSS, APIs, and automation
Linux	WebKitGTK	Distro packages and WebKitGTK versions affect runtime behavior
Android	Android WebView	Device WebView version and low-end devices matter

Renderer Testing

Use frontend tests for UI logic and mocked IPC. Use WebDriver or release smoke tests for behavior that depends on the real shell, platform webview, menus, dialogs, files, sidecars, or installer.

Practical Constraints

Keep raw invoke calls in a small wrapper module.
Keep secrets out of frontend state and local storage.
Avoid broad CSP relaxations such as release-only unsafe-eval unless you can justify them.
Test CSS and browser APIs on each target webview, not only in Chrome.
For mobile dev, expect extra network/dev-server setup because the device or emulator must reach the dev server.