ContentView.swift file.
FIGURE 1-12: The preview is updated to reflect the changes in the code.
If you change the color of the Text view (within the Button view) to blue, you should see the changes automatically reflected in the preview:
Text("Submit")
.padding(EdgeInsets(
top: 10, leading: 10,
bottom: 10, trailing: 10))
.background(Color.blue)
FIGURE 1-13: Occasionally you have to click the Try Again button to update the preview.
Working with Live Preview
Your code will change the text on the label when the button is clicked (or tapped on a real device). However, if you try clicking the button on the preview canvas, there is no reaction. This is because the preview canvas only allows previewing your UI — it doesn’t run your application. To run the application, you need to click the Live Preview button (see Figure 1-14).
FIGURE 1-14: Clicking the Live Preview button allows you to run your application directly on the canvas.
When the Live Preview mode is turned on, the background of the simulator will turn dark (see the left side of Figure 1-15). You can now click on the button and the text on the label will be updated (see the right side of Figure 1-15).
FIGURE 1-15: Testing your application in Live Preview mode.
Generating different previews
Notice this block of code at the bottom of ContentView.swift?
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
}
The ContentView_Previews struct conforms to the PreviewProvider protocol. This protocol produces view previews in Xcode so that you can preview your UI created in SwiftUI without needing to explicitly run the application on the iPhone Simulator or real devices. Essentially, it controls what you see on the preview canvas. As an example, if you want to preview how your UI will look like on an iPhone SE device, you can modify the ContentView_Previews struct as follows (see Figure 1-16):
FIGURE 1-16: Previewing the UI on two iOS devices — the latest iPhone and an iPhone SE.
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
Group {
ContentView()
ContentView()
.previewDevice(PreviewDevice(
rawValue: "iPhone SE"))
.previewDisplayName("iPhone SE")
}
}
}
The Gory Details
Now that you've seen how to get started with SwiftUI, let’s take a moment to examine the various files created in the project and see how the various parts connect.
In your project, notice that you have the following files created (see Figure 1-17):
AppDelegate.swift
SceneDelegate.swift
ContentView.swift (this is the file that you've been modifying to create the UI of your iOS application)
Info.plist
FIGURE 1-17: The content of the project created.
Info.plist
Let’s take a look at the Info.plist file first (see Figure 1-18). In particular, look at the key named Application Scene Manifest.
Within the Application Scene Manifest key, you have the following keys:
Enable Multiple Windows: This is set to NO by default. You can set this to YES if you're building apps for iPadOS and macOS.
Application Session Role: An array that contains a list of dictionary objects. The default object contains a key named Delegate Class Name that points to the SceneDelegate.swift file.
FIGURE 1-18: Examining the items in the Info.plist file.
AppDelegate.swift
AppDelegate.swift is the place where you write code to handle an application's launch, going into the background, coming to the foreground, and other activities.
AppDelegate.swift has three main functions:
application(:didFinishLaunchingWithOptions)