Coder Legion - Recent posts tagged tauri

I built a CLI to test Tauri apps because nothing else worked

Tue, 21 Apr 2026 10:31:42 +0000

I spent a weekend trying to set up end-to-end testing for a Tauri v2 app. Two hours into configuring WebdriverIO, I still couldn't get it to connect to the WebView. The official docs show a minimal example that doesn't cover IPC testing. Playwright flat-out doesn't work because Tauri uses WebKitGTK, not Chromium.

I gave up and wrote my own tool.

The actual problem

If you search "Tauri e2e testing" on GitHub, you'll find the same question asked over and over. The official docs split testing into two worlds: Rust unit tests for the backend, and WebDriver-based tests for the frontend. But nobody tells you how to verify that your Tauri IPC commands actually work from the user's perspective. You end up mocking window.__TAURI__ in your frontend tests and hoping production behaves the same way.

It doesn't always behave the same way.

What I wanted was simple: connect to a running Tauri app, inspect the UI, click buttons, fill forms, and check that things happened. Like Playwright, but for Tauri. No WebDriver binary. No Selenium. No 200-line config file.

What tauri-pilot does

tauri-pilot is a Rust CLI that talks to your Tauri app over a Unix socket. You add a plugin to your app (2 lines, debug builds only), install the CLI, and start testing.

$ tauri-pilot snapshot -i
- heading "PR Dashboard" [ref=e1]
- textbox "Search PRs" [ref=e2] value=""
- button "Refresh" [ref=e3]
- list "PR List" [ref=e4]
  - listitem "fix: resolve memory leak #142" [ref=e5]
  - listitem "feat: add workspace support #138" [ref=e6]
- button "Load More" [ref=e7]

That snapshot command walks the accessibility tree and gives every interactive element a short ref like @e3. You use those refs to interact:

$ tauri-pilot click @e3
ok

$ tauri-pilot fill @e2 "workspace"
ok

$ tauri-pilot assert text @e1 "PR Dashboard"
ok

$ tauri-pilot assert visible @e7
ok

Exit code 0 means pass. Exit code 1 means fail with a message. That's it. No test framework to learn.

Setup takes 2 minutes

Add the plugin to your Tauri app:

// src-tauri/src/main.rs
fn main() {
    let mut builder = tauri::Builder::default();

    #[cfg(debug_assertions)]
    {
        builder = builder.plugin(tauri_plugin_pilot::init());
    }

    builder.run(tauri::generate_context!()).expect("error running app");
}

Install the CLI:

cargo install tauri-pilot

Run your app in dev mode. That's it. tauri-pilot ping should respond.

The plugin only compiles in debug builds. It won't end up in your release binary.

Why not just use WebdriverIO?

I tried. Here's what the experience looks like:

With WebdriverIO, you need to install Node.js dependencies, configure wdio.conf.ts, point it at your built binary (not the dev server), make sure the WebDriver binary matches your WebKit version, write tests in JavaScript even though your app is in Rust, and deal with flaky selectors that break when your UI changes.

With tauri-pilot, you run cargo install tauri-pilot, add 2 lines to your app, and start writing shell commands. The accessibility tree refs (@e1, @e2) are stable across renders as long as the element exists. You can use CSS selectors too, or pixel coordinates for edge cases.

The diff command is something WebdriverIO can't do at all:

$ tauri-pilot diff -i
+ button "New PR" [ref=e8]
~ list "PR List" [ref=e4]: children 2 → 3

It compares the current UI state to the previous snapshot and shows only what changed. When you're debugging a UI issue, that's worth more than any assertion framework.

It's built for AI agents

I initially built tauri-pilot so Claude Code could interact with my Tauri apps. The output format is designed for LLM consumption: compact accessibility tree, short refs, plain text responses.

An AI agent's workflow looks like:

snapshot -i to understand the current page
Pick a ref from the output and interact with it
assert to verify the result
diff -i to see what changed without re-reading the entire tree (saves tokens)

The --json flag on every command gives structured output for programmatic use.

But you don't need an AI agent to benefit from this. I use tauri-pilot directly in bash scripts and interactively while developing. It's faster than clicking through the UI manually when I'm testing a form flow for the fifth time.

What's in v0.2.0

The latest release (just shipped) adds:

Record/replay — tauri-pilot record start, interact with your app, record stop --output test.json, then replay test.json to rerun the whole session. Export to a shell script with replay --export sh.
Multi-window support — windows lists all windows, --window flag targets a specific one.
Form dump — forms grabs all form fields at once instead of calling value on each input.
localStorage/sessionStorage access — storage get "token", storage set "key" "value", storage list, storage clear.
Drag & drop — drag @e5 @e6 for sortable lists, drop @e3 --file ./image.png for file upload zones.
DOM watch — watch blocks until a DOM mutation happens, then prints a summary. Good for waiting on async updates.

The full changelog is on GitHub.

How it works under the hood

The plugin starts a Unix socket server when your app launches. The CLI connects to that socket and sends JSON-RPC messages. The plugin injects a JS bridge (window.__PILOT__) into the WebView that handles DOM inspection.

The tricky part was getting return values from webview.eval(). In Tauri v2, eval() is fire-and-forget. There's no way to get a result back directly. So every JS evaluation wraps the script in a try/catch, calls back into Rust via IPC (invoke('plugin:pilot|__callback', {id, result})), and the Rust side waits on a oneshot channel with a 10-second timeout.

It works reliably. I've been running it daily for weeks.

Limitations

Linux only for now. Tauri uses WebKitGTK on Linux, WKWebView on macOS, and WebView2 on Windows. The socket and JS bridge approach should work on all platforms, but I haven't tested it. macOS and Windows support is planned.

The screenshot command uses html-to-image bundled into the JS bridge, which means it captures the WebView content but not native window decorations or system dialogs.

And it's pre-1.0. The API might change. I'm using semver, so minor bumps can include breaking changes until 1.0.

Try it

cargo install tauri-pilot

GitHub: github.com/mpiton/tauri-pilot
Docs: mpiton.github.io/tauri-pilot
crates.io: crates.io/crates/tauri-plugin-pilot

If you're testing a Tauri v2 app on Linux, give it a shot. Issues and PRs are open.

Cross-Platform Desktop Wars: Electron vs Tauri: How do you explain the tradeoffs to users?

Tue, 14 Apr 2026 07:12:44 +0000

Hello,

I am writing cause I wanted to get some opinions from folks here that have actually built and shipped with Electron (or Tauri).

Background: Building an API IDE on Electron. Not really “just an API client”, and not a(nother) thin wrapper around a webapp either. It’s a pretty original desktop tool with a lot of editor/IDE-like behavior - not the typical form centric behavior that postman or others have: local workflows, richer interactions, and some things that honestly would have been much harder for us to build and iterate on this quickly in a more constrained setup. Thats why Electron.

this is the tool:

https://github.com/VoidenHQ/voiden

Now, as adoption is growing, we are starting to get the usual questions about memory footprint and app size.

The (slightly) frustrating part is this:

When the app is actually being used, the app-side memory is often pretty reasonable. In many normal cases we are seeing something like 50–60 MB for the actual usage we care about (even added it in the app itself for people to check it out).

But then people open Activity Monitor, see all the Chromium/Electron-related processes, and the conversation immediately becomes:

“yeah but Tauri would use way less”

And then, without realizing, I suddenly end up talking and philosophizing about Electron, instead of discussing the tool itself (which is what I am passionate about :)

And of course, I get it. The broader footprint is real. Chromium is not free. Electron has overhead. Pretending otherwise would be foolish. So we are constantly optimizing what we can, and we will keep doing so…

At the same time, I do feel that a lot of these comparisons feel weirdly flattened. For example people often compare:

full Electron process footprint VS the smallest possible Tauri/native mental model

…without always accounting for development speed, cross-platform consistency, ecosystem maturity, plugin/runtime complexity, UI flexibility, and the fact that some apps are doing much more than others. Which is by the way the reason that we went with Electron.

So all this context to get to my real question, which is:

How do you explain this tradeoff to users in a way that feels honest and understandable, without sounding like you are making excuses for Electron?
And also, for those of you who have had this conversation a hundred times already:

What do you say when people reduce the whole discussion to “Electron bad, Tauri good”?

Have you found a good way to explain footprint in practical terms?

Where do you think optimization actually matters, vs where people are mostly reacting to the idea of Electron?

Mostly trying to learn how others think about this , especially those who have built more serious desktop products and had to answer these questions in the wild.

Would love your thoughts and advice!

Here is the Kimi Desktop on Ubuntu 26.04 noone asked for..... Because I am creating 1 desktop a day

Tue, 14 Apr 2026 03:17:32 +0000

I decided I am going to create 1 desktop app a day for the new Ubuntu release because noone ships linux. It's crazy they expect us to dev in linux but ship for windows and mac but you know what ? I am tired of bouncing back and forth! Linux for this windows for that ohhh check in on the kids switch to mac. It;s enough. So here is app 5 (if you dont count the Voicebox I made earlier today because their junk was busted and their instructions were just build it from source... Yeah thanks Chad...Here ya go. "Kimi Desktop on Ubuntu 26.04: Fixing the Broken .deb with Tauri v2"

"The official Kimi desktop app can't install on Ubuntu 24.04+ because it depends on a removed library. Here's how I rebuilt it with Tauri v2 and Pake v3 to fix it."

You install the official Kimi desktop .deb, fire sudo dpkg -i, and boom:

dpkg: dependency problems prevent configuration of kimi:
 kimi depends on libwebkit2gtk-4.0-37; however:
  Package libwebkit2gtk-4.0-37 is not installed.

That library doesn't exist on Ubuntu 24.04, let alone 26.04. It was removed from the repos over a year ago. The official Kimi desktop package is built on Tauri v1, which hard-depends on libwebkit2gtk-4.0.so.37 — a library that shipped with webkit2gtk 4.0, superseded by 4.1 and then dropped entirely.

So the app is just... broken on any modern Ubuntu. Here's how I fixed it.

The problem in one sentence

Tauri v1 → libwebkit2gtk-4.0 → removed from Ubuntu 24.04+ → dpkg fails.

The fix: rebuild with Tauri v2

Tauri v2 links against libwebkit2gtk-4.1, which is the version shipped in Ubuntu 24.04 and 26.04. So the fix is straightforward: rebuild the app with Tauri v2 instead of v1.

I used Pake v3, which wraps any web app into a native desktop app using Tauri under the hood. One build script, one config file, and you get a .deb that actually installs.

What you get

Tauri v2 runtime — Links against libwebkit2gtk-4.1, the one Ubuntu actually ships

OAuth / SSO — --new-window flag means Google sign-in works in-app instead of being blocked

System tray — Desktop integration that works

1200x780 window — Matches the original Kimi desktop dimensions

Rebuild it yourself

Prerequisites — Rust, Node, and the usual GTK/webkit dev packages:

# Rust >= 1.85
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Node.js >= 22 — use nvm, brew, whatever you prefer

# Build deps
sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev \
  libayatana-appindicator3-dev librsvg2-dev

# Pake CLI
npm install -g pake-cli

Then it's one command:

./build.sh

The .deb lands in dist/. Install it:

sudo dpkg -i dist/kimi_1.0.0_amd64.deb

Done. Kimi runs natively on Ubuntu 26.04 with no missing libraries.

The config that makes it work

Everything lives in config/pake.json. The important bits:

{
  "windows": [{
    "url": "https://kimi.moonshot.cn",
    "new_window": true,
    "width": 1200,
    "height": 780
  }],
  "user_agent": {
    "linux": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
  }
}

The two things that matter:

new_window: true — Without this, OAuth popups (Google sign-in, etc.) get blocked by the webview's navigation policy. This flag tells Pake/Tauri to open them in a new window instead.
user_agent.linux — Spoofing a Chrome UA because some OAuth providers reject webview user agents.

Why not just use the web app in a browser?

Fair question. A native desktop app gives you:

Alt-Tab separation — Kimi isn't buried among 40 browser tabs
System tray — Quick access, stays running in the background
Own window chrome — Feels like an app, not a tab
Smaller memory footprint — Tauri uses the system webview, not a bundled Electron instance

The repo

github.com/johnohhh1/kimi-app

Clone it, build it, install it. If you're on Ubuntu 24.04+ and want Kimi as a desktop app, this is currently the only way that works.

Uninstall

If you need to remove it:

sudo dpkg -r kimi

Kimi is a product of Moonshot AI. This project uses the open-source Pake tool (MIT license) to wrap the Kimi web interface as a native desktop application.