#555: feat: native desktop app for Windows + Linux (Tauri)

Context

The macOS desktop app shipped today as a native Swift wrapper. It's a thin native shell: WKWebView + SSH tunnel manager + preferences UI. The architecture is simple, works well, and is ~600 lines of Swift.

We now want the same for Windows and Linux, with the constraint that we don't want to maintain three separate codebases. macOS can stay Swift (it's already shipped and clean). Windows and Linux should share a single architecture.

Options

Option 1: Tauri (Rust + WebView)

Tauri wraps a web frontend in a native WebView — WebView2 on Windows, WebKitGTK on Linux. It uses Rust for the backend (system calls, SSH process, preferences).

Pros:

• Single codebase for Windows + Linux (and optionally macOS later)
• Ships as a single small binary (~5–15MB) — no Electron bloat
• WebView2 on Windows 10+/11 is built-in; WebKitGTK ships with most Linux distros
• Strong GitHub Actions support for cross-platform releases
• Growing ecosystem, actively maintained

Cons:

• Rust learning curve if nobody on the team knows it
• WebKitGTK on Linux can be fiddly (version differences across distros)
• Clipboard paste injection (the 3-strategy JS approach from the Mac app) needs to be re-implemented in Rust/JS interop
• SSH process management in Rust is straightforward but requires std::process::Command

Verdict: Best long-term choice if you're comfortable with Rust or willing to invest. Smallest distributable, no licensing issues, genuinely native.

Option 2: Electron

A Chromium WebView wrapping the hermes-webui frontend, with Node.js for SSH/system integration.

Pros:

• Large ecosystem, lots of prior art for this exact pattern
• Same codebase for Windows, Linux, and macOS if you eventually want to unify
• node-ssh or spawning the system ssh binary both work cleanly
• GitHub Actions cross-compilation is well-documented

Cons:

• ~150–200MB distributable per platform (Chromium bundled)
• Memory overhead — Electron adds ~100MB baseline RAM
• Electron has a reputation that puts some users off
• Requires code signing for both Windows SmartScreen and macOS Gatekeeper

Verdict: Fastest to ship a working app. Not the right long-term fit for a tool like this — the weight is hard to justify for what is essentially a WebView wrapper.

Option 3: .NET MAUI or WPF/WinForms (Windows) + GTK# or Avalonia (Linux) — separate repos

Two separate native apps sharing no code.

Cons: Exactly what we're trying to avoid. Two codebases, two maintenance tracks. Ruled out.

Option 4: Flutter

Cross-platform UI toolkit that compiles to native. Has a WebView plugin.

Cons: Heavy runtime, Dart adds another language, WebView integration is less mature than Tauri or Electron. Not the right tool for a thin shell.

---

Recommendation

Tauri for Windows + Linux. Here's the proposed approach:

• New repo: hermes-webui/hermes-desktop (Windows + Linux, Tauri)
• macOS Swift app stays separate — it's already shipped and clean
• If Tauri proves solid, macOS support can be added to hermes-desktop later as a migration path

Architecture (mirrors the Swift app):

• Tauri shell loads http://localhost:8787 in the system WebView
• Rust backend manages the SSH process (std::process::Command with the same -N -L args)
• Preferences stored in Tauri's built-in tauri-plugin-store (JSON file, equivalent to UserDefaults)
• GitHub Actions: tauri-action handles cross-platform builds for Windows (.msi/.exe) and Linux (.deb/.AppImage)

Distributable size: ~8–12MB vs ~180MB for Electron.

WSL note: For Windows users running hermes-webui inside WSL2, localhost should work with WSL2 mirrored networking. May need a config option for the WSL IP fallback (ties into issue #513).

---

Open questions

1. Does anyone on the contributor side know Rust / want to own this? Or is this something we build ourselves?
2. Should the Windows/Linux app support SSH tunnel mode (same as Mac) or just Direct mode initially?
3. Target Windows 10+ or Windows 11 only? (WebView2 is pre-installed on Win11, needs a bootstrapper on Win10)
4. For Linux: AppImage (universal, no install) or .deb/.rpm packages? AppImage is the lowest-friction path.

Tagging @redsparklabs who built the Swift Mac app — would be great to have the same contributor involved if interested.