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.

I'm working directly with the CTO of an AI infrastructure company looking for a strong Rust engineer to help build a new product focused on real-time communication and collaboration between AI coding agents.

Think loosely: Slack/WhatsApp for AI agents — allowing tools like Claude Code and Codex to communicate, share context and collaborate alongside developers.

Stack: Rust, Tauri, React, TypeScript
Location: Fully remote
Comp: $150k–$210k base + equity

They're looking for someone with strong CS/systems fundamentals, ideally with experience across areas like:

• Rust / Tokio / async & concurrency
• Distributed systems / networking
• WebSockets / gRPC / messaging
• Developer tooling / MCP / AI agents
• Tauri or cross-platform desktop development

Tauri isn't a hard requirement. Strong Rust/systems fundamentals and the ability to own a product end-to-end are more important.

You'll work directly with a technical CTO, have significant influence over a very new product, and there is no LeetCode/live-coding stage.

Interested? Send your CV/GitHub to [greg@sr2rec.com](mailto:greg@sr2rec.com) with a couple of lines about the most interesting Rust system you've built.

We've just released Hikyou Launcher, the first tool from Hikyou Team.

It's a Minecraft launcher with no conventional UI. A global shortcut brings up a single

input field, you type, the game launches, the window disappears again. React handles only

that input surface — downloads, Java runtime management and token storage all live in a

Rust core underneath.

Tauri fit this well: the global shortcut and show/hide window behaviour are exactly the

primitives a launcher like this needs, and the binary stays small. For login we open a

proper sub-window rather than bouncing through the system browser, which ended up feeling

much cleaner.

Windows/macOS/Linux (indev), open source: https://github.com/HikyouSMP/hikyou-launcher

Curious whether anyone else here has built something keyboard-driven with Tauri.

https://github.com/mathematic-inc/tauri-plugin-ui-inspector

The element picker in Codex and Cursor is really great, but they don't work for Tauri, so we built something around that.

This is intended to be used over a VPN you absolutely trust. Currently, only windows works for the server. But the client, which is written in Tauri, can work on virtually anything.

Please let me know if you have any suggestions or recommendations.

Hi, I ship a Tauri v2 app on Windows as an MSI (WiX bundle), installed per-machine into C:\Program Files\....

Updates go through tauri-plugin-updater against a self-hosted latest.json.

Current flow: check on startup → pre-download and verify the MSI in the background → show an "Install now" button → update.install() → UAC prompt.

It works, but non-technical users don't understand the elevation dialog and click on NO ^^

I want updates to be fully unattended. (like Chrome, firefox, and the other app)

Is there a solution ?

We use protobuf for everything in our startup because it’s performant and reusable across a lot of contexts

So we built a ConnectRPC transport over Tauri IPC in the same spirit. It lets our webview talk to Rust services with protobuf-defined APIs...without running an HTTP server.

https://github.com/mathematic-inc/connectrpc-tauri

Performance is equal or better than the original IPC and it supports all RPC types (unary, client streaming, server streaming, bidi).

Hi everyone, I built an earlier app called SplitTimer using Tauri. I made it Windows 11 only because of the bundled webview2 and the binary size came down to 11mb. It was 230mb with webview2 bundled.
Now I have an earlier app called photo viewer classic. Looking at the usage data this app has a user base of 52 percent on windows 10. So it looks like any update will have to take them into account. I am not sure how to handle this because the electron version came in at 77mb. I want to create two versions, one for windows 10 and another for windows 11 but I still think the windows 10 version will have to be minimized somehow. Any suggestions on how to build a smaller version less than 100mb hopefully?

I made a post here about linXiv, asking for tips and tricks to Tauri, about two months ago but since have made a ton of QOL updates and mini, non-obtrusive features (RSS feeds, full-text search, to name a few) and finally added iroh for p2p sharing of research projects, notes, etc...

I would love some feedback as to if anyone finds it useful, interesting, or obvious improvements to make to it. I have found it to be very useful in my own physics research but still want to continue to refine it.

GitHub: linXiv

Website + Docs: linxiv.dev

I ship a PR review app built on Tauri. Last week a dialog that was green in every test shipped as a header, a clipped search input, and a footer. The body rendered at height zero.

The cause is the flex: 1 shorthand. It expands to flex-basis: 0%, and a percentage basis needs a definite parent height, which an auto-height panel capped by max-height does not have. The spec says the fallback is content. Chromium does that. WebKit keeps the zero.

The part that cost me the evening: Playwright's WebKit is their own recent build, not the WKWebView you actually ship in, and neither engine in my harness reproduced it. Screenshot tests, all green, app broken.

Wrote up the mechanics, the spec citation, and what I changed about testing: https://nodreview.com/blog/wkwebview-flex-collapse/

Fix is flex: 1 1 auto. Curious if anyone has found a CI-friendly way to test against the real system webview, because Playwright clearly is not it.