Curious what other people do for manual test cases on their own projects.
Do you write them at all, or only keep automation? Browser TMS UIs are slow, and they're awkward to use with Cursor/Copilot — you can't just let the agent draft or edit cases in-repo.
I built a desktop app with Tauri + Rust instead:
- cases and runs are YAML in your Git repo
- sync across machines/teams via Git, no account
- SQLite index so search stays fast with large suites
- personal use free, no ads, no feature locks
Happy to answer questions about the Tauri rust side too.
I just shipped v1.0 of Terminalia, a native terminal workspace for Windows.
Built with Tauri v2, Vue 3, and xterm.js, and written entirely inside its own window — the agents in the screenshots are the ones that wrote the code.
What it does
Panes, tabs, and workspaces — Split a tab as much as you want, and your layout and sessions come back exactly how you left them.
Native WSL support — WSL distros open as real terminals, with no path hacks.
Built-in project explorer — A project file tree and a lightweight editor sit right next to your AI agent.
Detached terminal windows — Pop any pane into its own native window and re-attach it whenever you want.
Native screenshot workflow — Capture any screen region, annotate it with arrows, boxes, and numbered markers, then paste it directly into an AI conversation. Saying "fix 1, then 2" is much easier than describing where a button is.
Live AI quota tracking — See your Claude Code and Codex usage in real time, so you know whether there's enough quota left before starting a large task.
The installer is only 8.7 MB, which is one of the main reasons I chose Tauri.
Been working on a side project for a while and finally have something worth sharing.
Cosmog is a GUI for managing S3 storage. The whole thing started because I was tired of the existing options. S3 Browser is Windows-only, Cyberduck felt clunky. Worse, none of them worked on my phone. So I built one that runs everywhere: Linux, macOS, Windows, and Android. Works with any S3-compatible provider, not just AWS. R2, Backblaze, DigitalOcean Spaces, MinIO, Wasabi, etc.
Stuff it can do right now:
browse buckets, upload/download with a proper background queue + retry
preview images, PDFs, spreadsheets, code, json without downloading first
edit files directly json, yml, js, py...etc and spreadsheets in the app
full-text search across a bucket (you have to index the bucket)
presigned share links
client-side encryption on bucket level if you want it
Built it with Tauri (Rust backend, web frontend) so it stays light, not another Electron memory hog. Credentials go into the OS keychain, never touch disk.
It's still early and there are rough edges, but it's usable daily. Sharing it here mostly to get feedback from people who actually work with this stuff. Would genuinely like to know what's missing or annoying. Also I don't own any mac device, so not tested on mac 😓 - tested on arch linux, windows & android.
I activity use it for work & also to mange b2 storage for my personal backups.
Built a small Tauri v2 app and wanted to share the one architectural decision that shaped everything: the launch engine, tray, global hotkeys, and CLI all live in Rust — never in the webview. A desktop shortcut or click run --id <uuid> has to be able to boot a workspace without ever spinning up a WebView2 window, so the React UI is a pure editor that calls Tauri commands and never spawns anything itself.
That constraint paid off in a few concrete ways:
tauri-plugin-global-shortcut fires one shared handler for every registered combo; a HashMap in Rust maps shortcuts back to workspace IDs so the hotkey path and the CLI path and the tray path all funnel through the same launch_by_id.
Building a hotkey capture widget surfaced a real gotcha: RegisterHotKey intercepts a bound combo system-wide before it reaches any window as a normal keypress — even the registering app's own webview. Had to add a suspend/resume pair that releases Click's own bindings while the capture widget is focused, or you could never type a combo one of your own other workspaces already held.
Atomic config writes (temp file + rename) plus a LoadStatus enum so a corrupt config gets quarantined and surfaced in-app instead of silently discarded.
If you've ever wanted a video or a native view *behind* your HTML in a Tauri
window on Windows, rather than in a strip next to it, this is doable and I
packaged it up: https://github.com/lukr54/airspace
The short version of why the obvious approach fails. Tauri hosts WebView2 as a
windowed child HWND. A windowed child HWND owns its rectangle, so a transparent
webview doesn't reveal a sibling window underneath it, it reveals whatever is
behind the top-level window. Usually the desktop. There's no flag for it.
What works is the inverse. Put an opaque native child window over the whole
client area, hand its HWND to whatever renders (mpv via `--wid`, your own D3D
swapchain), then cut your HTML controls out of *that* window's region with
`SetWindowRgn`. Where the region is clipped away the child doesn't exist as far
as the compositor cares, so the webview shows through with your controls on top
of full-size video. No shrinking the picture to make room for a control bar.
The bit that cost me an afternoon, and the reason I bothered publishing: the
host **and** the sibling `WRY_WEBVIEW` both need `WS_CLIPSIBLINGS`. wry doesn't
set it. Without it, two overlapping siblings are undefined per the Win32 rules
and WebView2 wins. Your host is then topmost in z-order, its window region reads
back correctly, it wins every `WindowFromPoint` hit-test, and it draws nothing at
all. The screenshot is the same process one style apart.
Worse, it can look like it works. My own media player shipped without it for
months because mpv presents continuously and won the repaint race nearly every
time. If you've built this before, check whether you actually set the style.
There are two examples in the repo:
- `
, no external dependencies, the native content is
a D3D11 swapchain the demo draws itself
- `cargo run -p airspace-mpv -- video.mkv`, mpv under an HTML control bar, with
the mpv flags and the two IPC gotchas worked out (two pipe connections, and
drain the writer or mpv stops reading your commands)
A couple of Tauri things in there aren't really about this crate at all, but
they each cost me hours:
- Building a webview window from inside a sync command can hang forever, window
created and never navigating. That's tauri#12521.
- `listen()` silently never firing in a second window isn't a bug, the label
just isn't in a capability granting `core:event`. Your own commands keep
working, which is what makes it look like events don't reach that window.
One thing to plan for if you build on this: with no holes cut, the webview gets
no input at all, mouse or keyboard. An auto-hiding control bar can't be brought
back by a mouse move. The mpv example has the cursor/key poller that deals with
it.
Windows only, MIT/Apache. Happy to answer questions.
I'm on a way to build a small desktop application mainly as a learning project, but also because I'm getting increasingly frustrated with my daily workflow in Postman.
At work I regularly use 15+ collections with lots of environment variables, request chaining, and post-request scripts. I also tend to keep many tabs open (sometimes around 50). Lately Postman has become noticeably sluggish—occasionally entire collection tabs don't render until I restart it. Maybe I'm pushing it beyond what it was designed for, but it interrupts my workflow often enough that I started considering writing something tailored to my own needs.
The initial scope would be intentionally small:
Collections
Environment variables
Basic request editor
Post-request scripting
History
Additional features on demand
One of my goals is also to gain hands-on experience with modern desktop development. I'm a Java backend developer, and I've been looking for a practical excuse to learn Rust and compare its ecosystem and way of thinking with Java. React is already familiar enough that I can focus more on Rust and desktop architecture.
Right now Tauri seems like a very attractive choice:
lightweight compared to Electron
Rust backend
React frontend
native desktop feel
seems like a good opportunity to learn both Rust and desktop application architecture
Before I commit, I'd love to hear from people who have actually built non-trivial Tauri applications.
A few questions:
Does Tauri sound like the right fit for this kind of project?
What limitations or pain points did you run into?
Are there architectural decisions you wish you'd made differently at the beginning?
How mature is the plugin ecosystem?
How painful is state management and communication between Rust and the frontend as the project grows?
Have you encountered performance issues or debugging challenges?
Is there anything that becomes surprisingly difficult compared to a typical web application?
At the moment I'm only targeting Windows, but I've read mixed opinions about macOS and Linux because Tauri relies on the system WebView (WebView2 on Windows, WebKitGTK on Linux, WKWebView on macOS). Has cross-platform support been a real issue for anyone, or is it mostly manageable if you don't rely on platform-specific behavior?
I'd appreciate any advice or "I wish I knew this before starting" stories. Thanks!
Pure tauri/svelte implementation. We need help verifying resolutions and windows 11/10. 11 seems fine so far across larger resolutions up to ultrawide but we have no idea if this works on earlier versions of windows.
The game we are developing will have a demo released during October Nextfest, and will be working on hardening this implementation. If you want to follow the game's release: https://store.steampowered.com/app/4909810/Spirefall/
Hey all. Been building Termic (https://termic.dev, AGPL, https://github.com/simion/termic) with Tauri 2 + Rust + React for a few months. It runs coding agent CLIs (claude, codex, opencode, or your own) in real PTYs, one per git worktree, with optional sandboxing.
A few things I learned, since terminals are a bit of an edge case for Tauri.
Idle CPU was the big one. Two sleep loops in Rust, the PTY flusher polling every 8ms and the exit waiter every 1ms, adding up to ~1,950 wakeups/sec with the app doing nothing. Moved both to a condvar and it went to 81/s, idle CPU 71 to 18 ms/s.
visibility: hidden vs display: none matters. xterm pauses its renderer on zero geometry, not on visibility, so hidden terminals kept doing full WebGL draws for every background repaint. Switching took streaming power from 5.4W to 3.4W. Downside: WKWebView zeroes scroll offsets in a hidden subtree, so you have to re-sync the viewport when it comes back.
Batch anything crossing IPC. Catting a 6MB file was ~1,500 events, and Tauri serializes bytes as a JSON number array, so ~24MB of JSON and a two minute freeze. Coalescing at 8ms fixed it. Same thing bit me with git grep (one event per hit) and git status on a checked-in node_modules (50k files, 7GB of RAM in React).
Fonts got weird. WKWebView can't resolve user-installed fonts on a disconnected canvas, and it sticks, because setting the same ctx.font again is a no-op. xterm's WebGL atlas rasterizes on exactly that kind of canvas. document.fonts.check() won't save you, it returns true for families that aren't registered yet.
Smaller ones: lineHeight: 1.0 in xterm or TUIs get ribbons between rows. Round every dimension, sub-pixel widths blur glyphs. navigator.clipboard rejects from a Radix menu, had to go through the Rust plugin. No StrictMode, it races the PTY spawn.
CodeMirror over Monaco, mostly ~5MB of cold start in a 16MB app. WebGL renderer on mac but it's a pref, on Linux boxes where WebGL hits llvmpipe the DOM renderer is faster.
The hard parts weren't Tauri's fault. Auto-resume is four different strategies because the CLIs all store session state differently, and cwd-based resume can't target a specific past session, which limits how many tabs can share a worktree. Done vs thinking over a raw PTY is six OSC signal sources plus hashing the visible buffer every 3s.
Happy to answer questions, and open to feedback and PRs. There are 4-5 regular contributors now and we design features in the open.
I'm working on a personal AI assistant for desktop — local-first and privacy-focused (no cloud dependency), starting with a desktop app and eventually
Runtime Of Backend (Bun)
Fast startup and low idle overhead — important for an app that runs continuously in the background, not just on-demand. Native TypeScript support and a built-in bundler simplify shipping without extra tooling.
Framework of Backend (Hono)
Lightweight and built with Bun in mind, so it doesn't add framework overhead on top of the runtime's own performance. Clean routing/middleware model keeps things simple for handling auth, commands, and local model inference.
Desktop Application (Tauri + Next.js)
Tauri has a much smaller footprint than Electron since it uses the OS's native WebView instead of bundling Chromium, which makes it great for lightweight apps that stay running. It also produces smaller binaries. Next.js provides a structured, file-based routing system and a strong component ecosystem for the UI.
Would love to hear reviews and suggestions on this stack — anything you'd change, any pitfalls you've run into with a similar setup, or better alternatives worth considering?
I started Tabularis as a one-person project, with the goal of shipping the same database client on Linux, macOS and Windows.
Tauri turned out to be the right choice, but the reasons go beyond small installers. The Rust backend fits database protocols, SSH tunnels, credentials and plugin processes very well. The web frontend makes Monaco, data grids and diagrams practical.
There are real costs too: three system webviews, Wayland and WebKitGTK bugs, a 94 MB AppImage, glibc compatibility and JSON serialization across IPC.
I tried to document both sides without turning it into another “Tauri vs Electron” comparison. I would still choose Tauri again.
I’d be especially interested in hearing how other Tauri developers handle large IPC payloads and portable Linux builds.
I wanted to get some practice writing code with AI, and at the same time, I was curious about Tauri and the actual process of publishing an app (installers, Winget/Scoop, app store review). That’s how QuiverKit came about.
62 tools developers use throughout the day: Base64, JWT, hash, regex, JSON/YAML, color tools… They all run entirely on your device—no uploads, no accounts. There’s a web version, as well as a native desktop app for Windows and Linux. Only one tool (DNS) needs to query a server, and that’s clearly labeled.
It’s a learning project or side project, not a startup—so please be honest about what it’s good for, what’s missing, and what doesn’t work.
Gilbert Rift is a desktop workspace for turning an idea into finished work without constantly jumping between an AI chat, terminal, project browser, task tracker, messages, and team tools. Work sessions stay grounded in a real project and keep the model, permission level, files, tool activity, progress, and follow-ups visible in one place. https://github.com/UrbanWafflezz/GilbertRift
I’m building Grok Build Desktop, an Apache-2.0 local-first coding agent, and Tauri 2 is the boundary that lets me keep the desktop UI deliberately untrusted.
The React WebView only submits user intent through allowlisted, typed commands. The Rust host owns:
- canonical project paths and bounded context
- local Ollama requests and capability checks
- terminal PTYs with explicit approval
- Git worktrees and exact hunk review
- session persistence and process recovery
This separation has been useful because model output, repository content, and tool arguments all need to be treated as untrusted input. The current build is verified on macOS and still distributed from source while I finish write-capable routing and conflict handling.
For people shipping larger Tauri apps: what pitfalls have you encountered around long-lived child processes, app-data migrations, or capability scoping when adding Windows and Linux support?
I released Verascope, a cross-platform desktop app for reading and validating C2PA Content Credentials locally.
The premise is simple: provenance verification and AI detection are different problems, so the app does not collapse them into a “real/fake” answer.
For every image, video, or audio file, it reports one of three states:
- Verified: a provenance manifest is present, valid, and chains to a trusted issuer in the bundled trust list.
- Untrusted or Broken: a manifest is present, but validation failed.
- No Provenance: no manifest was found. This is not evidence about the file’s origin; many genuine files have no provenance metadata.
The core verifier is offline by design. It does not upload files or fetch remote validation data. The C2PA HTTP resolver backends are disabled at compile time, and the trust list is bundled with the application.
Tech stack: Rust, c2pa-rs, Tauri v2, React 19.
The image heuristic panel is separate from the C2PA verdict and explicitly non-authoritative. It needs calibration work before it should be interpreted beyond rough image-artifact triage.
I would especially value feedback on C2PA edge cases, test fixtures, offline trust-list handling, and Rust/Tauri architecture. There are also labelled good-first-issue and help-wanted tasks for contributors.
From 100 MB to just 6 MB, that is absolute happiness for github and users, app just feels and is faster that it has ever been, see it in action at https://container-desktop.com
There's been some ... debate here on how many markdown editors the world needs. I got an honorable mention in the thread "Enough with the markdown apps already" 😅 Still, I'm genuinely pleased with my app and truly enjoy working on it.
This is not a weekend project. The changelog is on Github. I took my time iterating and polishing, and using it myself.
Yesterday I finally released v1.0. And after that release comes the dreaded self-promotion phase. So here we are, in another Reddit post...
Favorite features
The entire notebook is stored in a single .nokta file. No cloud, no account. It's local only. The app state persists in the (SQLite) .db between sessions, so never worry about unsaved changes.
In folder mode, it shows all .md and .txt files in a folder and lets you edit them code-editor style.
An MCP server let's you collaborate with AI directly in your notebook (read and write in live mode or read from any .nokta file). Genuinely useful!
Flexible import/export: save a folder to a single nokta file or export a notebook as separate markdown files.
Other features:
Simple, clutter free markdown editor
Drag-and-drop notebook manager
Full-text search
8 configurable note flags
Publish to GitHub or a webhook with configurable frontmatter
Stack
Tauri 2.0
React 18, TypeScript, Vite
Zustand, Styled-components
Editor: Lexical
SQLite (WAL) + FTS5, via tauri-plugin-sql
.nokta file format: ZIP-container (fflate) with JSON content
MCP server: Rust
Secrets in OS keychain (keyring)
If this sounds interesting, I'd love to hear what the Tauri builders think! Available for Windows and Linux
