What’s in the basic template?

Tip: You might think this chapter is totally skippable, but unless you’re a Swift genius chances are you should read to the end just to be sure.

The basic Single View App template gives you the following:

1. AppDelegate.swift. This is responsible for monitoring external events, such as if another app tries to send you a file to open.
2. SceneDelegate.swift. This is responsible for managing the way your app is shown, such as letting multiple instances run at the same time or taking action when one moves to the background.
3. ContentView.swift. This is our initial piece of user interface. If this were a UIKit project, this would be the ViewController class that Xcode gave us.
4. Assets.xcassets. This is an asset catalog, which stores all the images and colors used in our project.
5. LaunchScreen.storyboard. This is the screen that gets shown while your app is loading.
6. Info.plist is a property list file, which in this instance is used to store system-wide settings for our app – what name should be shown below its icon on the iOS home screen, for example.
7. A group called Preview Content, which contains another asset catalog called Preview Assets.

And that’s it – it’s a pleasingly small amount of code and resources, which means we can build on it.

The part we really care about – in fact, here it’s the only part that matters – is ContentView.swift. This is the main piece of functionality for our app, and it’s where we can start trying out various SwiftUI code in just a moment.

First, though: what makes ContentView.swift get shown on the screen?

Well, if you remember I said that SceneDelegate.swift is responsible for managing the way your app is shown. Go ahead and open SceneDelegate.swift now, and you’ll see code like this in there:

if let windowScene = scene as? UIWindowScene {
    let window = UIWindow(windowScene: windowScene)
    window.rootViewController = UIHostingController(rootView: ContentView())
    self.window = window
    window.makeKeyAndVisible()
}

That code creates a new ContentView instance (that’s the main piece of functionality we’ll be looking at soon), and places it inside a window so it’s visible onscreen. It’s effectively bootstrapping our app by showing the first instance of ContentView, and from there it’s over to us – what do you want to do?

Open ContentView.swift and let’s look at some actual SwiftUI code. You should see code like this:

import SwiftUI

struct ContentView: View {
    var body: some View {
        Text("Hello World")
    }
}

#if DEBUG
struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}
#endif

That’s not a lot of code, but it does pack in a great deal.

First, notice how ContentView is a struct. Developers familiar with UIKit will know that this is huge – we get to benefit from all the immutability and simplicity of values types for our user interface! Folks who aren’t familiar with UIKit… well, just nod and smile – you never knew the pain we used to have.

Second, ContentView conforms to the View protocol. Everything you want to show in SwiftUI needs to conform to View, and really that means only one thing: you need to have a property called body that returns some sort of View.

Third, the return type of body is some View. The some keyword was introduced in Swift 5.1 and is part of a feature called opaque return types, and in this case what it means is literally “this will return some sort of View but SwiftUI doesn’t need to know (or care) what.”

Important: Returning some View means that the body property will return something that conforms to the View protocol. You can’t return many things or forget to return anything at all – the Swift compiler will refuse to build your code. To be clear, your view body must always return exactly one child view.

Fourth, inside the body property there’s Text("Hello World"), which creates a label of the text “Hello World”.

Finally, below ContentView is a similar-but-different struct called ContentView_Previews. This doesn’t conform to the View protocol because it’s specifically there to show view previews inside Xcode as opposed to be on-screen in a real app. This is why you’ll see it inside #if DEBUG and #endif lines – this code is only built into the finished product when our app runs in a debug environment because it doesn’t make sense in a production app.

We’ll look at each of these components in much more detail soon enough, but first let’s take a look at that Text component…