What’s in the basic template?

Paul Hudson @twostraws February 9th 2021

Updated for Xcode 13.0 beta 2

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 App template gives you the following:

YourProjectName.swift. This performs an initial set up, then creates and displays your initial view.
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.
Assets.xcassets. This is an asset catalog, which stores all the images and colors used in our project.
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.
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 YourProjectName.swift is responsible for managing the way your app is shown. Obviously it’s not actually called that – it will be named according to the project name you chose when creating your poject.

Go ahead and open this file now, and you’ll see code like this in there:

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

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 group 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!")
            .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

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 forget to return anything at all – the Swift compiler will refuse to build your code.

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

Fifth, that Text view has a padding() method call below it. In SwiftUI this actually creates a new view with padding around it, rather than changing the existing Text view. As a result, we call these modifiers because they create modified content, as opposed to methods.

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 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…