9 ms·

macOS Apps in Rust

184 points by debdut 3y ago

kitsunesoba 3y ago
Interesting to see that AppKit is fully supported before UIKit, usually it's the reverse (if AppKit is supported at all). I suppose it kind of makes sense… the case for sharing a Rust core across platforms is stronger on macOS, because on iOS the optimizations you're trading away (such as the native network stack scheduling requests from apps to fire while the antenna is already awake) have a bigger impact on iDevices. Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious, and I'm not sure that it'd be the tool I reach for when developing apps with UIs… from a distance it feels better suited for CLI tools, back ends, and the nuts'n'bolts parts under the hood of UI apps. In comparison it makes some tradeoffs but I really enjoy writing UI apps in Swift (albeit in UIKit/AppKit — SwiftUI needs more time in the oven).
- imbnwa 3y ago
  More tangential, is there a good, in-depth resource for learning how to build an app in AppKit w/ Swift?
  - kitsunesoba 3y ago
    Unfortunately I can't point you at a single comprehensive resource. Instruction for building apps in AppKit has always been kind of spotty. When I first started learning it alongside Objective-C in the 2000s, the best a beginner could really do was sift through random blogposts and mimic patterns seen in FOSS Mac apps. The best resources at that point were probably the various books on the topic (such as the Big Nerd Ranch Cocoa books I'd seen recommended frequently) but at that point I was a broke teenager so buying books was off the table. I would like to at some point build a one stop shop for learning all the most pertinent parts of building a Mac app with AppKit and Swift, but that takes a lot of time… if it happens it'd probably be when I'm inbetween jobs so I can dedicate the resources required to make such a thing good.
    - imbnwa 3y ago
      Gotcha, thanks for the reply. I think you'd have the market on this domain cornered if ever you'd produced a comprehensive text since its very much still blog posts and reading extant code.
- 59nadir 3y ago
  > Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious [...] Assuming your trepidation is because memory management is somehow more manual in Rust I would argue that it's actually not. This isn't something I'm saying because I want to convince you to use Rust; I'm actually of the opinion that Rust doesn't give you enough direct control of memory allocation and has iffy support for custom allocators on top. Rust's memory management is much more like a garbage collected language in practice, hence why I consider it too indirect.
  - kitsunesoba 3y ago
    From the bits of Rust code I've seen, it seems like while memory management isn't exactly manual, it needs to be given a fair amount of thought, what with borrow semantics and such. When writing Swift I very infrequently have to give it any thought at all, beyond avoiding retain cycles (which is usually as simple as using weak references to self in closures).
    - duped 3y ago
      There's no obligation to pass everything in references. You can wrap most things in Box/Rc/Arc and move on with your life.
      - WastingMyTime89 3y ago
        But why bother using Rust then? If you are going to use it like a garbage collected language, you would be better served by one of the slew of other languages with the same features but which are easier to use. The memory management is what sets Rust apart.
- Klonoar 3y ago
  Author here. :) AppKit is first because this was extracted from a cross platform GUI library I was building years ago, and it’s just less cumbersome to iterate on.
kennywinker 3y ago
> I would be surprised if we didn't have another ~5+ years of support Five years would shock me. I’d say more like ten. It’s gonna take a huge concerted effort to get rid of objc in macos, and idk if it’s worth it
- jb1991 3y ago
  There’s a proposal to allow C++ and Swift to interact in the same way that objc and C++ interact, and if that were to eventually become part of swift then objc’s days are numbered. Right now, one of the most significant reasons to continue using objc is that you don’t have to wrap everything in a C API.
  - jb1991 3y ago
    Forgot the link: https://www.swift.org/cxx-interop-workgroup/ https://www.swift.org/cxx-interop-workgroup/
- Klonoar 3y ago
  FWIW, I’m the author and I think I wrote that line close to 5 years ago already… so you may be right. :)
apatheticonion 3y ago
Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. One could write their UI state and application logic once while maintaining 3 entry points using the various platform GUI bindings (gtk-rs, cacao, win32?) to represent the UI state. This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms - though you would still need to rewrite widgets/components for each platform independently. Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. After all, you can't horizontally scale a client device so it's important that an application is able to maximize its use of the available hardware. Rust's borrow checker/ownership model eliminates dangerous multi-threaded code which makes it practical to write highly efficient GUI applications. Could be good for projects like cross-platform terminal emulators or code editors.
- hot_gril 3y ago
  The GUI bindings are usually the hard part.
  - heavyset_go 3y ago
    Speaking of, does anyone know how Qt bindings for Rust are these days? Last time I looked, there were several awkward Rust APIs for Qt, suffering in part from the fact that Qt's API is inheritance-based.
    - ThePhysicist 3y ago
      I think it's pretty difficult mapping the Qt memory management model to Rust, for the same reason we haven't seen working Golang bindings for Qt either. I have some experience with the Python bindings (PySide or PyQt) and both of them use pretty extensive wrapper generator frameworks specially developed for the task (SIP in the case of PyQt, Shiboken in the case of PySide), coming up with something like that is not an easy task at all. And Python is a language that was pretty much intended to act as a foreign function wrapper around low-level languages, while Rust & Golang are not primarily intended to be wrappers for other languages.
meatjuice 3y ago
Is it a backend library for Slint?
- josephg 3y ago
  No. This is rust bindings to the native apple UI toolkits, UIKit and AppKit (on iOS and macos respectively). Using a library like this, your software will have a fully native look and feel. The result should be indistinguishable from the equivalent Swift or Obj-C app from the point of view of a user. Including all accessibility hooks, fully native widgets and things like that. The downside is that code written against this api will not work on any other platform.
  - wffurr 3y ago
    I’d take that downside over having to mix languages on each platform. UI toolkit Rust bindings for all the platforms I want to target would let me just write Rust instead of also having to write Swift, Java, JavaScript, etc.
brundolf 3y ago
Is... the name a Portlandia reference?
- bitwize 3y ago
  It could be a Portland reference. The city had a gourmet chocolate shop called Cacao that served "drinking chocolate" from 2005 until 2020. I know because I went in there after getting lost and drenched in a Portland February, and the staff there were kind enough to bring me towels and let me wait out the downpour while I sipped chocolate. But more than likely it's just a reference to Apple's Cocoa api.
  - sk0g 3y ago
    Am I missing something, is the name/reference just "cacao"? Many languages spell cocoa that way, so I would take the name as cocoa-but-exotic or cocoa-but-foreign.
- tobinfricke 3y ago
  https://en.wikipedia.org/wiki/Cacao https://en.wikipedia.org/wiki/Cacao
- tempodox 3y ago
  I take the name as a pun on the Cocoa API.
  - brundolf 3y ago
    Right, I think it's both
- Klonoar 3y ago
  Author here. Never seen Portlandia, so no. Just a Cocoa pun!
tempodox 3y ago
If you use the Cocoa API with ObjC or Swift, you get Automatic Reference Counting (ARC), generated by the compiler. I guess with this you'd have to retain / release your objects manually again?
- IshKebab 3y ago
  Rust has ARC too so I very much doubt it.
  - pjmlp 3y ago
    Nope, someone has to manually type .clone() calls.
    - IshKebab 3y ago
      That's irrelevant (and barely different to having to type `=`). The salient point is that you don't need to manually call free/release.
      - pjmlp 3y ago
        That is more than relevant, otherwise we are comparing oranges to apples, pun intended. Automatic Reference Counting. Since = is the same as .clone() in character count?
        IshKebab 3y ago
        Yes I'm aware that the A stands for Atomic in Rust, not Automatic. But it is still automatic because you do not need to increment and decrement the counter manually. > Since = is the same as .clone() in character count? Why does character count matter? I think you're getting a bit distracted from the point. Will you need to manually free/release objects? No you will not.
        deleted 3y ago
        [deleted]
ushakov 3y ago
1000 GitHub stars and not a single screenshot?
- nasretdinov 3y ago
  I presume the screenshots would look like a regular macOS app :)
- Klonoar 3y ago
  Author here - it’s a rust crate, run one of the many examples in the project. :)
jashephe 3y ago
A tangent: does anyone have recommendations for a library for easy Swift-Rust interop? This is a cool tool, but I’d much rather make a GUI natively with e.g. SwiftUI and then call out to Rust for business logic. The previous times I’ve looked into this, both languages had to communicate through a C intermediate, and handling more complex types became a chore…
- agg23 3y ago
  A bit late, but swift-bridge (https://github.com/chinedufn/swift-bridge https://github.com/chinedufn/swift-bridge) does this intelligently, and is probably what you're looking for.
- drizze 3y ago
  There was a talk given on this subject at iOSoho if ya want to take a peek: https://youtu.be/8ApcIOZe9qg?t=1921 https://youtu.be/8ApcIOZe9qg?t=1921
- lukax 3y ago
  Mozilla's uniffi-rs is really good. You write a common IDL and the bindings are generated automatically. It supports Swift, Kotlin, Python, Ruby and JavaScript (not in the official repo). https://github.com/mozilla/uniffi-rs https://github.com/mozilla/uniffi-rs
todd8 3y ago
This is off topic, but thinking about portable desktop apps, why didn’t JavaFx become more popular? What is JetBrains using for its sophisticated GUIs? Is it just Swing? It would be great if Rust could be used to write portable high quality desktop apps.
- RMPR 3y ago
  > why didn’t JavaFx become more popular? Oracle ditched it a long time ago [0] > What is JetBrains using for its sophisticated GUIs? Is it just Swing? They use custom Swing components [1] 0: https://www.infoworld.com/article/3261066/javafx-will-be-removed-from-the-java-jdk.html https://www.infoworld.com/article/3261066/javafx-will-be-rem... 1: https://plugins.jetbrains.com/docs/intellij/user-interface-components.html?from=jetbrains.org https://plugins.jetbrains.com/docs/intellij/user-interface-c...

184 points by debdut 3y ago

Interesting to see that AppKit is fully supported before UIKit, usually it's the reverse (if AppKit is supported at all). I suppose it kind of makes sense… the case for sharing a Rust core across platforms is stronger on macOS, because on iOS the optimizations you're trading away (such as the native network stack scheduling requests from apps to fire while the antenna is already awake) have a bigger impact on iDevices. Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious, and I'm not sure that it'd be the tool I reach for when developing apps with UIs… from a distance it feels better suited for CLI tools, back ends, and the nuts'n'bolts parts under the hood of UI apps. In comparison it makes some tradeoffs but I really enjoy writing UI apps in Swift (albeit in UIKit/AppKit — SwiftUI needs more time in the oven).

imbnwa 3y ago
More tangential, is there a good, in-depth resource for learning how to build an app in AppKit w/ Swift?
- kitsunesoba 3y ago
  Unfortunately I can't point you at a single comprehensive resource. Instruction for building apps in AppKit has always been kind of spotty. When I first started learning it alongside Objective-C in the 2000s, the best a beginner could really do was sift through random blogposts and mimic patterns seen in FOSS Mac apps. The best resources at that point were probably the various books on the topic (such as the Big Nerd Ranch Cocoa books I'd seen recommended frequently) but at that point I was a broke teenager so buying books was off the table. I would like to at some point build a one stop shop for learning all the most pertinent parts of building a Mac app with AppKit and Swift, but that takes a lot of time… if it happens it'd probably be when I'm inbetween jobs so I can dedicate the resources required to make such a thing good.
  - imbnwa 3y ago
    Gotcha, thanks for the reply. I think you'd have the market on this domain cornered if ever you'd produced a comprehensive text since its very much still blog posts and reading extant code.
59nadir 3y ago
> Tangentially related, I'd to dabble in Rust at some point but the syntax and memory management leave me trepidatious [...] Assuming your trepidation is because memory management is somehow more manual in Rust I would argue that it's actually not. This isn't something I'm saying because I want to convince you to use Rust; I'm actually of the opinion that Rust doesn't give you enough direct control of memory allocation and has iffy support for custom allocators on top. Rust's memory management is much more like a garbage collected language in practice, hence why I consider it too indirect.
- kitsunesoba 3y ago
  From the bits of Rust code I've seen, it seems like while memory management isn't exactly manual, it needs to be given a fair amount of thought, what with borrow semantics and such. When writing Swift I very infrequently have to give it any thought at all, beyond avoiding retain cycles (which is usually as simple as using weak references to self in closures).
  - duped 3y ago
    There's no obligation to pass everything in references. You can wrap most things in Box/Rc/Arc and move on with your life.
    - WastingMyTime89 3y ago
      But why bother using Rust then? If you are going to use it like a garbage collected language, you would be better served by one of the slew of other languages with the same features but which are easier to use. The memory management is what sets Rust apart.
Klonoar 3y ago
Author here. :) AppKit is first because this was extracted from a cross platform GUI library I was building years ago, and it’s just less cumbersome to iterate on.

kennywinker 3y ago

> I would be surprised if we didn't have another ~5+ years of support Five years would shock me. I’d say more like ten. It’s gonna take a huge concerted effort to get rid of objc in macos, and idk if it’s worth it

jb1991 3y ago
There’s a proposal to allow C++ and Swift to interact in the same way that objc and C++ interact, and if that were to eventually become part of swift then objc’s days are numbered. Right now, one of the most significant reasons to continue using objc is that you don’t have to wrap everything in a C API.
- jb1991 3y ago
  Forgot the link: https://www.swift.org/cxx-interop-workgroup/ https://www.swift.org/cxx-interop-workgroup/
Klonoar 3y ago
FWIW, I’m the author and I think I wrote that line close to 5 years ago already… so you may be right. :)

apatheticonion 3y ago

Pretty cool project, seems like it's becoming more realistic to write cross platform native desktop applications with OS-specific GUIs in Rust. It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. One could write their UI state and application logic once while maintaining 3 entry points using the various platform GUI bindings (gtk-rs, cacao, win32?) to represent the UI state. This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms - though you would still need to rewrite widgets/components for each platform independently. Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. After all, you can't horizontally scale a client device so it's important that an application is able to maximize its use of the available hardware. Rust's borrow checker/ownership model eliminates dangerous multi-threaded code which makes it practical to write highly efficient GUI applications. Could be good for projects like cross-platform terminal emulators or code editors.

hot_gril 3y ago
The GUI bindings are usually the hard part.
- heavyset_go 3y ago
  Speaking of, does anyone know how Qt bindings for Rust are these days? Last time I looked, there were several awkward Rust APIs for Qt, suffering in part from the fact that Qt's API is inheritance-based.
  - ThePhysicist 3y ago
    I think it's pretty difficult mapping the Qt memory management model to Rust, for the same reason we haven't seen working Golang bindings for Qt either. I have some experience with the Python bindings (PySide or PyQt) and both of them use pretty extensive wrapper generator frameworks specially developed for the task (SIP in the case of PyQt, Shiboken in the case of PySide), coming up with something like that is not an easy task at all. And Python is a language that was pretty much intended to act as a foreign function wrapper around low-level languages, while Rust & Golang are not primarily intended to be wrappers for other languages.

meatjuice 3y ago

Is it a backend library for Slint?

josephg 3y ago
No. This is rust bindings to the native apple UI toolkits, UIKit and AppKit (on iOS and macos respectively). Using a library like this, your software will have a fully native look and feel. The result should be indistinguishable from the equivalent Swift or Obj-C app from the point of view of a user. Including all accessibility hooks, fully native widgets and things like that. The downside is that code written against this api will not work on any other platform.
- wffurr 3y ago
  I’d take that downside over having to mix languages on each platform. UI toolkit Rust bindings for all the platforms I want to target would let me just write Rust instead of also having to write Swift, Java, JavaScript, etc.

brundolf 3y ago

Is... the name a Portlandia reference?

bitwize 3y ago
It could be a Portland reference. The city had a gourmet chocolate shop called Cacao that served "drinking chocolate" from 2005 until 2020. I know because I went in there after getting lost and drenched in a Portland February, and the staff there were kind enough to bring me towels and let me wait out the downpour while I sipped chocolate. But more than likely it's just a reference to Apple's Cocoa api.
- sk0g 3y ago
  Am I missing something, is the name/reference just "cacao"? Many languages spell cocoa that way, so I would take the name as cocoa-but-exotic or cocoa-but-foreign.
tobinfricke 3y ago
https://en.wikipedia.org/wiki/Cacao https://en.wikipedia.org/wiki/Cacao
tempodox 3y ago
I take the name as a pun on the Cocoa API.
- brundolf 3y ago
  Right, I think it's both
Klonoar 3y ago
Author here. Never seen Portlandia, so no. Just a Cocoa pun!

tempodox 3y ago

If you use the Cocoa API with ObjC or Swift, you get Automatic Reference Counting (ARC), generated by the compiler. I guess with this you'd have to retain / release your objects manually again?

IshKebab 3y ago
Rust has ARC too so I very much doubt it.
- pjmlp 3y ago
  Nope, someone has to manually type .clone() calls.
  - IshKebab 3y ago
    That's irrelevant (and barely different to having to type `=`). The salient point is that you don't need to manually call free/release.
    - pjmlp 3y ago
      That is more than relevant, otherwise we are comparing oranges to apples, pun intended. Automatic Reference Counting. Since = is the same as .clone() in character count?
      - IshKebab 3y ago
        Yes I'm aware that the A stands for Atomic in Rust, not Automatic. But it is still automatic because you do not need to increment and decrement the counter manually. > Since = is the same as .clone() in character count? Why does character count matter? I think you're getting a bit distracted from the point. Will you need to manually free/release objects? No you will not.
        deleted 3y ago
        [deleted]

ushakov 3y ago

1000 GitHub stars and not a single screenshot?

nasretdinov 3y ago
I presume the screenshots would look like a regular macOS app :)
Klonoar 3y ago
Author here - it’s a rust crate, run one of the many examples in the project. :)

jashephe 3y ago

A tangent: does anyone have recommendations for a library for easy Swift-Rust interop? This is a cool tool, but I’d much rather make a GUI natively with e.g. SwiftUI and then call out to Rust for business logic. The previous times I’ve looked into this, both languages had to communicate through a C intermediate, and handling more complex types became a chore…

agg23 3y ago
A bit late, but swift-bridge (https://github.com/chinedufn/swift-bridge https://github.com/chinedufn/swift-bridge) does this intelligently, and is probably what you're looking for.
drizze 3y ago
There was a talk given on this subject at iOSoho if ya want to take a peek: https://youtu.be/8ApcIOZe9qg?t=1921 https://youtu.be/8ApcIOZe9qg?t=1921
lukax 3y ago
Mozilla's uniffi-rs is really good. You write a common IDL and the bindings are generated automatically. It supports Swift, Kotlin, Python, Ruby and JavaScript (not in the official repo). https://github.com/mozilla/uniffi-rs https://github.com/mozilla/uniffi-rs

todd8 3y ago

This is off topic, but thinking about portable desktop apps, why didn’t JavaFx become more popular? What is JetBrains using for its sophisticated GUIs? Is it just Swing? It would be great if Rust could be used to write portable high quality desktop apps.

RMPR 3y ago
> why didn’t JavaFx become more popular? Oracle ditched it a long time ago [0] > What is JetBrains using for its sophisticated GUIs? Is it just Swing? They use custom Swing components [1] 0: https://www.infoworld.com/article/3261066/javafx-will-be-removed-from-the-java-jdk.html https://www.infoworld.com/article/3261066/javafx-will-be-rem... 1: https://plugins.jetbrains.com/docs/intellij/user-interface-components.html?from=jetbrains.org https://plugins.jetbrains.com/docs/intellij/user-interface-c...