Rust Tauri Apps

Rust Tauri Apps

Build Tauri v2 applications with small Rust command surfaces, secure capabilities, explicit IPC contracts, and maintainable distribution workflows.

Operating Model

1. Inspect the Tauri version and generated structure first: src-tauri, tauri.conf.json, capabilities, permissions, plugins, frontend invocation code, and CI/release scripts. 2. Treat every command as a public bridge contract. Validate input, return typed serializable results, and keep filesystem/shell/network capabilities narrow. 3. Prefer app-owned Rust services behind commands. Do not put large domain logic directly in #[tauri::command] functions. 4. Keep the capability model least-privilege by default. Avoid broad filesystem, shell, opener, and dialog permissions unless the user workflow truly needs them. 5. Coordinate with the general tauri-v2 skill when available for framework-specific current docs; use this skill for Rust architecture, security, testing, and command design.

Reference Map

• references/tauri-v2-rust-backend.md for command/state/plugin architecture and typed IPC.
• references/capabilities-security.md for permissions, filesystem/shell risk, secrets, updater, and secure defaults.
• references/distribution-mobile.md for bundling, updater, sidecars, signing, desktop/mobile packaging, and release checks.

Defaults

• Keep commands async only when they await I/O. Do CPU-heavy work off the main runtime.
• Use serde DTOs at the IPC boundary and convert to domain types inside services.
• Use tauri::State for shared app services with clear ownership; avoid global mutable statics.
• Use plugin APIs instead of hand-rolled platform code when mature official plugins cover the use case.
• Keep frontend-originated paths, URLs, and shell arguments untrusted until validated.

Verification

Use repo-native checks first, then add Tauri-specific validation:

cargo fmt --all --check
cargo test --manifest-path src-tauri/Cargo.toml --all-targets
cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets --all-features -- -D warnings

For command changes, add Rust tests around service behavior and frontend tests or contract fixtures for IPC shapes when the app already has a frontend test lane.

Capabilities and Security

Least Privilege

Capabilities are part of the app security boundary. Keep them narrow:

• Limit filesystem scope to required directories.
• Avoid shell permissions unless there is a clear user workflow and strict argument validation.
• Prefer opener/dialog plugins over custom shell calls.
• Gate dangerous commands behind explicit UI actions and clear confirmation.

Input Validation

Treat frontend input as untrusted:

• Normalize and validate paths.
• Reject traversal outside allowed roots.
• Validate URLs, schemes, and hosts.
• Validate command arguments as data, not strings to concatenate.
• Enforce file size and content type limits when reading user-selected files.

Secrets

Do not send secrets to the frontend unless the frontend must display them. Prefer platform keychain/secure storage plugins for durable secrets and short-lived in-memory tokens for command work.

Updater

Updater configuration should be explicit:

• signed update artifacts
• stable channels
• clear rollback plan
• environment-specific endpoints
• tests or smoke scripts for update metadata

Audit Checklist

Before shipping risky permissions, answer:

• Which user action requires this capability?
• What exact paths, commands, or hosts are allowed?
• What happens if the frontend is compromised?
• Is there an official plugin with a smaller permission surface?

Distribution and Mobile

Desktop Packaging

For release work, inspect existing scripts before changing Tauri config. Common checks:

• cargo test and cargo clippy in src-tauri
• frontend build
• tauri build for target platforms
• signing/notarization configuration where required
• installer metadata and icons
• update artifacts and signatures

Sidecars

Sidecars need explicit lifecycle ownership:

• versioned binary source
• checksum verification
• platform-specific paths
• startup/shutdown behavior
• stdout/stderr capture policy
• failure reporting

Do not shell out to arbitrary paths supplied by the frontend.

Mobile

When mobile is in scope:

• Confirm plugin mobile support.
• Audit permissions separately for iOS and Android.
• Keep filesystem assumptions platform-aware.
• Test deep links, notifications, and secure storage on real/simulator lanes where available.

Release Automation

Prefer reproducible release scripts over hand-run build sequences. Keep secrets in CI secret stores and avoid local-only signing assumptions unless the project intentionally releases manually.

Tauri v2 Rust Backend

Command Shape

Keep commands as thin adapters:

1. Deserialize DTOs. 2. Validate frontend-provided values. 3. Call an app-owned service. 4. Map domain result/error into a stable IPC response.

Avoid embedding business logic, filesystem traversal, or subprocess orchestration directly in command functions.

IPC Contracts

• Use explicit request/response structs for anything beyond trivial commands.
• Keep field names stable and documented through TypeScript bindings or generated fixtures where the repo supports it.
• Return structured errors instead of stringly catch-all failures when the frontend branches on error kind.
• Do not leak internal paths, tokens, or raw subprocess output unless the UI explicitly needs them.

App State

Use tauri::State for shared clients, stores, and services. Make ownership clear:

• immutable config
• async clients with internal pooling
• mutex-protected mutable state only when truly shared
• channels for background workers

Avoid global mutable statics. If singletons are needed, initialize them in app setup and inject them through state.

Plugins

Prefer maintained Tauri plugins for common platform features. Before adding a plugin:

• Check current Tauri v2 compatibility.
• Review required permissions.
• Confirm mobile/desktop support if cross-platform is needed.
• Add only the plugin surface actually used.

Frontend Bridge

Keep invoke names centralized in frontend code. For larger apps, generate or hand-maintain a small typed client module rather than scattering raw string command names.