Tauri 2.0 tries to make mobile apps crossplatform(beta.tauri.app)
beta.tauri.app
Tauri 2.0 tries to make mobile apps crossplatform
https://beta.tauri.app/guides/
43 comments
Been using it in production for over 2y, expect a lot of complaint from Linux user. Webkitgtk is really behind in terms of performance, standard support, etc. And it is not on MDN compatibility list so good luck finding what is available. It is to the point where we marked it as experimental for our users and considered switching to electron (we didnt yet).
Also you can expect hard to reproduce bugs on X version of Y OS that are not reproducable anywhere else. It's a PITA to maintain even for people used to the pain of cross browser problems. Just yesterday I got a user on macos 12 reporting not being able to write in some input fields, no error in the console. Now I need to figure out how to have a VM of that macos version with the specific patch for the webview version to match to reproduce, nightmares I tell you.
Otherwise it is decent and we are a rust shop so it makes sense for us. But IMO it is impossible they will gain any market traction in bigger businesses until we have standard webview packaged into the binaries like electron.
Also you can expect hard to reproduce bugs on X version of Y OS that are not reproducable anywhere else. It's a PITA to maintain even for people used to the pain of cross browser problems. Just yesterday I got a user on macos 12 reporting not being able to write in some input fields, no error in the console. Now I need to figure out how to have a VM of that macos version with the specific patch for the webview version to match to reproduce, nightmares I tell you.
Otherwise it is decent and we are a rust shop so it makes sense for us. But IMO it is impossible they will gain any market traction in bigger businesses until we have standard webview packaged into the binaries like electron.
Thank you very much for sharing your experience. I am developing on macOS so I have yet to face the Linux issues, but I have already faced a few issues on macOS, that require editing some plists file (switching media outputs for example), which made me "sigh" a couple of times.
In Electron, I got my fair share of Linux issues, but nothing critical (tray appearing twice, this kind of things).
This is the Electron paradox: this is the best platform to develop cross-platform apps, because it just works. Yet people hate it (for valid reasons).
In Electron, I got my fair share of Linux issues, but nothing critical (tray appearing twice, this kind of things).
This is the Electron paradox: this is the best platform to develop cross-platform apps, because it just works. Yet people hate it (for valid reasons).
I feel like I've seen mention of them looking at Servo long term - but don't quote me and please someone correct me if I'm wrong.
WebkitGTK being so lackluster is indeed a problem - I ran into this of all things in a wxWidgets project. Eventually wound up ripping it out and replacing it with custom screens since it was more work to maintain and work around issues than to just sit down and write the UI.
WebkitGTK being so lackluster is indeed a problem - I ran into this of all things in a wxWidgets project. Eventually wound up ripping it out and replacing it with custom screens since it was more work to maintain and work around issues than to just sit down and write the UI.
WebRTC! in webkitgtk soon!
:/. Glad I stopped holding my breath, I would have have died several times.
:/. Glad I stopped holding my breath, I would have have died several times.
[deleted]
i think for such case Tauri should allow to embed engine like chromium blink for cases like windows 7 or xp.
Does MacOS not have an equivalent of the Linux AppImage build that bundles the webview?
Am I to understand this correctly that you can effectively ship Tauri-Chromium on Linux?
> changes in the Rust backend can take minutes to compile, and rust-analyzer is damn slow.
Do you find that if you run cargo build, then trigger RA - without even making any changes - then run cargo build again, it recompiles a bunch of dependencies?
If so, you might find that pinning anyhow to =1.0.77 fixes this! There's a bug somewhere in the interaction between RA, cargo and some crates including afaict mostly dtolnay's which leads to RA runs causing the crate build script to think that RUSTC_BOOTSTRAP is set and they should invalidate the fingerprint and recompile.
Perhaps totally unrelated :) but I ask because I just spent days chasing this down only to find, once in the possession of the important keywords, that some helpful fellow had already filed a PR with rust-analyzer that purports to fix it and so my efforts were probably pointless. But if I can save some random guy a few minutes of compile time before the fix is released then it's worth it, right?
Do you find that if you run cargo build, then trigger RA - without even making any changes - then run cargo build again, it recompiles a bunch of dependencies?
If so, you might find that pinning anyhow to =1.0.77 fixes this! There's a bug somewhere in the interaction between RA, cargo and some crates including afaict mostly dtolnay's which leads to RA runs causing the crate build script to think that RUSTC_BOOTSTRAP is set and they should invalidate the fingerprint and recompile.
Perhaps totally unrelated :) but I ask because I just spent days chasing this down only to find, once in the possession of the important keywords, that some helpful fellow had already filed a PR with rust-analyzer that purports to fix it and so my efforts were probably pointless. But if I can save some random guy a few minutes of compile time before the fix is released then it's worth it, right?
(also thiserror =1.0.52!)
> mainly to reduce the memory and app size footprints, which are the main things everybody complains about with Electron
Those are annoyances. But the way an app feels and behaves is the main culprit IMHO. I'd rather have a heavy app that looks and feels native than the other way around.
I don't know about museeks tho. Never tried it. But best of luck with the port in any case!
Those are annoyances. But the way an app feels and behaves is the main culprit IMHO. I'd rather have a heavy app that looks and feels native than the other way around.
I don't know about museeks tho. Never tried it. But best of luck with the port in any case!
We have been using Tauri for about a year (a desktop app) and I am very happy with our choice. What I initially found attractive was the smaller binary sizes. Over time I have come to really appreciate their stance on security and implementation of the Isolation pattern[0].
When we were deciding whether we want to build our business[1] around Tauri, the final argument that helped me decide was the video manifesto[2] on their site as I felt that we were aligned on values. Having interacted with the community over this one year I have had a very positive experience, therefore Tauri definitely gets my recommendation.
[0] https://tauri.app/v1/references/architecture/inter-process-c... [1] https://github.com/gitbutlerapp/gitbutler [2] https://tauri.app/about/intro
When we were deciding whether we want to build our business[1] around Tauri, the final argument that helped me decide was the video manifesto[2] on their site as I felt that we were aligned on values. Having interacted with the community over this one year I have had a very positive experience, therefore Tauri definitely gets my recommendation.
[0] https://tauri.app/v1/references/architecture/inter-process-c... [1] https://github.com/gitbutlerapp/gitbutler [2] https://tauri.app/about/intro
@Sytten mentionned many issues with WebkitGTK, do you share the sentiment?
It's been disheartening to see the degradation of desktop computing because of the shift to "mobile first".
That AI UI designer (Aiuzard?) doesn't even know what a "desktop program" is. Everything's expected to look like a website or a mobile app.
That AI UI designer (Aiuzard?) doesn't even know what a "desktop program" is. Everything's expected to look like a website or a mobile app.
I agree, but I think this is largely the fault of OS Vendors, who design deskop creation frameworks that are usually some combination of hard to use, not very stable, not powerful enough, ugly, or not cross-platform.
I'm sympathetic to the argument that OS Vendors shouldn't be held responsible for their libraries being used outside their OS, but that's clearly what (most) developers want, so (in my opinion) it's a requirement for a popular library.
I'm sympathetic to the argument that OS Vendors shouldn't be held responsible for their libraries being used outside their OS, but that's clearly what (most) developers want, so (in my opinion) it's a requirement for a popular library.
We have gone backward. MacOS X gave us a smooth, tear-free desktop back in 2001. Electron apps and other web technology based apps shit all over that. Even basic apps tear and rubber band when doing something as mundane as resizing the window. They are grotesquely slow and janky while also having a fraction of the features of the apps that we used to use for the same things. And then there’s all the paradigms that make sense on mobile but feel like a straitjacket on the desktop, such as model windows for editing items, or single-window interfaces.
Frankly, it’s depressing. It’s like living in Detroit or Baltimore or Pittsburgh after deindustrialization, when you remember what they were like in their heyday.
Frankly, it’s depressing. It’s like living in Detroit or Baltimore or Pittsburgh after deindustrialization, when you remember what they were like in their heyday.
I'm pretty impressed by what's been put in place to ensure good governance of the project. They have already become a project of the Commons Conservancy, which is a 'fiscal sponsor' organization, and they have a very geographically diverse initial board (seven board members from seven different countries across four continents).
Whatever the technology, this is a serious committent to community-led FOSS, which already sets it apart from the Flutters, Xamarins and Ionics of the world, which are primarily profit-making ventures with an open source aspect on the side. Projects founded with a strong mission and rigorous planning usually cause positive changes within the other ecosystems they touch, even if they don't end up standing the test of time themselves.
Whatever the technology, this is a serious committent to community-led FOSS, which already sets it apart from the Flutters, Xamarins and Ionics of the world, which are primarily profit-making ventures with an open source aspect on the side. Projects founded with a strong mission and rigorous planning usually cause positive changes within the other ecosystems they touch, even if they don't end up standing the test of time themselves.
The Build and Distribute parts of the docs are the things I clicked on first. How can I get Tauri mobile apps in Apple and Google app stores? But they're both 'stubs' with no content yet.
https://beta.tauri.app/guides/build https://beta.tauri.app/guides/distribute
https://beta.tauri.app/guides/build https://beta.tauri.app/guides/distribute
Maybe its only EU compliant
.. where Apple has to allow sideloading
.. where Apple has to allow sideloading
If you are looking for a non-web-based cross-platform GUI in rust, check out EGUI. It has an easy-to-use API, good docs, runs fast, and can integrate with 3d graphics, maps etc.
> By being built on Rust, Tauri is able to take advantage of the memory, thread, and type-safety offered by Rust. Apps built on Tauri can automatically get those benefits even without needing to be developed by Rust experts.
How much of this is mitigated by being web-API-based?
> By being built on Rust, Tauri is able to take advantage of the memory, thread, and type-safety offered by Rust. Apps built on Tauri can automatically get those benefits even without needing to be developed by Rust experts.
How much of this is mitigated by being web-API-based?
At least it is a mile better than the abomination named Electron.
Each Electron app has both Chromium and NodeJS bundled. Tauri only use platform-specific webviews, and Rust is a compiled language with no GC and no runtime.
Each Electron app has both Chromium and NodeJS bundled. Tauri only use platform-specific webviews, and Rust is a compiled language with no GC and no runtime.
Doesn't using platform-specific webviews mean you get inconsistencies between OSes?
Yes, it does suck sometimes, but for UI then your frontend framework should work all the same 99% of the time. If your app is related to audio/video playback or you want to use newer features of Web standard such as webGPU, then it will be trickier.
Source: I'm developer of https://github.com/tranxuanthang/lrcget
Source: I'm developer of https://github.com/tranxuanthang/lrcget
Ah, good point about the frontend framework, you're right. Thanks!
Only if relying on the browser/renderer's opinion on layout.
That sounds like a significant advantage.
egui works for things where you can get away with non-standard-OS behavior and/or are fine with immediate mode. Quite a few projects are not under this umbrella.
> How much of this is mitigated by being web-API-based?
Tauri makes it much easier to use the web side only for presentation and defer almost everything else to the Rust side. The web browsers themselves are pretty well sandboxed all things considered.
> How much of this is mitigated by being web-API-based?
Tauri makes it much easier to use the web side only for presentation and defer almost everything else to the Rust side. The web browsers themselves are pretty well sandboxed all things considered.
Does it work on mobile?
Another (also Rust-based) cross-platform mobile app dev kit is crux [1]. I've never used it, but the core idea of "native UIs (i.e. in Kotlin + Swift) with a shared business logic core via IPC" seems like the sweet spot to my mostly untrained sensibilities.
[1] https://redbadger.github.io/crux/
[1] https://redbadger.github.io/crux/
They were a great alternative for Electron for desktop apps for sure. I'm not very hopeful that they become yet another solution to solve too many platform issues. How could they prevent the framework become over bloated with semi baked plug-in?
> How could they prevent the framework become over bloated with semi baked plug-in?
...not sure how they plan to, but how they COULD do it is by making it easy enough to directly access native resources directly from the script language (like NativeScript) or by making it so easy to write native code (Kotlin/Swift are listed as first-class options) that you just write any specific API access code in the appropriate native language.
It doesn't give you the Electron "write once run everywhere" experience, since you need to write some of the code per-platform, but many apps are 95% UI and only 5% platform-specific functionality. So by abstracting the UI by having it be HTML/CSS/JavaScript, you're getting a "write once run everywhere UI" and the minority of the code that needs to differ is all you have to maintain per-platform.
If writing a plug-in is a high bar, then you get tons of semi-baked plug-ins as the (seemingly) only way to access native features. If instead you can drop in native code easily and quickly, then you can focus on app development and cut out the middleware. ;)
...not sure how they plan to, but how they COULD do it is by making it easy enough to directly access native resources directly from the script language (like NativeScript) or by making it so easy to write native code (Kotlin/Swift are listed as first-class options) that you just write any specific API access code in the appropriate native language.
It doesn't give you the Electron "write once run everywhere" experience, since you need to write some of the code per-platform, but many apps are 95% UI and only 5% platform-specific functionality. So by abstracting the UI by having it be HTML/CSS/JavaScript, you're getting a "write once run everywhere UI" and the minority of the code that needs to differ is all you have to maintain per-platform.
If writing a plug-in is a high bar, then you get tons of semi-baked plug-ins as the (seemingly) only way to access native features. If instead you can drop in native code easily and quickly, then you can focus on app development and cut out the middleware. ;)
Seems like the main differentiator for Tauri is building plugins and features in Rust, no? Otherwise the core architecture will be the same as Capacitor and other projects as that is dictated by the SDK support on each platform (especially iOS).
Yeah. I am about 10 years behind on web dev and so I'm working on a Tauri app that is 99% Rust with just Tauri to draw some GUI controls. Works pretty well.
We considered these other frameworks and decided not to pursue them:
- Qt - Not aware of good Rust bindings, difficult to deploy without like 10 DLLs
- FLTK - Good Rust bindings but difficult to style and was missing some features we want
- GTK - Assumed it doesn't build / deploy easily on Windows
- Win32 - Hoo boy we tried. It would be tiny and fast as hell, but riddled with unsafe blocks, and the documentation is just terrible.
- WPF / XAML - Not aware of Rust bindings
- Flutter, WinUI, etc. - Too new
- egui, iced, etc. - Too hard to style, don't need the performance benefits. If I was making a video editor I'd take egui over Tauri since Tauri can't share memory between Rust and JS.
So Tauri won out on these advantages:
- Built-in bundling for NSIS and MSI makes Windows deployments painless
- Can hire any random webdev to fix up the HTML/CSS/JS when needed
- No problem of binding - It's already made to work well with Rust
I did run into a few caveats, the biggest of which is that Tauri programs cannot return from main. Their event loop doesn't allow it, somehow. Every Tauri program just calls `std::process::exit` to quit. There is probably a very good soundness reason for this (e.g. Windows would flip a turd if you exited one GUI event loop and started another?) but it's frustrating since other toolkits do let you return from main.
Also the Windows clean builds are incredibly slow. It builds faster on Linux but it does not build _fast_ fast anywhere. Incremental builds are bearable.
We considered these other frameworks and decided not to pursue them:
- Qt - Not aware of good Rust bindings, difficult to deploy without like 10 DLLs
- FLTK - Good Rust bindings but difficult to style and was missing some features we want
- GTK - Assumed it doesn't build / deploy easily on Windows
- Win32 - Hoo boy we tried. It would be tiny and fast as hell, but riddled with unsafe blocks, and the documentation is just terrible.
- WPF / XAML - Not aware of Rust bindings
- Flutter, WinUI, etc. - Too new
- egui, iced, etc. - Too hard to style, don't need the performance benefits. If I was making a video editor I'd take egui over Tauri since Tauri can't share memory between Rust and JS.
So Tauri won out on these advantages:
- Built-in bundling for NSIS and MSI makes Windows deployments painless
- Can hire any random webdev to fix up the HTML/CSS/JS when needed
- No problem of binding - It's already made to work well with Rust
I did run into a few caveats, the biggest of which is that Tauri programs cannot return from main. Their event loop doesn't allow it, somehow. Every Tauri program just calls `std::process::exit` to quit. There is probably a very good soundness reason for this (e.g. Windows would flip a turd if you exited one GUI event loop and started another?) but it's frustrating since other toolkits do let you return from main.
Also the Windows clean builds are incredibly slow. It builds faster on Linux but it does not build _fast_ fast anywhere. Incremental builds are bearable.
I'd consider Tauri more a tool for web-UI on desktop that also happens to be usable on mobile than a tool to unify iOS and Android. Certainly a lot of overlap.
Why would you use this over dart/flutter for cross platform mobile apps?
I chose dart/flutter after searching and failing to work out what would be the best web framework to use out of the ever increasing amount of them.
I chose dart/flutter after searching and failing to work out what would be the best web framework to use out of the ever increasing amount of them.
Play around with Tauri the last few months and I've come to the realization that I don't want to build my business on it. We have seen these before (Electron, Expo, Ionic) and they all suffer from the same pitfalls. Now if I have a web application and I'm trying to target mobile and I want to give my business time to develop a native application than I'm using Tauri over the rest of the crowd. A targeted business strategy can make this work, but you are doing so because you need speed not durability or longevity.
I'm curious what pitfalls you're referring to. Frameworks like Tauri and Wails are a far departure from Electron in that they don't bundle a browser.
As someone considering exploring this direction, what pitfalls specifically? There is a performance hit, sure, and considerable memory usage, but that's the trade off for having essentially a virtual machine to work on. And with VS Code being Electron based it's at least conceivably possible to make this approach very performant. On desktop anyway.
Ecosystem / vendor lock in
I have been using wails for our company's desktop apps:
https://wails.io/
It is golang based and works pretty well, I don't know how it compares with Tauri though. We use it mainly because most of our backend code is already golang and I tend to avoid introducing multiple stacks/runtimes to a project.
It doesn't support mobile apps yet, but if you want something golang-based I recommend it.
https://wails.io/
It is golang based and works pretty well, I don't know how it compares with Tauri though. We use it mainly because most of our backend code is already golang and I tend to avoid introducing multiple stacks/runtimes to a project.
It doesn't support mobile apps yet, but if you want something golang-based I recommend it.
If you ditch all "support" libraries, your webview Android application can be smaller than 100KB. And it will build much faster too.
Just use Compose and Kotlin Multiplatform.
What I really like:
- the dev experience is stellar and comes out of the box. No need to setup binary compilation, webpack, vite, hot-reload, TS compilation for back-end, etc yourself. You can pick your favorite JS framework with Vite, during setup, or use a Rust frontend (kind of what electron-forge is doing, but it is buggy, and landed yeaaaars after Electron was released).
- the architecture makes sense (commands, security, plugins, all very well-designed)
- they provide official plugins for common-usecases (SQL, config, etc)
- Rust is fun and interesting to learn for folks like me used to high-level languages like JS or Python
What I don't like as much:
- facing webview-specific UI issues (feature X does not work on Safari, Y not on gtk-webview etc), with Electron, you know if X works on Windows, it will work on Linux or MacOS
- some rough edges with the framework or the ecosystem (not as mature or dev-friendly as npm's or Electron), but the crates (and Tauri's) maintainers are very friendly and reactive.
- the focus on mobile apps, It seems like a very different space, and it feels weird to try to build with big mashup framework. I would rather have them work on more integrations, but whatever.
- changes in the Rust backend can take minutes to compile, and rust-analyzer is damn slow.
Overall I'm really happy and having a lot of fun. I will keep working on this port and release it when I can. Kudos to the Tauri team, what you are building is awesome :)
[0] https://museeks.io