But you're right that the UI layer is still HTML/CSS rendered in a webview. It's not SwiftUI or Win32. Tauri gets you closer to native than Electron, smaller binaries, lower memory, OS-level webview, but it's not the same as writing Cocoa or GTK directly.
For what this project does (AI generating full apps), Tauri hits a good tradeoff: one codebase, all platforms, real system access, and the AI is much better at generating React than platform-specific UI frameworks. I tried to do the same with Swift it, fails meserably
Thanks, I failed after three attempts. I tried to build a clone of the current backend Tauri at dev time. The only approach that worked well was having a proxy. But now I'm looking into embedding a compiler inside the Tauri Rust at prod time.
This looks like a massive level-up for the "AI-to-Software" pipeline. Moving from simple web-app generation to actual native desktop apps is a huge step for utility—especially if it handles the boilerplate for system-level APIs.
The fact that it's open-source is a great move for the HN crowd. I’m curious, what are you using under the hood for the desktop shell? Is it wrapping an Electron/Tauri instance, or is it generating something like Rust/Python natively?
Clean UI on the site, too. Excited to see where this goes!
Under the hood, it is wrapping Tauri, and as the live preview benefits from a proxy-tauri backend to let you feel like you are already in prod mode. I like that feeling too.
There is no Python, only Rust, AppleScript, and Shell script.
Using Tauri makes a lot of sense here keeping the binary size small while having Rust's safety for the backend is a huge win over Electron. The proxy tauri backend for live previews sounds like a clever way to handle the dev-to-prod feedback loop. Curious if you have hit any specific hurdles with AppleScript for the system level automation yet?
AppleScript execution is running outside of the tauri app; the current app has no way to get the output reliably of the AS code generated by AI. Unless I do a semantic review of the code to make sure that I can capture the output/error of AS execution.
By now, AS run 90% of the time, when it is a single-phase execution, then it is easy. But multiphase execution has a high chance of having the code break in the middle.
That is why I instruct the AI engine to prefer sequential execution (atomic fashion)
Well, while Tauri is certainly nice, it's not quite what I imagine when I hear "native".
But you're right that the UI layer is still HTML/CSS rendered in a webview. It's not SwiftUI or Win32. Tauri gets you closer to native than Electron, smaller binaries, lower memory, OS-level webview, but it's not the same as writing Cocoa or GTK directly.
For what this project does (AI generating full apps), Tauri hits a good tradeoff: one codebase, all platforms, real system access, and the AI is much better at generating React than platform-specific UI frameworks. I tried to do the same with Swift it, fails meserably
How is this better than..Already existed platforms (both legacy and Indie)...like Antigravity etc..
I also use Antigravity. I want to have the live preview of what I'm building. I don't have it in Claude Code, Antigravity, or Cursor.
Not native at all
Edited now. My main concern is how to embed a mini Rust compiler in Tauri for prod time.
That live preview sounds pretty neat!
Thanks, I failed after three attempts. I tried to build a clone of the current backend Tauri at dev time. The only approach that worked well was having a proxy. But now I'm looking into embedding a compiler inside the Tauri Rust at prod time.
This looks like a massive level-up for the "AI-to-Software" pipeline. Moving from simple web-app generation to actual native desktop apps is a huge step for utility—especially if it handles the boilerplate for system-level APIs.
The fact that it's open-source is a great move for the HN crowd. I’m curious, what are you using under the hood for the desktop shell? Is it wrapping an Electron/Tauri instance, or is it generating something like Rust/Python natively?
Clean UI on the site, too. Excited to see where this goes!
Under the hood, it is wrapping Tauri, and as the live preview benefits from a proxy-tauri backend to let you feel like you are already in prod mode. I like that feeling too. There is no Python, only Rust, AppleScript, and Shell script.
Using Tauri makes a lot of sense here keeping the binary size small while having Rust's safety for the backend is a huge win over Electron. The proxy tauri backend for live previews sounds like a clever way to handle the dev-to-prod feedback loop. Curious if you have hit any specific hurdles with AppleScript for the system level automation yet?
AppleScript execution is running outside of the tauri app; the current app has no way to get the output reliably of the AS code generated by AI. Unless I do a semantic review of the code to make sure that I can capture the output/error of AS execution. By now, AS run 90% of the time, when it is a single-phase execution, then it is easy. But multiphase execution has a high chance of having the code break in the middle.
That is why I instruct the AI engine to prefer sequential execution (atomic fashion)