> 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.
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.
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?
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.
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?
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
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).
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.
> 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.
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.
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.
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”).
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.
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).
For the uninitiated:
> 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/
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).
Also, let's not forget he's the one who brought Swift to the Godot engine https://github.com/migueldeicaza/SwiftGodot
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.
If I don’t use Mono or Gnome, what else from him is part of my stack today?
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.
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?
i'm rather unfamiliar with his work post-mono.
He also wrote (or at least started) midnight commander!
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.
Swift really does hit a sweet spot.
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.
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.
Swift is pretty good.
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 disagree that rust can be as ergonomic. I’ve been writing rust for longer than Swift , and there’s a lot of niceties in Swift.
Default parameters, null shortcircuits, lazy static initializers, computed properties, ease of binding to C++, RC by default, defer.
Both languages are great, but I don’t think they’re on the same ergonomic level by any means.
> ease of binding to C++
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.
0: https://github.com/LadybirdBrowser/ladybird/issues/933
1: https://forums.swift.org/t/ladybird-browser-and-swift-garbag...
2: https://forums.swift.org/t/ladybird-gc-and-imported-class-hi...
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?
Here's what I wrote on this subject back in September. Nothing has changed so far as I can see.
https://news.ycombinator.com/item?id=45417366
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
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.
> Swift strings default to operating on grapheme clusters, which is relatively slow.
The unicode-segmentation crate implements this for Rust, in case it matters for accuracy.
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).
That's right, I said TypeScript but yeah, it's v8 under the hood.
For web server benchmarks, it’s far behind typescript. Async has further degraded performance competitiveness
It also has C++ interop btw
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.
Swift "feels" like C#. A lot of systems programming is done in C#.
Depending on your goals, it's worth giving C# a test-drive given Swift's similarity to C#.
Traditionally I would say it feels more like Ada, Modula-2, Object Pascal.
And if making reference counting part of the picture, Cedar, Modula-2+,...
Finally catching up with what we already had in the 1990's and lost, in a couple of decades split between C, C++ and VM based languages.
> 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.
NeXTSTEP systems programming was done in Objective-C, including writing drivers.
Also Objective-C has nothing to do with those languages, so I got lost in what history.
It picks from C and Smalltalk.
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.
Quite enjoyable. Some compiler errors are a pain.
What an understatement :)
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?
> 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?
Yep, that sounds about right to me. Although it looks like that file is also wrapping Tao (which is a cross-platform windowing/event loop library).
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.
> Together with the author's distaste for Rust
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.
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…
Just in case you missed it and are interested in a go alternative https://wails.io/
A "port" or "a nice Swift API for it"? It seems like the latter in that it requires cargo (the rust build chain) to build.
It uses the Tao and Wry crates the same as Tauri does. So it's a port of Tauri but not of its dependencies
Ah, thanks for the clarification.
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.
Not to be confused with Velox a compute engine https://github.com/facebookincubator/velox/
Eh. Dioxus to me is the more interesting project honestly.
Could it feasibly be wrapped or ported to Swift?
It doesn't tick the “I dislike Rust” box which is apparently the main motivation for this project.
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”).
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.
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).