Live data from Hacker News

macOS Apps in Rust

github.com

1–10 of 89 posts

Re: macOS Apps in Rust

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

Re: macOS Apps in Rust

#3
> 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

Re: macOS Apps in Rust

#4
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.

Re: macOS Apps in Rust

#5

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…

The GUI bindings are usually the hard part.

Re: macOS Apps in Rust

#6

> 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

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.

Re: macOS Apps in Rust

#8

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 iDevice…

More tangential, is there a good, in-depth resource for learning how to build an app in AppKit w/ Swift?

Re: macOS Apps in Rust

#10
post #5

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…

The GUI bindings are usually the hard part.

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.
Post reply on HN