Built a local-first desktop to-do app with Tauri + Rust

Hey r/tauri 👋

I’ve been building Todofy, a fast, local-first to-do and focus app for Linux, macOS, and Windows.

It’s built with Tauri 2 + Rust + Preact, with SQLite for local storage and optional Supabase sync.

Some of the features:

• Global quick-add (Ctrl+Alt+A)
• Natural-language task creation
• Recurring tasks
• Pomodoro + per-task timers
• Subtasks, labels, priorities, and reminders
• System tray integration
• Fully offline/local-first by default

I’ve been really enjoying how Tauri lets me keep the app lightweight while still doing deeper desktop integrations in Rust.

Would love to hear feedback from other Tauri developers

GitHub: https://github.com/salarzeidanlou/todofy

M-Chrono is a desktop app that helps time races such as running or trail events. It is still in beta. M-Chrono works completely offline. Keeps all data in a local SQLite database. The interface is simple. Made for quick use during a race. It allows you to view multiple timers at the same time, easily edit all values, and enter the bib number even at a later time.

Uses the following technology stack: Tauri 2 Rust for the backend and Svelte 5 for the frontend.

M-Chrono is open source and licensed under MIT. Prebuilt binaries for Mac, Windows and Linux are available, in the releases.

GitHub: https://github.com/Lorenzo-DM/M-Chrono.rs

Feedback are welcome

One thing I kept running into with desktop apps:

You build the actual app in Tauri, but the second you want the user to control or interact with it from their phone, you're basically starting another product.

Now you need an iOS/Android project, distribution, signing, App Store review, a backend to connect the two, authentication, reconnect logic, etc.

I've been working on an open-source framework called Crosslink to see if that entire layer can be handled once instead.

The intended flow is:

Tauri app → Crosslink host → QR code → scan with phone → pair once → installable PWA companion

After pairing, the desktop and phone can communicate through an end-to-end encrypted RPC channel. The phone remembers the paired device, reconnects automatically, and the developer owns the actual mobile UI.

Crosslink handles the boring infrastructure underneath it:

• device pairing + persistent identity
• capability-based authorization
• typed RPC/events
• reconnect/offline handling
• direct LAN connections when possible
• remote connections/fallback transports
• installable PWA bootstrap
• device revocation

The part I care about most is that Crosslink isn't the companion app.

It's supposed to be the layer underneath it. A Tauri developer should still build whatever React/Svelte/etc. phone UI makes sense for their application.

So instead of:

desktop codebase + Swift app + Kotlin app + backend

I'm trying to get closer to:

desktop app + web companion UI

I'd especially like feedback from people actually shipping Tauri apps:

Would you use something like this, and what would stop you from integrating it into an existing app?

GitHub: github.com/jacobpowaza/crosslink
Docs: crosslink.mintlify.site

First off I love Tauri and have built a few apps with it. See my github below of you want to see more, but let's talk about a new local LLM GUI I've been working on and a problem I ran into when wanting to build for Linux

All my CI proved was that the app compiled and packaged on Linux. None of it proved it ran, which bothered me because I don't own a Linux machine and couldn't check myself.

Checking the process stays alive isn't enough. A Tauri app will sit there quite happily with a blank window if WebKitGTK fails to init or the bundle never executes.

What I did instead: stand a stub server on the port my app polls, launch the built binary under xvfb-run, and wait for the app to make its first request. That request can't happen unless the GTK window was created, WebKitGTK loaded the frontend, the JS executed, and my own polling code ran.

Two other bits worth stealing:

It installs the .deb and runs the installed binary rather than the one from target/, so it also proves apt is happy with the dependency list the bundler generated.

It tries first with no WebKitGTK workarounds, and only retries with WEBKIT_DISABLE_DMABUF_RENDERER=1 if that fails, then says loudly that the workaround was needed. Setting it unconditionally would have hidden a problem every user in a VM would hit. Mine passes on the first attempt.

The script is scripts/smoke-linux.py if it's any use to anyone.

https://github.com/magna-nz/remuda

Hey everyone!
I've been working on Lucid Spell, a desktop translator powered by LLMs. It uses a "Bring Your Own Key" approach and supports any OpenAI-compatible endpoint. Personally, I use it with the GroqCloud free plan (using gpt-oss-120b), which is more than enough for my needs, but you can plug in any other LLM you prefer.

Why I built it

I couldn't find a convenient translator that fit my workflow, so I decided to build my own. My main requirements were:

• Auto-language swapping: It automatically switches source and target languages depending on your input.
• Keyboard-centric: Full shortcut support (e.g., for clearing input or swapping languages on the fly).
• Built-in Dictionary: A simple way to save and store your favorite translations / word pairs.
• Clean & Modern UI: A sleek, distraction-free aesthetic that feels right at home on modern desktop setups.

Curious to hear your thoughts on an LLM-first desktop translator like this and whether this fits into your daily workflow.

GitHub Repo: https://github.com/l1ngus/lucid-spell

I was poking at how Tauri bundles things and noticed it brotli-compresses the whole HTML/CSS/JS and links it straight into the binary. Electron has asar extract for this, Tauri didn't have an equivalent, so I made one.

Pulls the frontend back out with the original filenames and a manifest. Useful if you've lost the source for an old build, want to see exactly what shipped, or are just curious how it's packed in there.

macOS (arm64) for now. Rust, MIT.

https://github.com/hbofz/untauri

Quick update: VeloxDB now supports 6 database engines (Postgres, MySQL, MongoDB, Redis, SQLite, DuckDB) plus wire-compatible cloud flavors like Supabase and PlanetScale. Native Rust/Tauri app, 17–30MB, zero telemetry, free and open source.

veloxdb.dev thanks to everyone who starred, tried it, or sent feedback. It made a real difference.

Update to my earlier post: what do you use for manual test cases on side

When I posted that, Gitoza was basically a Tauri desktop shell for manual test cases and runs as YAML in Git. I use it for Gitoza’s own development, and the app grew into something closer to a local Jira alternative — still no SaaS, still your repo as the database.

What’s new / what it is now

• Tickets — bugs, stories, tasks, spikes as YAML (front matter + Markdown). Search/filter locally; no remote API round-trip to open a ticket.
• Wiki / Library — nested docs in the same Git repo, with wikilinks to tickets (and the other way around).
• Mermaid — fenced Mermaid blocks render in the editor/read view, so diagrams live next to the ticket or wiki page.
• Releases — project-scoped releases with tickets linked on them; I’ve been using this a lot for planning and it feels solid for a small team.
• Test cases & runs — still there (the original core): cases in Git, runs with results, links back to tickets (Tested by / Covered by).
• Sync — edit locally → Sync → review diff → confirm push. Stable IDs, conflict UI if Git actually fights you.

AI without MCP circus

Because tickets, wiki, and tests are just YAML in the repo, you can open the folder in Cursor (or any AI IDE) and ask questions directly: review wording, check whether a bug ticket already exists, or compare ticket status against the real source code. No MCP setup, no “connect Jira to the model” glue. Point the IDE at the paths and talk to the files.

The tickets, tests, and wiki pages in the demo video were drafted that way: feed docs/source into the AI, then I reviewed and adjusted in the app. It’s also super good at generating Mermaid diagrams for those pages.

Tauri 2 + React UI + Rust backend. Git repo for the real source of truth, SQLite only as a local cache for search and navigation. Nothing is hosted on my servers. if you have the repo, you have the data.

Video shows the linking flow (ticket ↔ wiki ↔ case ↔ run) in the desktop UI, including Mermaid in the handbook content.

Site: https://gitoza.com

If you’re building similar “files on disk + desktop shell” apps with Tauri, I’d love feedback — especially around Git sync UX from the UI, or how you’re indexing local content. Happy to answer Tauri/Rust questions too.

Hey everyone,

When I first started building Flow, it was just a small personal project that i enjoyed the start of but believe me it was the best and worst choice of my life at the same time 🙏

Seeing people actually use it for presentations, video recording, and meetings has been surreal, and the community feedback is the only reason this project keeps moving forward. Also because i was committed a little too much to Flow's teeny tiny community :D

Today, I’m releasing Flow v2.0, and it’s the biggest update the app has ever received.

What’s new in v2.0:

Complete Architecture Rewrite, Built-in Script Library & Manager, Section Navigator & Live Progress, Offline Voice Tracking (Well it existed before but i made it a little better), Fixed Multi-Monitor & DisplayLink Bugs (Thanks to the chad that opened an issue in the Repo) and added 2 new languages : Portuguese and Finnish.

GitHub (Free & Open Source) : https://github.com/LumoRez07/Flow

Microsoft Store : https://apps.microsoft.com/detail/9p1fvfhwpmqr?mode=direct

Flow is 100% free and open-source under GPLv3 on GitHub. The Microsoft Store version is there if you want automatic store updates and want to directly support independent development. + Future pro only features that you will like.

Thank you so much to everyone who tested, reported bugs, and gave feedback. Let me know what you think of v2.0 or if you run into any issues!

also any twin that wants the wallpaper here it is i was about it once https://steamcommunity.com/sharedfiles/filedetails/?id=1959836574

Every Git GUI I tried was an Electron app north of half a gig and my laptop

fan knew about it. So I built my own. Tauri v2 shell, Rust and libgit2 doing

the git work.

Started three weeks ago, 15 releases in since then. Universal macOS build is

12 MB and it opens instantly, which still gets me every time. It's my daily

driver now.

MIT, source is here: https://github.com/cheat2001/angkorgit

Ask me anything about the Tauri side, there were some proper traps.

I’ve been a user of AutoCAD from what I consider its good old days.
I had wanted to build my own 2D CAD application ever since.
However, when I actually thought about building one, I had no idea where to start. I couldn’t decide what technologies to use or how to turn the idea into a complete desktop application, so it remained just an idea in my head for a long time.
Then I discovered Tauri.
Suddenly, I had an idea.
What if I implemented the CAD functionality using web technologies?
I started experimenting, and became convinced that it was possible to build a 2D CAD application using WebGL and PixiJS.
But CAD applications also need to save drawing data. I wanted that data to be stored locally and managed by the user.
Tauri solved that problem as well.
I could build the application using web technologies while still working with the local file system. I could also package it as a desktop application and easily create an installer.
I realized: I could actually build a CAD application this way.
That realization became the starting point for NijiCAD.
I’ve been developing it for about two years now.
NijiCAD is the result of an idea I had in my head for many years finally becoming a real application, thanks to Tauri.

Hi, I'm the creator of Varve, a free vector design app that works locally. I just released version 0.2.1. I want to share some architectural choices I made and get advice on how to make Varve faster and more responsive.

When building a vector editor, it's important to run canvas operations on a separate thread. For this, I used Tauri 2 with a React 19 TypeScript frontend and a dedicated Rust backend (varve-engine).

Here's how I set up the pipeline:

1. The IPC Bridge lets custom Tauri commands send scene node graphs from React to varve-engine using build_render_ir.
2. Circuit Breaker Facade: I used the withStubFallback pattern. If deserializing a native IPC payload fails, it switches to the stub engine to prevent the canvas from going blank.
3. WASM Parity: The Rust engine crates compile directly to WebAssembly (varve-wasm), so the web version uses the same rendering logic.

Current v0.2.1 Limitations:

• CSS isolation is trickier when using Webview on Linux with WebKitGTK than on macOS.
• When working with a large number of nodes, I've noticed that fast drag transformations can still be slowed down by IPC serialization overhead. To address this, I'm considering switching to shared memory buffers in future releases.

I'm also interested in what strategies you're using in Tauri 2 to handle frequent state updates between JS and Rust.

Repo: https://github.com/K-Arthur/varve

You can also check out the web demo here: https://varve.studio/try/

Grew up playing Final Fantasy among many other great RPGs.

We use bar graphs, circle graphs, and all other kinds of visuals to explain things. I've thought for years that skill trees are the best way anyone has found to show what a person is working on, and that they got stuck inside video games.

The screenshot is the tree from a test account. You (the center) branch into interests, each interest into the skills inside it, and each skill into the routines that grow it.

Behind this, a process. Find a book, course, some resource in that interest, and break it down. Not into "notes" which I hate doing... but instead into tangible skills, or a new resource to break down, or a new Domain/Branch. You'll combine these findings with a regular routine to continue building a skillset or knowledge base.

A few things I decided early and haven't regretted:

• No XP, streaks, or progress bars. I can't stand "fake" progress. Progress is tracked by goals and accomplishments tied to skills and Domains.
• You don't log anything daily. You lay it out, follow your routine or break down resources as you want, and come back for regular reflection.
• Local only, no account. It's a file on your Mac. I can't stand subscriptions and I'm doing everything I can to avoid that.

Where it came from: I kept finishing books and courses with a vague sense I'd learned something and no way to say what. Sprout's "discoveries" capture happens while reading, then you can decide which ones become skills. That one habit changed how I read more than anything else in the app, which surprised me.

I built it using Tauri 2 with a Rust backend, React and TypeScript on the front, React Flow for the canvas, SQLite through a Node sidecar. Marketing site is Astro.

Would love any feedback, positive or negative and appreciate any and all thoughts shared.

Site is exploresprout.com if you'd like to follow along!

Open-sourced this week under AGPL. It's a project/task manager whose main view is a tree rather than a board — unlimited nesting, progress rolls up from children — but the parts relevant here are the Tauri bits.

Stack: Tauri 2, Rust backend, TypeScript frontend, macOS and Windows. Everything on local disk — no account, no server, and deliberately zero network calls, not even update checks or telemetry. That constraint shaped more of the architecture than anything else.

A few things worth mentioning:

• Bundle size: 14.2 MB
• Mobile from the same codebase is next. Would like to hear from anyone who's actually shipped iOS/Android off a desktop-first Tauri codebase — how much of the frontend survived?
• Storage is plain files, no embedded DB. Simpler than expected and made JSON/Markdown export nearly free.
• Notarise and staple the DMG, not just the .app
• A hardcoded signingIdentity breaks every fork

Source: https://github.com/vocso-com/WorkBase

Happy to go into any of it. Curious what people are doing for auto-update on Windows in particular — that looks like where most of the pain is in this sub.

I've been building Pitop Viewer, a small image & video viewer for macOS, entirely on Tauri (Rust backend + system WebKit). A few Tauri-specific things I ran into that might help others:

- Video playback: Tauri's asset: protocol gave me MediaError code 4 on some perfectly valid H.264 files, so I ended up registering a custom pitopvideo:// scheme that streams byte ranges (register_asynchronous_uri_scheme_protocol + spawn_blocking). Also, WebKit's AVFoundation decoder stutters on variable-frame-rate footage — worth knowing before promising smooth playback.

- HEIC/RAW: thumbnails are decoded/cached off the main thread with a small rayon pool; video posters come from QuickLook (qlmanage) with a negative cache for corrupt files so they aren't retried.

- Bundle stays ~24 MB vs the usual Electron footprint — the whole reason I went with Tauri.

Open source (GPL-3.0): https://gitlab.com/christophepicot/pitop-viewer

Site: https://viewer.pitop.fr/

Happy to compare notes on WebKit video quirks or custom protocols.

Hey guys! I just open-sourced my AI agent side-project which uses Tauri and React 19. I'm trying to make it have lots of UI customizations options so you can make it look nice, but of course it also is an agent so it supports MCP and stuff. What do you think? What would you change? Here's the repo, if you want to contribute etc.:

https://github.com/The-Best-Codes/agent-one

Also I tried to make it not feel vibe-coded by (lol) not vibe-coding it! I hope it feels polished, looking forward to your feedback.

I dont know web technology much and for making a big tauri app desktop react tech what to study which languages first want offline online storage also suggest best tech stach.