32 ms·

Velox: A Port of Tauri to Swift by Miguel de Icaza

173 points by wahnfrieden 9mo ago

boxed 9mo ago
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.
- m12k 9mo ago
  It uses the Tao and Wry crates the same as Tauri does. So it's a port of Tauri but not of its dependencies
  - boxed 9mo ago
    Ah, thanks for the clarification.
embedding-shape 9mo ago
The runtime-wry-ffi (https://github.com/velox-apps/velox/blob/f062211ced4c021d8193c5e2cef7d5a2a34c9132/runtime-wry-ffi/src/lib.rs 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.
- nicoburns 9mo ago
  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).
  - embedding-shape 9mo ago
    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?
    - nicoburns 9mo ago
      > 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).
  - zozbot234 9mo ago
    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.
- oscargrouch 9mo ago
  > 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).
  - deleted 9mo ago
    [deleted]
  - wahnfrieden 9mo ago
    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.
- migueldeicaza 9mo ago
  I don’t distrust rust, I think it is great for some things. But I write code to enjoy myself and swift hits the spot between safety and satisfaction for me. Your satisfaction might be different, enjoy it!
robert3005 9mo ago
Not to be confused with Velox a compute engine https://github.com/facebookincubator/velox/ https://github.com/facebookincubator/velox/
- deleted 9mo ago
  [deleted]
vlovich123 9mo ago
Eh. Dioxus to me is the more interesting project honestly.
- littlestymaar 9mo ago
  It doesn't tick the “I dislike Rust” box which is apparently the main motivation for this project.
  - dagmx 9mo ago
    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.
    - littlestymaar 9mo ago
      > 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”).
      - dagmx 9mo ago
        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.
hollowturtle 9mo ago
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
- Terretta 9mo ago
  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.
- ppeetteerr 9mo ago
  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.
  - fauigerzigerk 9mo ago
    >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.
    - wahnfrieden 9mo ago
      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.
mintflow 9mo ago
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…
- hollowturtle 9mo ago
  Just in case you missed it and are interested in a go alternative https://wails.io/ https://wails.io/
walski 9mo ago
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/ https://v2.tauri.app/start/
wahnfrieden 9mo ago
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.
bsharper 9mo ago
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).
- bhadass 9mo ago
  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.
  - pjmlp 9mo ago
    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.
    - pixelready 9mo ago
      Development focused on iPadOS as an export platform, or using an iPad as the actual dev environment?
      - debugnik 9mo ago
        Actual dev environment, they've ported the Godot editor to SwiftUI and touch controls. https://xogot.com/ https://xogot.com/
        pixelready 9mo ago
        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.
taylorallred 9mo ago
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.
- pohl 9mo ago
  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.
  - wahnfrieden 9mo ago
    This recent project looks interesting for improving build times without having to abandon SPM: https://xccache.trinhngocthuyen.com https://xccache.trinhngocthuyen.com which is a UI for managing https://github.com/trinhngocthuyen/xccache https://github.com/trinhngocthuyen/xccache
ray023 9mo ago
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.

173 points by wahnfrieden 9mo ago

boxed 9mo ago

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.

m12k 9mo ago
It uses the Tao and Wry crates the same as Tauri does. So it's a port of Tauri but not of its dependencies
- boxed 9mo ago
  Ah, thanks for the clarification.

embedding-shape 9mo ago

The runtime-wry-ffi (https://github.com/velox-apps/velox/blob/f062211ced4c021d8193c5e2cef7d5a2a34c9132/runtime-wry-ffi/src/lib.rs 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.

nicoburns 9mo ago
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).
- embedding-shape 9mo ago
  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?
  - nicoburns 9mo ago
    > 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).
- zozbot234 9mo ago
  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.
oscargrouch 9mo ago
> 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).
- deleted 9mo ago
  [deleted]
- wahnfrieden 9mo ago
  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.
migueldeicaza 9mo ago
I don’t distrust rust, I think it is great for some things. But I write code to enjoy myself and swift hits the spot between safety and satisfaction for me. Your satisfaction might be different, enjoy it!

robert3005 9mo ago

Not to be confused with Velox a compute engine https://github.com/facebookincubator/velox/ https://github.com/facebookincubator/velox/

deleted 9mo ago
[deleted]

vlovich123 9mo ago

Eh. Dioxus to me is the more interesting project honestly.

littlestymaar 9mo ago
It doesn't tick the “I dislike Rust” box which is apparently the main motivation for this project.
- dagmx 9mo ago
  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.
  - littlestymaar 9mo ago
    > 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”).
    - dagmx 9mo ago
      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.

hollowturtle 9mo ago

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

Terretta 9mo ago
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.
ppeetteerr 9mo ago
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.
- fauigerzigerk 9mo ago
  >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.
  - wahnfrieden 9mo ago
    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.

mintflow 9mo ago

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…

hollowturtle 9mo ago
Just in case you missed it and are interested in a go alternative https://wails.io/ https://wails.io/

walski 9mo ago

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/ https://v2.tauri.app/start/

wahnfrieden 9mo ago

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.

bsharper 9mo ago

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).

bhadass 9mo ago
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.
- pjmlp 9mo ago
  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.
  - pixelready 9mo ago
    Development focused on iPadOS as an export platform, or using an iPad as the actual dev environment?
    - debugnik 9mo ago
      Actual dev environment, they've ported the Godot editor to SwiftUI and touch controls. https://xogot.com/ https://xogot.com/
      - pixelready 9mo ago
        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.

taylorallred 9mo ago

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.

pohl 9mo ago
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.
- wahnfrieden 9mo ago
  This recent project looks interesting for improving build times without having to abandon SPM: https://xccache.trinhngocthuyen.com https://xccache.trinhngocthuyen.com which is a UI for managing https://github.com/trinhngocthuyen/xccache https://github.com/trinhngocthuyen/xccache

ray023 9mo ago

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.