SwiftUI Entry Point - Proper Location In Project

I can’t really answer your questions, because the don’t make much sense. It sounds to me as if you have tried to learn Swift and SwiftUI by reading random bits of code and trying to work out what they mean by looking for connections with other languages. Sorry, that’s not going to work.

Now in the SwiftUI project, I tried this...

What do you actually want to happen? Presumably you want it to print “hi” at some point. When do you want it to do that?

If you want it to print “hi” when a ContentView struct is created, put it in an init method.

The most confusing thing for me, is where is "main"?

Let’s say that your app was called Foo. You will see a FooApp file in your project, and that bears the @main qualifier. It will look like:

import SwiftUI

@main
struct FooApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

That’s how it knows to present your ContentView.

Now, you included a screen snapshot where you tried dropping a call to result in various places. That will not work because this is a “declarative” framework, and it is expecting that the body will consist of a hierarchy of View types. But we can add “view modifiers” to any of the View’s within that body.

For example, there is an “event view modifier” called .onAppear, where you can specify what should happen when the associated View appears:

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundStyle(.tint)
            Text("Hello, world!")
        }
        .padding()
        .onAppear {
            foo()
        }
    }

    func foo() {
        print("foo")
    }
}

Or, if you wanted to do something asynchronous, we would do that in a .task view modifier:

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundStyle(.tint)
            Text("Hello, world!")
        }
        .padding()
        .task {
            await bar()
        }
    }

    func bar() async {
        do {
            try await Task.sleep(for: .seconds(1))
            print("bar")
        } catch {
            print(error)
        }
    }
}

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

endecotp wrote:

What do you actually want to happen?

1. How/where do I declare global variables in the same file as "main" location?

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

3. Do I have to declare these related functions in the "main" form ahead of usage?

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

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.

Just to clarify: Judging from your question, the problem might be less about the Swift language, itself (which I wager that you will quickly grok) than the SwiftUI framework (which is a framework where the UI, itself, is defined declaratively, coincidentally also in Swift). It is this latter framework for defining user interfaces that might feel a bit alien at first. But I don’t imagine you’ll have any troubles mastering Swift, itself, in general.

For what it is worth, in Apple ecosystems, when writing GUI apps, there are two paradigms for designing user interfaces. The older of the two is a “storyboard”, where you design and edit the UI in the Xcode GUI. This Xcode editor where you design UI’s is known, for historical reasons, as “Interface Builder”. Anyway, when you use storyboards, you then write familiar Swift imperative code to say what you want to do when certain things happen (e.g., the view is loaded, when the user taps a button, etc.). And you hook up the storyboard UI with your imperative code with “outlets” (@IBOutlet) and “actions” (@IBAction). It is the older, tried-and-true pattern.

The more modern way of designing user interfaces is SwiftUI, where, on top of all the more general Swift code you may write for various services, the UI is also defined in Swift. That’s what this ContentView is: It is a declarative definition of a UI, written in Swift.

When you create a new project, you can pick between “Storyboard” or “SwiftUI” for the UI (unless you create a multiplatform app, in which case SwiftUI is the only choice). If learning both Swift and SwiftUI in one fell swoop is too much to take in, you could always create an old-school storyboard-based app, at which point you could focus on familiarizing yourself with the Swift language. And then you could tackle SwiftUI, at your leisure, in a future project. But if you do this, you’ll have to learn a lot of legacy storyboard skills which will be of limited use when you later adopt SwiftUI.

So, feel free to dive into SwiftUI, directly, if you want. Just recognize that you will be learning two completely different techs, one is the Swift language, itself, and the other is SwiftUI’s declarative patterns for designing user interfaces, which happens to be written in Swift, as well. The various tutorials and videos I shared with you earlier will help you get up to speed on the latter.

How/where do I declare global variables in the same file as "main" location?

Variables declared outside of any class, struct or function, i.e. at the zero-indentation level, are ”global”.

But what, exactly, do you mean by “main”? The Swift equivalent of the “main function” in the C sense is partly explain by eoonline above, but I don’t think that’s really what you mean. I think you mean something more like “constructor”, or similar.

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?

Do you understand concepts like classes, objects and methods?

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.

OK, so you have heard of classes…

Do I have to declare these related functions in the "main" form ahead of usage?

Generally, the Swift compiler finds declarations in other files without any extra work on your part (unlike C).

But looking at your example, I think what you may be doing is creating instances of classes in order to call their methods. In that case, the answer is “yes, of course you need to create objects before you can call their (non-static) methods”.

Eoonline wrote:

Judging from your question, the problem might be less about the Swift language, itself (which I wager that you will quickly grok) than the SwiftUI framework

I agree that you should absolutely learn non-UI Swift first, and then learn SwiftUI, taking care to understand that its body declarative parts are subtly different from other Swift code.

I used "print(hi)" just to ensure that my function call was being called.

Crucially, the calls 1 and 2 are not within a function, they’re within a SwiftUI body declaration.

I’m not sure I agree with eoonline that you will “quickly grok” Swift, though. I have the impression that your first language was probably something without classes - maybe Fortran or Pascal - and you continue to think of everything in terms of those semantics.