> Tauri is a framework for building tiny, fast binaries for all major desktop and mobile platforms. Developers can integrate any frontend framework that compiles to HTML, JavaScript, and CSS for building their user experience while leveraging languages such as Rust, Swift, and Kotlin for backend logic when needed.
I agree. The v1 front page says this, which is ok but much less clear: “Build an optimized, secure, and frontend-independent application for multi-platform deployment.”
Don't treat the v2 site too harshly - it's in development and hasn't been released yet.
> Hardened foundation for your web apps
The honest description is : smaller faster electron for macos/win/linux/android/ios - written in rust using the OS provided web browser component for tiny binaries. The Tauri developer's focus on security in their marketing is genuine (they have paid for audits) but a little incongruous given what most of it's users want from it which is just a cross-platform UI and/or with a great rust experience.
I have really been enjoying v2 with Leptos with no problems. Ironically the only tricky bit has been setting up permissions for various types of system access (docs are not quite there) but it was simple and made sense once I saw how to do it. I expected a bad experience from the Linux OS web component but it's been excellent in terms of both performance and support on Ubuntu 22.04. The way Tauri can package your app as a .deb or .apk was crazy simple which I also did not expect.
Hardly, Electron is used to not care about the system it runs in. Tauri Is the opposite, you have to consider the works of system's engine.
At least untill they'll offer packing with servo. Then it would be a real rejection replacement.
I’ve been using Tauri for an app I’m developing. The Tauri team is super helpful in their Discord channel. Writing everything in Rust, including the UI (using Axum) has been nice. I’m really excited for 2.0 and mobile support!
I'm using it for https://mixitone.com originally it was going to be just a web app, but making it work offline was quite compelling. Being able to access NFC card readers with rust code was the clincher.
I wouldn't say the team has been very helpful though. I think I've asked 2 questions on their discord channel. The first the response wasn't unfriendly but they clearly didn't read my message about what I'd already tried and it was along the lines of "just do this as documented here" which was in the message. The second time nobody replied. I self replied with my solutions but no one seemed interested, so it didn't feel like much of a community to start engaging more with.
The testing situation isn't very good. They have an unstable webdriver to try. My existing web code was already covered with playwright tests. I ended up writing a websocket layer to pass all the events and commands to a browser so playwright could drive the browser as if it were a tauri window. I'm happy that I can exercise the whole codebase and share tests between the web app and tauri app, but it's not a great solution. If I were a company making money rather than one person doing a side project I'd love to contribute to the test tooling.
> I ended up writing a websocket layer to pass all the events and commands to a browser so playwright could drive the browser as if it were a tauri window.
I was just about to start doing something like this as well for end-to-end testing. Do you have that on Github or be willing to share more about your approach?
Thanks for the feedback. I use the accounts to know which device want to be connected. The devices create a mesh network via webrtc. Perhaps, I need to make it more clear why accounts are needed.
It's not high on my TODO list for the project, but shouldn't be too much work. I'd give it a try if you're interested. Want me to reply to your comment when I get a Linux version released?
We just finished migrating away from Tauri to Electron for our desktop application after running Tauri for 2 years. We are a rust shop so it makes sense to use Tauri, but I can't recommend it for a startup use until they allow packaging a webview into your build. The amount of time you currently have to spend in debugging each OS/Version combination of bugs is simply untenable. This is scheduled for v3 last time I talked to the devs.
I also use Tauri for a startup project I'm getting off the ground and I've been extremely impressed. Unless you're doing something extremely non-standard, I'm not sure what edge cases you're seeing. The webviews packaged with modern operating systems are very compliant (essentially Safari on MacOS and Chrome on Windows). The only wildcard is Linux which uses WebKitGTK which does have all kinds of weird quirks (but that's a comparably tiny market sector to begin with).
Using OS WebViews, you also get the added bonus of security updates which you get for "free" with OS updates (otherwise you have to handle these yourself). There have been some RCE exploits in Electron, so it's something you need to keep an eye out for.
Yup this was also our first impression. Wait until you have users (no snark here, but its the reality). We do have around 1/3 of our users on Linux and WebKitGTK is plainly bad.
Our application is complex I will give you that, but it isnt just that. Say you want to use WASM you have to check which macos versions you want to support and check the oldest possible webview (it doesn't get updated at the same time as safari), check which subset of WASM that supported, etc. It really is a nightmare of subtitle bugs that are hard and time consuming to reproduce.
OS webviews in our findings have a way worse update cycle than us shipping a new version of the app.
Have you or your team written about the migration? Would love to read about that more as usually there's a lot to learn from these situations even when you don't make the same move.
After running the migrate tool (via `bun run tauri migrate`) at the end of the guide, I needed to do the following things to get complete it migration.
- the migrate tool ran rust format on my backend code - which I was not using at that point
- and it changed my preferred to 2 spaces to 4, so I joined the rustfmt bandwagon and created a config file with my preferred settings
- run `cargo update` to get the new package versions
- modify `tauri.conf.json` as the structure changed, eg. `fileDropEnabled` -> `dragDropEnabled`
- change some imports, as the functions from client api were moved, this was straightforward
- add the plugins `updater` and `dialog` as that functionality has moved from the core to plugins
- change the code that handles the auto-updating, as the api changed as well, but for the better
- the only thing that tripped me up, was that re-building the project didnt't work due to an colliding filename error, but I found a closed issue at their https://github.com/tauri-apps/tauri/issues/10192 which pointed me towards removing `rlib` from the crate-type, which solved that issue.
All in all quite a smooth experience, was done in an 1-2 hours or something, not sure.
I've been following tauri for a bit. It seems very cool and interesting but I've always wondered - what are the use cases for putting your app in a webview instead of using the browser? Everything I've thought of would work just as well.
The goal is to make a standalone desktop app with access to local resources, so the question is "why should you put your app in a webview instead of Electron or a native toolkit?"
The answer is that Electron forces you to carry a whole Chrome installation around, which is unnecessarily heavy, and (AIUI) you have a node.js backend giving you the means to touch the actual OS, whereas Tauri lets you write Rust (YMMV as to whether that's an advantage). Both Tauri and Electron let you use a web-based interface instead of mucking about with native widgets, which are a pain for cross-platform development.
For Slack & co, being able to be on the native application dock (for the average user) instead of buried in a tab is considered a significant visibility boost.
It’s also something that came about from when web apps on desktop/PWA didn’t have nearly as much reach. With e.g modern macOS support for PWAs you might be able to get away with just the web app now, depending on your target customer.
Anything that needs os access, to name some things: menu bar apps, clipboard access, file system, multi window, etc etc.
You can do a lot of things in the browser, but usually it's limited (mainly for security reasons). Having it be an app allows you to better integrate with the OS.
I mean there are so many reasons why you would want to do this it's impossible to enumerate them all. Key command overrides are a great example of bad behavior on the web that is essential to UX in a native app. Or mouse pointer control. File system access and other native APIs the browser doesn't expose, or makes a pain.
I have too. I think the big deal is easy to do cross platform + reuse your javascript/css skills for gui + lower memory footprint than electron apps. I'm waiting until I see some major apps done in it.
You build something that needs access to to the filesystem? -> No other choice than a desktop app. (Chrome has some limited APIs around that, but AFAIK only sandboxes ones and not e.g. existing directories)
It makes more of a difference for the end-user then the developer necessarily.
An end-user can continue to use your electron/tauri app for years after a website has long since vanished into the infinite void.
But vunderba you think to yourself and also how did I know what you were thinking just call me the amazing kreskin, "what about a PWA? - you can use that off-line".
PWAs give the deceptive illusion to the laymen that they're installing an actual application as opposed to just a bunch of ephemeral stuff thrown inside the user data folder of the respective browser.
Not lighter weight than a website because it is a website. The only advantages are you can ship parts of your app as native code, and you aren't constrained by the browser permission model.
Can anyone explain what Tauri or webviews offer that makes them a good choice over a local-http-server webapps? Imo, as a user, Webview, no thanks. Local webapps, yes please.
There really isn't a good reason for webviews or electron/tauri that I can tell? Why some people love love love native apps, to the extent they'd rather a dressed up webapps is confusing to me. If it's already a webapps, hell yeah give me the user-agency of extensions, browser history, tabs, back buttons, and hyperlinks or give me death! Anything but the power-stripping captive-audience of native apps!
It would be much better to package your app as a small daemon that hosts a localhost webserver. The daemon can talk to all the system APIs it needs to. Add a desktop icon or shortcut that opens the localhost webpage. The daemon can present just a regular HTML hypertext webapps as usual, so all the usual bits of user-agency can slot into the overall experience.
Theres a lot of usenet-related apps that work like this, that run as daemons, and have web interfaces. Sunshine game streaming too.
It's be great to have some massively multi-platform http-headed app frameworks! That does seem semi missing, especially wrt mobile integration.
Because you're thinking of it backwards. Users have known for decades that they can click an icon, a window will appear, and that's the "application" they're interacting with. This is culturally ingrained as the basis of graphical operating systems (even mobile!) and it's a standard people want to continue meeting regardless of the underlying technology they use.
It just turns out due to historical reasons, in 2024, "the web" has the most easy-to-get-running cross platform UX system available, where you can produce an icon that people click, and it opens the app. That's basically the long and short of it.
At the end of the day most of the stuff you mentioned doesn't matter because these are, from the beginning, designed as applications that use the web as a way to deliver UI more than anything. Things you mention like back buttons (requiring you to design around stateless hypertext APIs rather than what would be local RPC, and which may be better handled inside the system anyway with e.g. its own undo system) or "browser history" either have large design consequences, or just don't make any sense at all.
To be clear, it's very useful in some cases to have the design you describe (true client/server architecture), and underneath it all Tauri does something like that. But it alone can't fulfill all the use cases something like Tauri or Electron aim to.
> The daemon can talk to all the system APIs it needs to.
That's not the problem, it's the impact on the downstream design, like the fact such a daemon can't cleanly interact with the native windowing context of the (existing) browser or operating system without duplication. You cannot add a proper system menu bar or global shortcuts to the design you described in any way that won't either be sucky and fiddly, or just outright reimplementing what Tauri already does anyway. Or consider alt tabbing and wanting to dial in on a specific app window. There are tons of small things like this that do not work.
I am curious, I work for a company that has a bunch of hardware(serial communication) that communicates to our modules is built via python.
So all the backend tooling is python that has the drivers and quality of life functions to support that hardware. Would love to make a native experience instead of a webapp (flask etc)
Does anyone have a solution to this? Would love to use Tauri as a desktop server and create the WebView. But do I just use ffi for every single class/module/function?
Or does anyone know a more elegant solution to bridge the gap of making a native desktop experience while still leveraging the years of python drivers that have been built up
I use Tauri for my sync app that syncs music between my mobile app and desktop library. It's been a pleasure to use. Tauri 2.0 looks like it's going to be a real contender for mobile too.
Readit News
Consider adding something more informative than 'Hardened foundation for your web apps', and maybe an 'About' page.
> What is Tauri?
> Tauri is a framework for building tiny, fast binaries for all major desktop and mobile platforms. Developers can integrate any frontend framework that compiles to HTML, JavaScript, and CSS for building their user experience while leveraging languages such as Rust, Swift, and Kotlin for backend logic when needed.
This ought to be on the front page.
> Hardened foundation for your web apps
The honest description is : smaller faster electron for macos/win/linux/android/ios - written in rust using the OS provided web browser component for tiny binaries. The Tauri developer's focus on security in their marketing is genuine (they have paid for audits) but a little incongruous given what most of it's users want from it which is just a cross-platform UI and/or with a great rust experience.
I have really been enjoying v2 with Leptos with no problems. Ironically the only tricky bit has been setting up permissions for various types of system access (docs are not quite there) but it was simple and made sense once I saw how to do it. I expected a bad experience from the Linux OS web component but it's been excellent in terms of both performance and support on Ubuntu 22.04. The way Tauri can package your app as a .deb or .apk was crazy simple which I also did not expect.
> (Toolkit/Framework) for building cross-platform desktop application using web technologies. Focused on efficiency, security, and size.
My app (very beta) https://meshly.cloud
I wouldn't say the team has been very helpful though. I think I've asked 2 questions on their discord channel. The first the response wasn't unfriendly but they clearly didn't read my message about what I'd already tried and it was along the lines of "just do this as documented here" which was in the message. The second time nobody replied. I self replied with my solutions but no one seemed interested, so it didn't feel like much of a community to start engaging more with.
The testing situation isn't very good. They have an unstable webdriver to try. My existing web code was already covered with playwright tests. I ended up writing a websocket layer to pass all the events and commands to a browser so playwright could drive the browser as if it were a tauri window. I'm happy that I can exercise the whole codebase and share tests between the web app and tauri app, but it's not a great solution. If I were a company making money rather than one person doing a side project I'd love to contribute to the test tooling.
I was just about to start doing something like this as well for end-to-end testing. Do you have that on Github or be willing to share more about your approach?
Otherwise good progress, happy to see it!
Using OS WebViews, you also get the added bonus of security updates which you get for "free" with OS updates (otherwise you have to handle these yourself). There have been some RCE exploits in Electron, so it's something you need to keep an eye out for.
Our application is complex I will give you that, but it isnt just that. Say you want to use WASM you have to check which macos versions you want to support and check the oldest possible webview (it doesn't get updated at the same time as safari), check which subset of WASM that supported, etc. It really is a nightmare of subtitle bugs that are hard and time consuming to reproduce.
OS webviews in our findings have a way worse update cycle than us shipping a new version of the app.
There's also various UX differences in webviews.
It's all fine though, I'd rather have multiple webviews over a bloated app. Used to developing for multiple environments anyways.
They started working on 2.0 with the docs for v1 in a 10% state. I mostly searched through discord threads for tidbits. It was painful.
Expect the documentation for 2.0 to be at 5% for years.
Deleted Comment
After running the migrate tool (via `bun run tauri migrate`) at the end of the guide, I needed to do the following things to get complete it migration.
- the migrate tool ran rust format on my backend code - which I was not using at that point - and it changed my preferred to 2 spaces to 4, so I joined the rustfmt bandwagon and created a config file with my preferred settings
- run `cargo update` to get the new package versions
- modify `tauri.conf.json` as the structure changed, eg. `fileDropEnabled` -> `dragDropEnabled`
- change some imports, as the functions from client api were moved, this was straightforward
- add the plugins `updater` and `dialog` as that functionality has moved from the core to plugins
- change the code that handles the auto-updating, as the api changed as well, but for the better
- the only thing that tripped me up, was that re-building the project didnt't work due to an colliding filename error, but I found a closed issue at their https://github.com/tauri-apps/tauri/issues/10192 which pointed me towards removing `rlib` from the crate-type, which solved that issue.
All in all quite a smooth experience, was done in an 1-2 hours or something, not sure.
The answer is that Electron forces you to carry a whole Chrome installation around, which is unnecessarily heavy, and (AIUI) you have a node.js backend giving you the means to touch the actual OS, whereas Tauri lets you write Rust (YMMV as to whether that's an advantage). Both Tauri and Electron let you use a web-based interface instead of mucking about with native widgets, which are a pain for cross-platform development.
- File System (Obsidian, Logseq)
- Push Notifications (IM, Social Media, Email)
- USB/Bluetooth (Doesn't work in Safari?)
- Global Hotkeys (Raycast)
- Interfacing with other local Apps (localhost is often blocked)
It’s also something that came about from when web apps on desktop/PWA didn’t have nearly as much reach. With e.g modern macOS support for PWAs you might be able to get away with just the web app now, depending on your target customer.
You can do a lot of things in the browser, but usually it's limited (mainly for security reasons). Having it be an app allows you to better integrate with the OS.
An end-user can continue to use your electron/tauri app for years after a website has long since vanished into the infinite void.
But vunderba you think to yourself and also how did I know what you were thinking just call me the amazing kreskin, "what about a PWA? - you can use that off-line".
PWAs give the deceptive illusion to the laymen that they're installing an actual application as opposed to just a bunch of ephemeral stuff thrown inside the user data folder of the respective browser.
There really isn't a good reason for webviews or electron/tauri that I can tell? Why some people love love love native apps, to the extent they'd rather a dressed up webapps is confusing to me. If it's already a webapps, hell yeah give me the user-agency of extensions, browser history, tabs, back buttons, and hyperlinks or give me death! Anything but the power-stripping captive-audience of native apps!
It would be much better to package your app as a small daemon that hosts a localhost webserver. The daemon can talk to all the system APIs it needs to. Add a desktop icon or shortcut that opens the localhost webpage. The daemon can present just a regular HTML hypertext webapps as usual, so all the usual bits of user-agency can slot into the overall experience.
Theres a lot of usenet-related apps that work like this, that run as daemons, and have web interfaces. Sunshine game streaming too.
It's be great to have some massively multi-platform http-headed app frameworks! That does seem semi missing, especially wrt mobile integration.
It just turns out due to historical reasons, in 2024, "the web" has the most easy-to-get-running cross platform UX system available, where you can produce an icon that people click, and it opens the app. That's basically the long and short of it.
At the end of the day most of the stuff you mentioned doesn't matter because these are, from the beginning, designed as applications that use the web as a way to deliver UI more than anything. Things you mention like back buttons (requiring you to design around stateless hypertext APIs rather than what would be local RPC, and which may be better handled inside the system anyway with e.g. its own undo system) or "browser history" either have large design consequences, or just don't make any sense at all.
To be clear, it's very useful in some cases to have the design you describe (true client/server architecture), and underneath it all Tauri does something like that. But it alone can't fulfill all the use cases something like Tauri or Electron aim to.
> The daemon can talk to all the system APIs it needs to.
That's not the problem, it's the impact on the downstream design, like the fact such a daemon can't cleanly interact with the native windowing context of the (existing) browser or operating system without duplication. You cannot add a proper system menu bar or global shortcuts to the design you described in any way that won't either be sucky and fiddly, or just outright reimplementing what Tauri already does anyway. Or consider alt tabbing and wanting to dial in on a specific app window. There are tons of small things like this that do not work.
Dead Comment
Does anyone have a solution to this? Would love to use Tauri as a desktop server and create the WebView. But do I just use ffi for every single class/module/function?
Or does anyone know a more elegant solution to bridge the gap of making a native desktop experience while still leveraging the years of python drivers that have been built up