FREE TRIAL: Accelerate your app development career with Hacking with Swift+! >>

What’s in the basic template?

Paul Hudson    @twostraws   

Updated for Xcode 13.0

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:

  1. YourProjectName.swift. This performs an initial set up, then creates and displays your initial view.
  2. 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.
  3. Assets.xcassets. This is an asset catalog, which stores all the images and colors used in our project.
  4. 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.
  5. 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…

Hacking with Swift is sponsored by Essential Developer

SPONSORED Join a FREE crash course for iOS devs who want to become complete senior developers — from October 18th to 24th. Learn how to apply iOS app architecture patterns through a series of lectures and practical coding sessions.

Learn more

Sponsor Hacking with Swift and reach the world's largest Swift community!

Similar solutions…

BUY OUR BOOKS
Buy Pro Swift Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift (Vapor Edition) Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Server-Side Swift (Kitura Edition) Buy Beyond Code

Was this page useful? Let us know!

Average rating: 4.6/5

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.