Updated for Xcode 12.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 Single View App template gives you the following:
ViewController
class that Xcode gave us.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…
SPONSORED From January 26th to 31st you can join a FREE crash course for iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a senior developer!
Sponsor Hacking with Swift and reach the world's largest Swift community!
Link copied to your pasteboard.