On my Mac, I've written in Rust quite a few utilities, but until now, they were for my personal use only, and run in the Terminal exclusively. Over the years, these utilities have gotten quite elaborate, and now, I would like to sell some of them in the Mac App Store, because I think other people might be interested in buying them, and because I am poor.
So, I would like to convert my Terminal apps to commercial GUI apps, in such a way that they would be accepted in the Mac App Store. What would be the best way to do this? Among Rust GUI frameworks, "Gtk-rs" looks the most promising, but would Apple actually accept "Gtk-rs" apps in its store? If not, I guess the other solution would be to build the front-end in Swift, and to use my existing Rust code only as back-end, but this looks dawnting for me: I would have to learn the Swift language, and the XCode tooling, from the ground up, at which point I might just as well rewrite everything in Swift, instead of trying to bridge the two languages.
Thank you in advance for your advice or your experience!
I'm afraid there are no good options for GUIs in rust.
Another option that is often overlooked is wxWidgets. At least there it will be cross platform with platform native widgets. Or QT where it is easier to make it look pretty and keep it cross platform. That way if or when you need to move to another platform the path is straightforward.
As for bridging. Depending on the API surface the method I usually employ to avoid writing a whole lot of annoying bridging code is to serialize objects from one side to the other. Json is always well supported, if better performance is required something like flatbuffers could be used.
Your best option probably is to write a thin UI layer in Swift or Objective C, and then have an API to the Rust backend. All three languages have great interoperability with C, so you can use that as the interface layer.
Thank you all for your informative answers! I think I will follow the majority's vote, and use Swift for the front-end and Rust for the back-end. I was worried about exchanging complex data between the two languages, but Sergej's suggestion of using a binary serialization format, equivalent to JSON, as go-between makes perfect sense to me. I should've thought about it myself. After some research, MessagePack looks like an efficient format of this kind: it's supported by the "serde" crate in Rust, which I am quite familiar with, and I found a MessagePack implementation written in Swift. But if you have other suggestions or ressources for bridging Rust and Swift, I am all ears!
If your utilities aren't macOS-only you should definitely go for QT. If you only need to deploy on macOS, then stick to your choice of writing the UI in Xcode with Swift and use your Rust code as back-end.
An example of this kind of thing working well in practice - the Language Server Protocol (used by VS Code and other IDEs to talk to language servers written in any language) is actually built on top of the JSON-RPC spec. So whenever you're using, for example, the RLS, your editor is actually sending JSON messages to another library/process and back.
If something like that can be performant enough to react to your keypresses in an editor, it's probably good for most cases
Shipping multiple binaries in a MAS app is pretty complicated due to code signing and sandbox requirements. The best way to do that is an XPC service that uses a complicated message passing system, which can be killed at any moment by the system.
You can't compare that to Electron or VS Code, as these aren't distributed through the Mac App Store (and also, couldn't).
Calling a library seems more robust to me than launching a distributable binary. Also, I think that a distributable binary would be extremely prone to commercial theft (I am creating a paid product, after all).
The problem is that you have to sign every executable you ship. If you create a separate executable for your rust code, you have to sign it manually (since Xcode can't help you there). This is possible, but even harder than getting Xcode to properly sign your binaries (which I've already wasted countless hours on).