Not Allowed To Open Rust Binary In Terminal

You haven't told us what goes wrong when you try to run it.

Finder When I double click on the binary in Finder, a second Terminal window opens up and says "Process Completed", with no opening of the GUI window.

CommanderOne When I click on the binary in the development folder with CommanderOne, I get this first:

1. a new Terminal window opens saying "Process Completed"
2. I also get a notification window from CommanderOne saying “csv” is a Unix app created by the app Commander One. Are you sure you want to open it?
3. When I click "open" to the message above, I get "csv” can’t be opened because Commander One is not allowed to open documents in Terminal."

It does not seem to make a difference how the binary is compiled, either a debug or release compile gives the same result.

By the way, I notice that my post Title is not completely correct, but I have no way of changing that initial post.

If I understand correctly, you can run the binary from Terminal. The Finder is different. It's going to expect a real app. That's a totally different environment.

Yes, I can run the binary by calling "cargo run" from the Terminal, and then the binary opens as well.

So you are saying that when using Finder, it expects a real app.

Ok, so how do I convert my Rust binary into an Apple app?

A further question. Are all binaries that run on MacOS considered "apps"? If so, that would imply that all binaries compiled with Xcode would be "apps".

Are all binaries that run on MacOS considered "apps"?

No.

macOS draws a strong distinction between command-line tools and apps. A command-line tool is:

• Packaged as a single executable file

• Run from Terminal

• Interacts with the user, if at all, using stdin / stdout / stderr

In contrast, an app is:

• Packaged in a .app bundle

• Run from the Finder

• Interacts with the user with UI frameworks like AppKit and SwiftUI

The command-line tool packaging is also commonly used for other types of programs, like launchd daemons and agents, but there the line starts to get kinda blurred.

If so, that would imply that all binaries compiled with Xcode would be "apps".

Nope. In Xcode you can start with either the macOS > App template or the macOS > Command Line Tool template, and that determines the packaging you get.

how do I convert my Rust binary into an Apple app?

That’s a very Rust-specific question. I don’t play in that world so I can’t offer specific advice. However, it’s common for non-Apple development environments to offer a variety of different approaches:

• A tool to wrap your tool in a standard terminal-esque UI

• A UI framework that’s ‘native’ to that environment

• A mechanism to import Apple’s UI frameworks, allowing you to create an app that’s native to the Apple environment

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, I can run the binary by calling "cargo run" from the Terminal, and then the binary opens as well.

Sounds like it's working then.

So you are saying that when using Finder, it expects a real app.

Yes. A "real app" is just a bundle directory that wraps the executable and includes dynamic libraries and frameworks, helpers, resources, and various metadata files like an Info.plist.

Ok, so how do I convert my Rust binary into an Apple app?

No clue about anything Rust-related.

I can tell you that every "real app" includes a command-line executable. You can usually run that executable on the command-line like any other Unix command.

Sometimes this can be handy to easily see certain log messages or to force the app to run in a particular localized language.

The downside is that since you aren't running it from the Finder, there may be some unexpected behaviour. But sometimes you can even have apps that run normally in the Finder, but also have a special command-line only mode.

Now the mechanism of displaying a graphical user interface via a command-line app is deep, undocumented black magic. It works for most "real apps" built using normal Xcode templates. It also works for legacy architectures like XQuartz and maybe Tcl/tk stuff. If Rust is able to hook into standard Apple APIs and Frameworks, then it should be able to do that too.

A further question. Are all binaries that run on MacOS considered "apps"?

No. There are all kinds of exotic things that can be executed.

If so, that would imply that all binaries compiled with Xcode would be "apps".

It is true that Xcode was designed for app building and for building various other app-supporting artifacts. But Xcode is also just an IDE like any other. I build websites in Xcode using XML and XSLT. That being said, Xcode includes too much baggage for simple, educational command-line tools.

But since you are poking around with exotic command line things like Rust on a Mac, I should warn you. Modern, open-source projects can sometimes be based on extremely complicated build systems that make Xcode look simplistic by comparison. (Anything that anyone from Google or Meta has ever touched, for example). If you are trying to build any of that stuff on a Mac, you might find it easier to discard those build systems and port it all to Xcode. It sounds like a lot of work, but at the end of the month, you'll have something to show for it where you wouldn't trying to figure out something like Ninja etc.

Quinn wrote:

A mechanism to import Apple’s UI frameworks, allowing you to create an app that’s native to the Apple environment

After some digging, I found

Building an iOS App with Rust Using UniFFI

So as Quinn mentioned, the Rust community developed a wrapper system that involves the use of UniFFI. I don't know anything about it at this point, but it looks like a direction to head in.

Etresoft wrote:

If you are trying to build any of that stuff on a Mac, you might find it easier to discard those build systems and port it all to Xcode.

This may be a very good point. Two things come to mind.

1. Rust is much easier for me to work with on Linux
2. Trying the same thing on a Mac gets much harder for my skill level.

With this in mind, I am going to post another thread with the title...

"Overall Code Structure Of Swift Project"

... and see where this takes us. I have watched numerous videos and they seemed promising, but trying to figure out the structure of a UI project was daunting, to the point where I gave up trying to learn Swift.

There are many different communities for various languages and platforms. If you choose an odd combination, then the burden will be on you to figure it out. Rust people may not know anything about Apple platforms and Apple developers may not know anything about Rust. That can be an opportunity for you to become that expert. But generally speaking, the barriers are social and psychological rather than technical.

Rust GUI binary that I compiled on Mac

What GUI toolkit is this using? It’s something portable, right, rather than native macOS? That may be more significant than the fact that it’s written in rust.

Etresoft wrote:

If you choose an odd combination, then the burden will be on you to figure it out.

Good point. And so far, that is exactly what has happened. It's been quite the journey.

endecotp wrote:

What GUI toolkit is this using?

I stumbled on FLTK after starting out trying "TK" and then later, "Iced", ending up using "FLTK".

It's interesting in that the dependencies while using "Iced", were about twice as much as FLTK, with the expected longer compile times.