I was a long time C# programmer, and recently started learning Rust. Now that I recently purchased my first Mac, I ran into several issues trying to run binaries on the Mac, due to various restrictions. On another forum post here, it was mentioned that I should take a look at Swift, as a development tool. This comment brings up an entirely new topic for me, as I discovered that the Swift project file structure seems daunting. But first let's backtrack to when I used C#. C# The first graphic show the default file structure that I used to start a new C# project. I would copy this entire folder structure to the clipboard and paste it where my new project folder was located, and start coding. Using this same principle, I wrote my own music player, and again the file structure for the entire project was as below. For those that may not know, the "bin" folder contains both debug and release folders and appropriate contents. Swift I created a Windows UI called "Test" using Swift, and then started poking around the file system, trying to determine the file structure that was created. Unbeknownst to me at the time, part of the project files ended up on the Desktop in a folder called Test. I did not expect Swift to place the files there. When I click on the Test folder and look inside, I see a file with a "xcodeproj" extension, which makes sense to me, as this is similar to C#. What I don't see however, is any file labeled Test.App. I also don't see either debug or release folders for this project. Obviously there are additional files for this project that are "somewhere", just not in a location I am aware of.

Hi In C#, one can define associated functions by the following. Notice that "Declarations DE" is a reference to a function in another C# project file. This lets the compiler know that there are other references in the project. Likewise, "Form_Load" is the entry point of the code, similar to "main" in C. Any calls to related functions can be made in this section, to the functions that have been previously defined above. So I set out trying to find similar information about SwiftUI, and found several, but only offer partial answers to my questions. The YouTube video... Extracting functions and subviews in SwiftUI | Bootcamp #20 - YouTube ... goes into some of the details, but still leaves me hanging. Likewise... SOLVED: Swift Functions In Swift UI – SwiftUI – Hacking with Swift forums ... has further information, but nothing concrete that I am looking for. Now in the SwiftUI project, I tried this... The most confusing thing for me, is where is "main"? I found several examples that call functions from the structure shown above, BUT I have no reason as to why. So one web example on StackOverFlow called the function from position 1. That did not work. Position 2 worked to call the function at position 3, but really, why? All this activity brings up a lot of questions for me, such as: Does SwiftUI need function callouts similar to C#, and they are called out even before running "main". I seem to recall Borland Delphi being this way as well. How does SwiftUI make references to other classes (places where other functions are stored in separate files)? Does SwiftUI actually make use of "main" in the normal sense, i.e. similar to C, C#, Rust and so on? I did notice that once a SwiftUI function is called, it makes reference to data being passed very similar to other languages, at least for the examples I found. Note that I looked at official SwiftUI documentation, but did not come across information that answers the above.

Hi, I am a long time programmer in C#, and newer to Rust, and a rookie to MacOS 15.1. Over the past few days I have made numerous attempts to run a Rust GUI binary that I compiled on Mac. Here are some examples of things I have tried using. Executable compiled in M1 mac not running on Apple Silicon Mac - help - The Rust Programming Language Forum And here.... How to run unsigned apps in macOS 15.1 Also here... "sudo spctl --master-disable" There are many more that I have tried. I also tried moving the binary from my developer folder to the Application folder and running.... xattr -r -d com.apple.quarantine /Applications/csv Note that "csv" is the name of my binary. You have probably seen this 100 times, so can you point me to me to something that allows my Rust binaries to run under MacOS? PS The Rust program code works just fine under Linux. I can either type Cargo Run and run the binary from the Terminal or go directly to the executable and double click on it to open the GUI application. The only thing that MacOS lets me do it open the GUI from the Terminal. Commander One says that I do not have the proper credentials to open the file directly. Finder also does not allow me to open the binary directly. Thanks, Jim

Hi, I am looking for guidance on how to create a scrollable song list, such as the attachment. The song list was originally created in C#, using an RTF object and populated by about 43 lines of song criteria. What similar approach would I use in Swift and MacOS? By the way, I currently play music that resides on the Mac, no external streaming is required or desired. Thanks, Jim

I am coming from C#, where Forms and Controls are placed similar to Swift Storyboards. I have been trying to learn Storyboards, but keep running across tutorials regarding SwiftUI, and Storyboard examples are few. So the question becomes, "how do I position controls on a Form using SwiftUI?" See the example below. I have run across many videos that use either horizontal or vertical positioning of controls, but these examples are usually very simple, with items occupying only the center portion of the screen. I get stuck on examples that are more complicated. The example below only shows the controls for the upper part of a Form, with some type of textbox (Viewform) below making up the rest of the Form. How does one make more complicated placement of controls with SwiftUI?

Hi, I am looking for comprehensive "controls" documentation for SwiftUI. When searching on the Apple site, I have not seen any documentation that shows a picture of a control and an explantation of what it does, for all the available controls. I have also searched the web for such documentation, and have not found any. When I was learning Rust, I came across a beautiful document about GTK3 (PDF) that had a complete list of controls, including pictures. If something looked interesting I could do a search for more details. Thanks, Jim

I just updated to Tahoe 26 and Xcode 26, and now a SwiftUI project that was working just fine, simply shows a blank canvas. I closed Xcode and reopened, but get the same results. Note that there is no error message and the project builds and displays normally. Steps to blank canvas: Open Xcode I see Canvas Paused Click on the circle The Form opens with a blank screen Build the project The Form opens with all controls showing Jim

I am trying to resize a Window Form after it loads and have done quite a bit of searching for code to do it. Here is one code snippet that works to size the form during the design phase. self.view.window?.contentMinSize = CGSize(width: 1100, height: 310) I have tried code like below to increase the window size after the Form loads if let myWindow = self.view.window ?? NSApplication.shared.mainWindow { // Increase window size and position after it loads let newRect = NSRect(x: 100, y: 100, width: 1400, height: 900) } It seems that this code not only changes the Form size after loading, but also changes the size of the Form in Main.swift, which is something I don't want. I read elsewhere that I had to disable constraints to resize the Form, so I tried code below. let tableView = NSTableView() tableView.translatesAutoresizingMaskIntoConstraints = false let newRect = NSRect(x: 100, y: 0, width: 1100, height: 600) myWindow?.setFrame(newRect, display: true) That code did not seem to do anything as well. Also, the Form displays in the lower left of the screen. Note that main reason I want to resize the Form after loading is to keep it smaller during design development. The same goes for the NSTableView, which I have not gotten to yet.