> 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.
Miguel de Icaza is kind of a legend, I know him most from his work on Mono and Gnome. Whatever he works on today will likely be part of a stack you work on in a few years (at least that's my experience).
Related, for everyone interested into Godot + Swift, check out https://github.com/johnsusek/SwiftGodotBuilder I think Swift might soon be a crazy ergonomic language to make Godot games.
respect to icaza for his contributions (tho I was on the KDE side of the gnome/kde desktop "wars"), but has the "Whatever he works on today will likely be part of a stack you work on in a few years" been true for a long time?
After successfully getting Xamarin acquired by Microsoft, apparently he got disappointed how everything turned out, especially the decisions that lead to the Xamarin.Forms to MAUI rewrite, MonoDevelop being killed, or what is left of Mono/Xamarin.
Nowadays he is full into Apple and Swift ecosystem, doing apps, and contributing to Godot on Apple, making it Swift first with goodies for doing iPadOS based game development.
Oh, very cool. Just watched the YouTube on some of the porting challenges. Love the idea of a full fledged game dev environment the kids can graduate to from scratch Jr. and the like.
Combine this with an Apple Pencil, Pixelmator pro and Blender and you’ve got yourself a great little hyper portable game kit. Don’t think I’d do too much hardcore coding in this form factor, but if I had an existing prototype that I just wanted to tweak a bit and play around with, it seems legit.
Everybody could see how the whole Microsoft thing was going to go except Miguel, apparently. Worse he was very smug and self-righteous about selling out.
Unity engine , the most popular game engine based on mono. Also gnome software like glib , cairo , harfbuzz prolly used as foundation by all OSes, gui toolkit, programming language or browser on the market.
I don't make games so probably not using Unity. I also don't think gnome software like glib and cairo is the "foundation" of the OS I use like macOS. Are you sure you're not a Miguel de Icaza alt account?
It's likely you do use Mono or a successor. The modern dotnet framework is a descendent of Mono and is used in a variety of websites, games, and other applications.
IIRC, Mono's base class library was also used to fill the cross-platform gaps in .NET Core 2-3 back when they ported the Framework APIs they had removed for Core 1. I don't know how much of that remains though.
I understood the point of Tauri is to write the apps with Typescript and web tech and to NOT have to write Rust or even know Rust. So why would it need to be ported to Swift when the point of Rust in Tauri just so the devs themselves or the wider community can write the base and plugins and stuff in Rust and the apps the general dev writes with it are written in TS?
I looked at Tauri like an Electron alternative that in the future will run with Servo under the hood.
To anybody with experience, how's Swift? Especially outside MacOS/iOS programming. Let's say I want to use it standalone for doing some systems programming, how's the standard lib? I'd like to not rely on apple specific frameworks like uikit
One of the biggest issues I ran into years ago was debugging outside of macOS was a nightmare. Even now, debugging is a terrible experience on a non-trivial project. I am not really sure if it the size of the projects I've worked on, interop with objc, compiler configs, project configs, or what, but it has always been a bad experience. I used it on/off for a project on Linux and the debugger didn't work at all. This was so long ago I am sure that has changed but at least so far in my experience, lldb will stop working at some point. I've worked on large Obj-C and C++ codebases and never ran into any of the problems I've run into with swift in this area.
Apple really needs to decouple swift debug and profiling tools from Xcode. I've been using vscode for swift work but hate having to switch back to Xcode for the tools.
As a language, I really like it. It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
The standard library is pretty good but the extended ecosystem is not as strong outside of Apple platforms, though that is improving.
If the ecosystem improved, like this project here, it would probably be my go to language. Failing that it’s usually rust , Python, C# and C++ for me.
UI libraries outside of Apple frameworks is about as weak as all those other languages if you don’t have Qt bindings. Qt does have Swift bindings officially in the works though so that could change.
> It feels very much like a cousin to Rust with a few tradeoffs to be more ergonomic.
Rust can be just as ergonomic. It takes some minor boilerplate of course, since you're resorting to coding patterns that are somewhat unidiomatic - but not nearly as much as the likes of C# or Java.
I wouldn't really call this an "ergonomic" feature of a language. That's a whole research project.
Regardless, C++ interop in Swift isn't straightforward and there are a multitude of issues. One being that you need to compile your C++ codebase with Apples fork of LLVM and in some cases add annotations in your C++ so that Swift plays nice (which basically isn't interop at that point)
You can see the Ladybird projects issue tracker[0] and issues on the Swift forum that LB maintainers have created[1][2] to get an idea. Swift adoption has stalled due to these.
It’s not perfect but if that’s your standard, then that cuts a lot of stuff from both languages :-)
I’m not sure why annotations are a bad thing to you. They’re not necessarily swift specific and could benefit other bindings too, and their existence doesn’t mitigate that it’s a binding. Or do you not consider rust being bindable to any non-C language since you’d have to write CFFI bindings in between?
Could be better, think .NET Core 1.1 timeframe when Microsoft finally decided to make it cross-platform.
You get the bare bones standard library, some of it still WIP, and naturally most libraries were written expecting an Apple platform.
Windows workgroup was announced yesterday, and Linux support is mostly for macOS/iOS devs deploying some server code, because naturally OS X Server is no more.
Not quite systems programming but this might give you some insight. Swift is memory efficient, and runs stable backend services. I've seen benchmarks showing that it's slightly more performant than typescript but twice as memory efficient (but not as efficient when it comes to memory management compared to Rust, C, and C++).
The other point I've seen is that its string library is slow and very accurate.
Besides that, the C-interop means you have quite a bit of flexibility in leveraging existing libraries.
>The other point I've seen is that its string library is slow and very accurate.
Swift strings default to operating on grapheme clusters, which is relatively slow. But you can always choose to work with the underlying UTF-8 representation or with unicode scalars, which is fast.
The only situation where UTF-8 incurs overhead is if the String comes from some old Objective-C API that gives you a UTF-16 encoded String.
Unicode scalars are not so fast. But yes working directly with UInt8/Data bytes is efficient.
That’s how I took over maintenance of SwiftSoup and made it over 10x faster according to my benchmarks. Besides various other optimizations such as reducing copying, adding indexes, etc.
Being only slightly more performant than an interpreted GC-only language is hard to believe (even though typescript is just a spec and you probably meant slightly more performant than v8).
> Traditionally I would say it feels more like Ada, Modula-2, Object Pascal.
Well, that's from the Objective C history; and Objective C borrows a lot from those languages.
The thing is, once you're doing systems programming, it's unlikely you're going to call any Objective C APIs, or APIs that have an Objective C history. You're more likely to call something in C.
It's lovely, not “always has been” but since, say, 5.10.
// I'm an originally Pascal and assembly dev (learned most Internet dev langs along the way) who hated what people did with Java (until last 5 years), failed to like Ruby, liked Clojure, disliked go, did like Nim, but really found Swift to be fresh air for data shapes and flow. And the tooling experience with git repo to iCloud build to testflight is worth every penny of the annual dev fee.
I tried using it on Windows, but it failed to compile as soon as I used file IO. The error was non-descriptive and had no matches online. I couldn't figure it out so I tried it without file IO, but as others have said the compiler is odd, the errors are odd, and in general doesn't feel like the tooling is nearly as good as most other popular languages
It’s a lovely language but the compiler has got to be the most unreliable I’ve ever seen.
It crashes semi-frequently. And it will sometimes try to run analyses that are way beyond O(n). So you can have perfectly valid code that it can’t compile, until you simplify or reduce the size of some function.
The runtime-wry-ffi (https://github.com/velox-apps/velox/blob/f062211ced4c021d819...) file which is 3.2K lines long and has close to a 100 unsafe calls, isn't that just interacting with wry which has it's own crate you could use instead? I'm not 100% sure, but seems to be basically the same as wry itself but without the cross-platform stuff, is that the purpose of that file?
Together with the author's distaste for Rust, it seems awfully dangerous instead of pulling in a crate made by Rust developers, but I might misunderstand the purpose of the file here.
I believe that is wrapping the Wry crate (and a few other crates) in a C API that can be accessed over FFI (which can then presumably be called directly be Swift code).
Thanks for helping me understand! So to clarify, that file is wrapping Wry with a C API, and Wry itself is merely wrapping whatever webview is available on the OS?
Shouldn't this kind of work be upstreamed to the original project, though? It would enable wry to export a libwry.so dynamic library for general use in any language that can FFI with C.
As someone who understand the sentiment, I wouldn't call it distaste for Rust. It feels more as Rust not being the right tool for the job and to be honest I have the same feeling here. Rust is great for a bunch of problem domains, but it doesn't feel to be the best tool for this specific problem domain.
It's always about the choices a programming language makes, it make it good for some use-cases and bad for others and there's nothing wrong with it.
Also as a cautionary tale about panacea programming languages, Java once tried it with great success to be "the one" language to rule them all and we can see that even though it was a popular choice in many domains, slowly other fitting solutions to specific problem domains took over. Proving that there is no such a thing, unfortunately for us, but some languages gets closer than others (Rust being one of them).
Swift is a great language for app development, and many app developers already know and use it on iOS, macOS, and Android and want to use it for more platforms too.
Swift users aren’t choosing between Rust and Swift. They’re looking to use Swift more. I think that’s why this is valuable - it doesn’t need to be centered around why one wouldn’t use Rust.
I have always felt like Swift is the king of application development. The syntax and ergonomics really lend itself to UIs and the like. It's a shame that the Swift compiler is on the slow side.
The best way I've found to mitigate the compiler speed issue is to factor my application workspace into different sub-projects, so that the sub-projects don't get built every time I make a change. It makes a huge difference and, honestly, it's something I should have been doing anyway, just for good architectural layering.
Have built a cross alternative tailscale gui client based on tauri, the rust and ffi to cgo tailscale feel a little tough, I was wondering it will save a lot time to me if the tauri had been written in go.
Seems Miguel’s velox point a new idea, leveraging the wry and use ffi to go, and rewrite some tooling.
I hope I will have the spare time and energy to give a try…
I asked the author about whether this could be ported to support Android/Linux/Windows and he was optimistic it would not be much trouble. So I plan to look into that.
What I’d like to determine first is if I can use this for brownfield development: on Apple platforms I’d like to stick to native SwiftUI and use Velox only for some views inside of a SwiftUI host application. And then on other platforms it can be fully Velox.
I can’t find any info on people doing this with Tauri. Expo recently added this about a month ago for React Native but I’d prefer to use Swift everywhere. I appreciate any info.
He specifically says he likes Rust, just not for GUI app development. He also puts that on himself rather than blaming the language.
Which is not a hot take by any means, even in the rust community. A lot of UI based app paradigms don’t map easily to rust, outside of immediate mode UIs.
> I am too old to develop an appreciation for poetry or Rust
Basically he says he's in favor of Rust being used for security reasons but he doesn't like using it (which is fair, honestly, I don't like C# much either).
Also, there arguably no programming language that works well with UI, which is why we keep reinventing new paradigm every few years. People love saying Rust doesn't works well for UI because it doesn't works well for the old OO-based UI, but it's not how most people write UIs nowadays anyway: the current most popular paradigm for writing UI by far is React and its derivatives (or rather, the Elm derivatives), which isn't something I'm personally fond of but this paradigm at least works flawlessly with Rust (hence Dioxus).
And off course given that Tauri's default is about writing the app's GUI in JavaScript, the argument about Rust being a bad fit for GUI never made sense in the first place (and Icaza never maid it himself, by the way, see how there's no reference to GUI in the statement: “but I do not love it to write apps”).
There are definitely languages that work well with UIs. I’m not sure how you can make that clear cut a statement?
C++ and Python map extremely well to Qt which is one of the predominant UI frameworks. ObjC maps really well to AppKit/UIKit. Anything small talk derived has been a pretty strong fit for UI work
Just because new paradigms are made, doesn’t mean the old ones are inherently bad either.
> C++ and Python map extremely well to Qt which is one of the predominant UI frameworks
Qt used to be predominent, but it really cannot be said in 2026 given that there's probably two orders of magnitude between the number of React Apps and the number of Qt ones being made in this decade…
> Just because new paradigms are made, doesn’t mean the old ones are inherently bad either
Yet barely anyone uses the old ones anymore. Surely it must not be only because people like new and shiny things (React being more than a decade old at this point makes it far from “new and shiny” anyway).
> ObjC maps really well to AppKit/UIKit.
This example is particularly interesting given that Apple moved away from their old UI tech on favor of SwiftUI, which isn't OO-based.
1. I said “one of the predominant”, that there are other frameworks ahead of it doesn’t mean it’s not in the top set of UI frameworks. Especially for native apps and automotive / medical use cases.
2. I think you might be living in a bubble if you think “barely anyone uses them”. Qt still has massive use , entire industries are dependent on it.
3. This is a misunderstanding of SwiftUI. Many aspects of the underlying parts of SwiftUI are still AppKit/uikit based. It’s about declarative vs imperative, and about react style development. SwiftUI being better doesn’t mean that the old paradigms were inherently bad or unsuitable like you suggested
> Especially for native apps and automotive / medical use cases.
It used to be the case, but even those sectors made the move to web GUIs. Heck even the Windows start menu is an Electron app nowadays.
> 2. I think you might be living in a bubble if you think “barely anyone uses them”. Qt still has massive use , entire industries are dependent on it.
I'm not. I've worked in medical devices and train control systems, on projects that would have been Qt based a decade earlier but had moved to web UIs. I even have a friend working for a defense company who told me that the UI for their latest AA weapon system was built with web technologies! That even the most conservative industry out there has started migrating tells you all you need to know.
Qt is definitely in the “legacy technology” category at this point and has been for a while. That doesn't mean it's dead, like Cobol it won't die before the last system using it will, but it's still far less relevant than it used to be.
> SwiftUI being better doesn’t mean that the old paradigms were inherently bad or unsuitable like you suggested
I'm not saying they were unsuitable, but they definitely weren't good enough which is why the entire industry has moved to something else. (The said alternative is far from perfect either, though).
Even if React is technically the most popular, that’s somewhat moot because most folks who might be interested in writing desktop apps with Rust probably aren’t coming from a web background, but instead from old school desktop UI frameworks (AppKit, win32, GTK, Qt, etc).
For this crowd, the barebones “bring your own everything” style of React and its analogues and contortions required to write apps with complex UIs in a declarative framework are not very appealing. OO imperative UI frameworks with a wide and deep chest of batteries-included widgets still come out on top for this particular use case. Minimal declarative frameworks are fine for light utilities but become progressively more cumbersome every step beyond that.
> most folks who might be interested in writing desktop apps with Rust probably aren’t coming from a web background, but instead from old school desktop UI frameworks
You'd be surprised. A lot of people migrating to desktop apps are people coming from a web background (this is after all by far the largest pool of UI developers) who want something more efficient than electron.
“More efficient” is relative. While tauri and dioxus can lower the install size, they’re not going to be meaningfully more efficient than electron for memory usage or speed since Chrome probably does better than the other frameworks, and consistently across OSes which dioxus and tauri struggle with since they are dependent on the host OS’s web implementation. Slint is interesting here but then it’s more rust and less web coding.
Oh, "more efficient" here isn't a refence to Tauri. It's a reference to the parent comment's mention of "(AppKit, win32, GTK, Qt, etc)".
I work on a framework (Dioxus Native) which I think sits at an interesting intersection of "rust" and "web": it renders using HTML/CSS (custom implementation, not using a webview) but it uses Rust scripting instead of JavaScript.
> 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.
https://v2.tauri.app/start/
reply