Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Apps in Rust

github.com

Post reply on HN
Print view View original

21–30 of 89 posts

Re: macOS Apps in Rust

#21

Post by josephg »

meatjuice wrote: post #7

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 against this api will not work on any other platform.

Re: macOS Apps in Rust

#22

Post by jb1991 »

jb1991 wrote: post #6
kennywinker wrote: post #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

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.

Forgot the link: https://www.swift.org/cxx-interop-workgroup/

Re: macOS Apps in Rust

#23

Post by xanathar »

tempodox wrote: post #17

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

Re: macOS Apps in Rust

#24

Post by sbt567 »

heavyset_go wrote: post #10
hot_gril wrote: post #5

Earlier quoted context omitted.

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.

There is a recent article about this on r/rust https://blog.logrocket.com/build-desktop-app-qt-rust/

Re: macOS Apps in Rust

#25

Post by foldr »

ThePhysicist wrote: post #16
heavyset_go wrote: post #10

Earlier quoted context omitted.

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.

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

Re: macOS Apps in Rust

#26

Post by criddell »

olliej wrote: post #20
apatheticonion wrote: post #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…

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 application than a well written cross platform application.

Re: macOS Apps in Rust

#27

Post by amelius »

olliej wrote: post #20
apatheticonion wrote: post #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…

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

Can you give an example of something can only be done in a native app?

And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

Re: macOS Apps in Rust

#28

Post by astrange »

amelius wrote: post #27
olliej wrote: 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"…

Can you give an example of something can only be done in a native app? And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

> Can you give an example of something can only be done in a native app?

Accessibility, text field behaviors, control animations looking right, window resizing behaviors, any system settings related to UI applying properly, printing, export to PDF, rich text copy and paste, normal power and memory use, the engineers working on the next OS release being able to fix your app if they break it, your app updating to the next OS version's UI changes automatically…

Re: macOS Apps in Rust

#30

Post by tcfhgj »

astrange wrote: post #28
amelius wrote: post #27

Earlier quoted context omitted.

Can you give an example of something can only be done in a native app? And why wouldn't a hybrid approach work? I.e. the majority of the code using the cross platform toolkit, and a small amount of code per platform using the native API.

> Can you give an example of something can only be done in a native app? Accessibility, text field behaviors, control animations looking right, window resizing behaviors, any system settings related to UI applying properly, printing, export to PDF, rich text copy and paste, normal power and memory use, the engineers working on the next OS release being able to fix your app if they break it, your app updating to the n…

afaik not a problem with apps written in something like react native which use platform specific widgets and common business logic.
Post reply on HN