Velox: A Port of Tauri to Swift by Miguel de Icaza
github.com
github.com
> 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'm rather unfamiliar with his work post-mono.
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.
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.
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.
"What Killed the Linux Desktop"
https://tirania.org/blog/archive/2012/Aug-29.html
"How I ended up with Mac"
// 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.
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.
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.
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.
The unicode-segmentation crate implements this for Rust, in case it matters for accuracy.
It also has C++ interop btw
Depending on your goals, it's worth giving C# a test-drive given Swift's similarity to C#.
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.
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.
Also Objective-C has nothing to do with those languages, so I got lost in what history.
It picks from C and Smalltalk.
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.
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.
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.
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.
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.
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...
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?
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.
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).
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 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.
Your satisfaction might be different, enjoy it!
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…
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.
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.
I looked at Tauri like an Electron alternative that in the future will run with Servo under the hood.
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.
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”).
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.
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.
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
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 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.
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.
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.
"interpreter.js" is for Dioxus's "web" backend which runs in browsers (who instantiate the JS engine). All it does is interpret "patch commands" to apply DOM mutations.