Locara

Tauri

What it is: Rust-based framework for building cross-platform desktop apps (and now mobile) with web frontends. Successor mindset to Electron — same web-frontend developer experience, but small bundles, OS-native webview, and a deliberate capability-based security model. Status: Tauri 2.0 stable since late 2024. Active development, good momentum, good security reputation. Most relevant to Locara: Locara’s runtime / shell. The framework Locara apps will run inside. Worth knowing the security model intimately because Locara’s capability system stacks on top of it.

Background

Tauri started in 2019 to address Electron’s biggest weaknesses: bundle size (Electron ships its own Chromium = 100+ MB minimum), memory footprint, and security via “we just exposed all of Node to the webview” patterns. Tauri uses the OS-native webview (WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux), keeps the backend in Rust, and routes web↔native through a structured IPC channel that’s gated by capabilities.

Tauri 2.0 added mobile (iOS, Android), reworked the security model into the current capabilities/permissions/scopes triad, and stabilized the plugin system.

Key design decisions

  • OS-native webview, not bundled. WKWebView on Mac, WebView2 on Windows. App bundle is small (often < 10MB), and webview vulns are patched by OS vendors, not by app updates.
  • Rust backend. Memory safety, performance, native integration. Frontend is whatever framework you want (React, Vue, Svelte, vanilla).
  • IPC as the trust boundary. Frontend can’t touch system resources directly. It calls Rust invoke('command_name', args), Rust executes, returns. Every command is gated.
  • Capabilities + permissions + scopes (Tauri 2.0):
    • Permissions = atomic privileges (read this file, open this URL, etc.).
    • Capabilities = named groups of permissions assignable to specific windows/contexts.
    • Scopes = parameter-level restrictions (e.g., “permitted to read files matching ~/Documents/**”).
  • Plugins extend the backend. Database, fs, http, shell, etc. are plugins, each with their own permissions surface.
  • No nodeIntegration-style escape hatch. Frontend can never directly use Rust APIs except through declared commands.
  • Cross-platform binaries (Mac universal, Windows MSI, Linux AppImage/deb).
  • Mobile support (Tauri 2.0) — iOS and Android with the same Rust core.
  • MIT/Apache dual license.

What worked

  • Bundle size wins. A “Hello World” Tauri app on Mac is ~10MB; the Electron equivalent is ~140MB. Distribution speed and disk-space friendliness.
  • Memory wins. Tauri uses ~half the RAM of equivalent Electron apps in benchmarks.
  • Capability model is well-designed. The 2.0 redesign is one of the best capability systems in any desktop framework.
  • Real apps shipped: Pop OS Cosmos, Hoppscotch, several real productivity apps, plus Jan.ai (validating the stack for AI apps specifically).
  • Plugin ecosystem growing — official plugins for filesystem, sqlite, http, shell, dialog, notifications, updater, etc.
  • Mobile from one codebase is genuinely useful even if not v1 priority.

What failed / criticisms

  • Native webview inconsistency — Mac WKWebView, Windows WebView2, Linux WebKitGTK all behave subtly differently. CSS, web APIs, and rendering differ. Cross-platform polish requires testing on all three.
  • Linux story is rough — WebKitGTK lags behind, fewer features, maintainership concerns.
  • Smaller ecosystem than Electron. Fewer plugins, fewer Stack Overflow answers, fewer hires.
  • Rust learning curve for backend devs coming from Node. Real cost.
  • Plugin permissions surface is verbose — declaring scopes/permissions can feel bureaucratic for simple apps.
  • Mobile is new — Tauri 2.0 mobile support isn’t yet at the polish level of native iOS/Android dev.
  • Updater plugin gotchas — auto-update is plugin-territory and has edge cases on macOS code-signing.

Specific learnings for Locara

  1. Tauri is the right shell choice. Validates the spec decisions. Real apps proving it works for AI use cases (Jan.ai).
  2. Locara’s capability model = Tauri capabilities + Locara-specific extensions. Map directly:
    • network: false → Tauri capability blocks http plugin.
    • fs.user-selected: true → Tauri’s filesystem plugin scope = $DOCUMENTS/* or whatever user picked.
    • device.camera: true → Tauri’s media plugin permission.
    • llm.chat, llm.embed, etc. → Locara-specific Rust plugin, gated by Locara capability declarations.
  3. The Tauri plugin model is how Locara primitives expose themselves. locara-models, locara-storage, locara-tools are Tauri plugins, with permission surfaces.
  4. Don’t fight native webview differences — embrace them. Locara should target macOS first specifically because WKWebView on Apple Silicon is the best of the three.
  5. Bundle size matters for app distribution. Small Locara apps = fast downloads = better install conversion.
  6. Mobile path exists but plan for it as phase 4+, after the macOS story is solid. The capability-on-iOS constraints are real (no WASM exec, no subprocess).
  7. Use the official updater plugin but plan to wrap it in Locara’s update logic (capability-change detection, cool-down on capability expansion, etc.).
  8. Embed the IPC mental model in the SDK. App authors think “this is a frontend that talks to my Locara backend” — same pattern as plain Tauri.

References