Live data from Hacker News

macOS Apps in Rust

github.com

31–40 of 89 posts

Re: macOS Apps in Rust

#31
post #21

Is it a backend library for Slint?

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

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.

Re: macOS Apps in Rust

#32
post #25

Earlier quoted context omitted.

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

> https://github.com/therecipe/qt Do these not work? (Not a rhetorical question - I haven’t tried them.)

They used to work until the big modules change a few golang releases ago. Now, nothing works anymore unless you exhume a sufficiently old golang compiler.

The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ But I haven't tried that one.

Re: macOS Apps in Rust

#33
post #20

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…

You can't write good UI apps with cross platform code. The basic idioms of each platform are different. You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken. "modern"…

Yet among the most used apps a lot of them are cross platforms: chrome, ableton live, vscode, figma, any game under the sun, slack, discord, … I would even argue that very few still develop directly with native ui toolkits directly.

Re: macOS Apps in Rust

#34
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…

Re: macOS Apps in Rust

#35

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…

There was a talk given on this subject at iOSoho if ya want to take a peek:

https://youtu.be/8ApcIOZe9qg?t=1921

Re: macOS Apps in Rust

#36
post #20

Earlier quoted context omitted.

You can't write good UI apps with cross platform code. The basic idioms of each platform are different. You can write your core application logic once and share it, but you need to have the interaction with the actual UI/window manager be per-platform. The reason electron apps are so bad on Mac is not that the core application logic is bad, it's that a whole bunch of basic Mac platform behaviors are broken. "modern"…

Cross platform toolkits are a way of getting something good enough, quickly. Our standards may be different, but I would say you can get something good. You likely won’t get something great though. I agree with your statement about modern toolkits being no better than Java, but Java is pretty good. I’d have no problem starting a new project with it today. All that said, I’d much rather have a well written native appl…

If anything, many of them are much worse in capabilities.

https://www.oreilly.com/library/view/filthy-rich-clients/978...

Re: macOS Apps in Rust

#37

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?

Rust has ARC too so I very much doubt it.

Nope, someone has to manually type .clone() calls.

Re: macOS Apps in Rust

#38

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?

No. Rust has RAII so you can have retain on 'clone' operations and release on drops, just like the native Rc/Arc types do. This is, incidentally, how the servo bindings to core-foundation work (I prefer those bindings where there is overlap). Servo bindings: https://github.com/servo/core-foundation-rs Other crates of interest on this topic: - https://crates.io/crates/objc - https://crates.io/crates/block

Someone has to manually type .clone() calls.

Re: macOS Apps in Rust

#39

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…

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

Re: macOS Apps in Rust

#40
post #32
post #25

Earlier quoted context omitted.

> https://github.com/therecipe/qt Do these not work? (Not a rhetorical question - I haven’t tried them.)

They used to work until the big modules change a few golang releases ago. Now, nothing works anymore unless you exhume a sufficiently old golang compiler. The project also seems dead since 2020 or so, a current fork is https://github.com/bluszcz/cutego/ But I haven't tried that one.

I see what you mean about this particular project, but more generally, you can certainly use pre-modules Go code with current Go compilers. See e.g. https://github.com/golang/go/issues/37797 (a case of someone not RTFMing, but the response illustrates how it's done).

If you just want to pretend modules never happened, then export GO111MODULE=off and use the latest Go compiler.

Post reply on HN