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: a new Terminal window opens saying "Process Completed" 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? 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.

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

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. Rust is much easier for me to work with on Linux 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.

etresoft wrote: When you're ready to distribute, you'll perform an archive build and you'll have to specify what you want to do with the build product. You can choose to submit it to the App Store, distribute it using a different method, or just save it to disk. When you save the file to disk, does Xcode add a certain extension to the binary? In Windows it's EXE and running Linux, Rust has no binary extension at all. DTS Engineer wrote: The project only contains files that are source of definitive information, such as your source code or your build settings. Anything that's derived from that source of truth can be discarded and recreated at any time. Hence DerivedData. Below is a Rust folder screenshot that shows a file structure very similar to C#. This example is from Github. When Rust compiles, it creates up to 1 gig of "extra stuff" during the build, and Rust leaves it alone until you send "cargo" a clean command. Note that FLTK is the GUI part of Rust code. Does Xcode clean up manually or automatically? endecotp wrote: I’m going to mention the Swift Package Manager: Yes, this something that sounds very interesting. I would definitely like to look into this. DTS Engineer wrote: It’s able to build macOS standalone executables and that’s about it. This sounds really good for my code usage. Does anyone have any other resources on this topic?

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.

Quinn wrote: But getting started is really easy: So I tried what you had written, and it worked great for me. However, for some reason I was expecting that the binary would be a GUI background with Hello World printed on top. This is my main interest in learning Swift. Thanks for the push to learn Swift, as I just purchased... Hacking With MacOS And will start learning with that text. Thanks again.

endecotp wrote: What do you actually want to happen? How/where do I declare global variables in the same file as "main" location? On a large project, there will be multiple associated files that contain related functions. How do make calls to these functions from the "main" file? In C# for example, I can't simply call the function name, it has to be associated the "class" that the function is stored in first. Do I have to declare these related functions in the "main" form ahead of usage? I used "print(hi)" just to ensure that my function call was being called. eoonline wrote: Note, if this is your first foray into a declarative language, I might suggest going through some of the tutorials on the SwiftUI page. Or perhaps watch some of the SwiftUI videos, such as WWDC 2024’s SwiftUI essentials (or any of the videos linked on that page). Is it that obvious? Yes, you are correct, in the Swift is quite a shock and seems to be a large learning curve. And yes, I am trying to find whatever I can to learn this language. Thanks for the links, I will certainly check these out.

Update on 12-23-2024: I purchased the book... "Hacking With Swift" by author Paul Hudson. Paul has a Github presence... github.com/twostraws/macos I downloaded the zip file and found sample code that shows how the @main makes a call to the first of many "func" calls. In the zip file, look at... project13 ...for a good example of how Swift makes calls to various "func" calls. Seeing this helped me a great deal. I noticed that Swift handles "func" calls to other classes quite a bit different than C#, but this is the reason for the book purchase. I am highlighting this here in the hope that it helps others who are starting their journey with Swift as well.

For anyone else that might have been struggling with running a Rust binary on Mac M1, here is some additional information that helped me. Do a web search for... Executable compiled in M1 mac not running on Apple Silicon Mac In the discussion, one of the posters highlighted this code... cargo build --target aarch64-apple-darwin --release So I tried building a Rust GUI that has a single button on the form, and built the code using the above target info. It worked! Note that if one tries to run the binary using Commander One, the request will fail. And THIS is what caused me to start this thread in the first place. For whatever reason, Commander One does not want to run this executable. So in this case, I used Double Commander and double clicked the binary and it worked just fine. I also made a shortcut and ran it from there, and again the Rust binary ran on Mac. I hope this helps others in the same situation. Jim

Late Update: Earlier above, I asked the question... Ok, so how do I convert my Rust binary into an Apple app? It turns out that this is indeed, an Apple function, which has been clarified on StackOverFlow. Search for the following... Running Rust app without showing the terminal - for MacOS To sum up, yes, a Rust app (binary) can be converted into an app that can be run natively on Apple OS systems. It should be noted that the release settings (with/without aarch64...) for the Rust binary did not seem to make any difference in running on MacOS. Jim