Unit 1: Getting Started|Introduction

While Xcode playgrounds are great tools for learning and experimenting with the Swift programming language, Xcode projects are geared toward creating applications. As you write code, you’ll want to see what effect it has on your app. For this, Xcode includes Simulator, an application that allows you to test your apps on a variety of devices and screen sizes—including older devices that may lack recent hardware advances, such as Touch or Face ID, or include the Home button that was removed on iPhone X.

In this lesson, you'll walk through the necessary steps to configure your Mac for building and debugging apps, and to use Simulator to test your apps from Xcode. You'll also learn how to run your app on a physical device and how to use breakpoints to locate bugs in your code.

What You'll Learn

How to use Simulator to run apps within the Xcode environment
How to run an app on a physical device
How to perform basic debugging using breakpoints

Vocabulary

Related Resources

Guide

Building and Running

Your first step is to create a new project in Xcode. You'll use the same iOS Single View App template as in the previous lesson. Name the project "GettingStarted" and choose a location for saving it.

Next, you'll be presented with the Xcode workspace. Locate the Scheme menu on the Xcode toolbar, then choose the device you want to simulate from the list.

Active scheme dropdown

Click the Run button , or use the keyboard shortcut (Command-R) to begin launching the app in Simulator.

If you’re running an app for the first time, Xcode asks whether you’d like to enable developer mode on your Mac. Developer mode gives Xcode access to certain debugging features without requiring you to enter your password each time. All the lessons in this course assume that you've enabled developer mode.

Enabling developer mode

After Simulator has launched, you should see a device image with a white background. To rotate the image from portrait to landscape orientation, use the keyboard shortcuts Command-Left Arrow and Command-Right Arrow.

The simulator image may appear quite large, depending on the screen resolution of your Mac and the device you chose to simulate. From inside the Simulator application, you can use keyboard shortcuts, from Command-1 to Command-3, to scale the device image up or down. If you're using an older Mac, you may want to select an older lower-resolution device, such as an iPhone SE, to reduce the total impact of the simulator on your system.

To quit Simulator, use the keyboard shortcut Command-Q. Or just go back to Xcode.

The simulator doesn't work for all portions of an app. Certain interactions depend on the actual physical device to run. For example, if you try to use the simulator to test an interaction with the Camera app, the program will crash. If your code depends on other hardware components that don't exist on a Mac—maybe an accelerometer, a gyroscope, or a proximity sensor—you'll want to test with an actual device.

The simulator also has some software limitations. For example, push notifications can be delivered only to physical devices, and the MessageUI framework—which helps compose email and text messages—is incompatible with the simulator. If you're running into a lot of issues in the simulator, try testing the code on your iPhone or iPad. Your issues may be resolved.

Simulator runs on a Mac, which is built on the Intel "x86-64" architecture, but iOS devices are built on the ARM (Advanced RISC Machine) architecture. This means there are underlying (and sometimes subtle) differences in how your app works.

Overall, the simulator works well when you're developing and debugging apps, but you should always test your code on actual hardware.

Using a Personal Device

The beauty of mobile apps is that you can take them anywhere. You may find that you want to share your programming progress with friends and coworkers. But before you can begin running your code on a physical device, you must have an account on the Apple Developer website. Accounts are free, so don't worry.

Using a web browser, go to developer.apple.com and click Account. You can sign up using your existing Apple ID. If you don't have an Apple ID, go ahead and create one—it's also free. Once you've entered your Apple ID, your developer account is good and you can head on back to Xcode.

(With a free account, you can run your iOS apps on only one physical device. To distribute your apps to multiple devices or publish them to the App Store, you need to enroll in the Apple Developer Program.)

Now, you need to tell Xcode about your new developer account. Open Xcode Preferences using the keyboard shortcut Command-Comma (or choose Xcode > Preferences from the Mac menu bar), and then select the Accounts button near the upper-left corner. Click the "+" button in the lower-left corner and choose Add Apple ID from the menu. After entering your credentials, you're ready to run and debug apps on a physical iOS device.

Connect your iOS device to your Mac using the appropriate USB cable. Xcode will automatically download the necessary information from the device and will display its name in the Scheme menu. Choose the name of your physical device—which will typically be at the top of the list, before the device simulators.

Build and run the app again. You may receive the following prompt, asking you to trust the developer certificate. Follow the instructions within the alert to allow the device to run your apps.

Prompt to trust developer certificate

Build and run once more, and you should see the same simple white screen on your iOS device. To stop the app from running, click the Stop button near the left end of the Xcode toolbar (or use the Command-Period keyboard shortcut).

Building and Running Wirelessly

Xcode also gives you the option of deploying an app to your device over your network. To do this, connect your iOS device to your Mac using the appropriate USB cable, and open the Devices and Simulators window by selecting Devices and Simulators from the Window dropdown.

Ensure that your device is selected in the list farthest to the left in the Devices and Simulators window. Check the Connect via network box.1

Devices and Simulators window with emphasis on Connect via network checkbox

If your device is on the same network as your Mac, you'll see a globe appear next to your device's name within a few moments. This indicates that your device is wirelessly connected.1

Devices and Simulators window with emphasis on globe by device name

You can now disconnect the USB cable connecting your device to your Mac, and build and run your app wirelessly.

In most cases, the above steps are sufficient for wireless pairing. However, if this doesn’t work for you, you might be on a corporate or institutional network where the system administrator has put in place certain network restrictions. In this case, open the Devices and Simulators window, hold Control and click your device, then click Connect via IP Address in the menu presented. You then need to find your device's IP Address from your device's Settings, enter it in the prompt, and click Connect. This should successfully pair your device. If you run into problems with wireless debugging, you can always pair over a USB cable.

Debugging an Application

Even the best developers struggle to write perfect code. Debugging is the process of identifying and removing problems that may arise in your app. Xcode provides tools to help you through this process.

When you run an app as described above, either on the simulator or on your device, Xcode will connect the app to its debugger. This allows you to watch the execution of your code in real time, stop code execution using breakpoints, print information from your code to the console, and much more.

As you proceed through this course, you'll encounter three types of issues: warnings, compiler errors, and bugs.

Warnings

Warnings are the simplest kinds of issues to fix. They're generated whenever your code is built, but they don't prevent your program from successfully compiling and running. Some of the conditions that can throw a warning include:

Writing code that never gets executed
Creating a variable that never changes
Using code that's out of date (also known as deprecated code)

Take a look at a warning. Back in Xcode, select ViewController.swift in the project navigator and, in the editor area, add the following line of code just below super.viewDidLoad():

let x = 4

This code assigned a value of 4 to a constant named x. Build your application using Command-B. You should see a yellow caution sign on the line you just added.

Warning icon

Xcode will do its best to explain the warning in a straightforward way:

Console Output:

Initialization of immutable value 'x' was never used; consider replacing with assignment to '_' or removing it.

The compiler is telling you that it created x but, because it's not used in a meaningful way, you can remove it. Delete the line and rebuild to remove the warning.

Compiler Errors

An error is indicative of a more serious issue—for example, invalid code (such as a typo), improperly declaring a variable, or improperly calling a function. Unlike a warning, an error prevents the code from ever being executed. Simulator won't even launch if your code has an error.

Here's a look at two different errors in the making. In ViewController.swift, remove the open and closing parenthesis on the end of super.viewDidLoad(), leaving super.viewDidLoad. Beneath this line of code, write navigationController.title = "Debugging".

After you build the app, you'll see two red error symbols.

Exception icon

One of the errors has a dot in the center dot icon . Click this error icon and Xcode displays a suggestion to fix the code. Click the Fix button to have Xcode implement this suggestion.1 In this instance, Xcode provides a valid fix. However, you can’t rely on the compiler to properly fix all errors—you need to be able to address errors on your own.

Xcode error description

The other error has an icon with an exclamation point in the center exclamation icon . Xcode doesn't offer a fix-it for this type of error, but it does provide a message that can help you identify the issue. The compiler expected to see an open and closing parenthesis as the proper syntax for calling a function. Add both characters at the end of super.viewDidLoad to remove the last error.

Bugs

The third type of issue is known as a bug—and it's the hardest issue to track down. A bug is an error that occurs while running the program, resulting in a crash or incorrect output. Finding bugs can involve some time and some real detective work.

In ViewController.swift, add the following lines of code below super.viewDidLoad():

var names = ["Tammy", "Cole"]
names.removeFirst()
names.removeFirst()
names.removeFirst()

You may not be familiar with Swift at this point, and that's OK. These lines are simple to understand. names is a list containing two pieces of text, "Tammy" and "Cole." Each subsequent line removes the first item from the list. Since there are three calls to remove the first item, but only two items in the list, what do you expect will happen?

Build your application. Since the syntax is valid, you'll receive the "Build Succeeded" message. Now try running the app. After a few moments, the program will crash, and the following message will appear in red on the last line of code above:

Thread 1: Fatal error: Can't remove first element from an empty collection

The program crashed when it tried to remove the remaining first element and couldn't find one. You've already guessed that. But imagine you're unsure how to fix the problem. Xcode can help you to step through the program one line at a time.

Before you start looking for the bug, you'll need to add a breakpoint to your code. A breakpoint pauses the execution of a program at a specified point. Create a breakpoint by clicking in the gutter area to the left of the line where you want execution to pause. In this case, add the breakpoint to the var names = ["Tammy", "Cole"] line.1

Add breakpoint

Build and run your app. You'll see the program pause at the breakpoint.1 That's good. In the debug area, show the variables view to inspect the current values2 (the button is on the lower right3). Because the breakpointed line hasn't yet been executed, names contains no values.

Hit breakpoint

From here, you can use the step control buttons at the top of the debug area to slowly continue code execution:

Continue — Resumes code execution until the next breakpoint is reached. If you select this button now, the code will crash, since there are no other breakpoints before the third names.removeFirst().
Step over — Executes the selected line and pauses execution on the next line.
Step into — If clicked on a line with a function call, advances to the first line of the function, then pauses execution again.
Step out — Executes all remaining lines in the function call and pauses execution on the line after the function.

Click the "Step over" button to advance execution by one line. In the variables view, you can see that names has been assigned the proper values. So far, so good.

Debug area

Click the "Step over" button again to execute the first call to names.removeFirst(). names no longer includes "Tammy" in its list, so that worked fine. Click "Step over" again to execute the second call to names.removeFirst(), leaving names an empty list with zero values. Still OK. By now, it should be clear that the third call to names.removeFirst() is responsible for the bug.

Remove the third call to names.removeFirst() and run the program again to verify that the error has been fixed.

Debugging is a crucial skill for developers to build. When debugging, take the following approach:

Try to understand the problem
Brainstorm a potential solution
Try the solution
Verify it worked, repeat as necessary

Take each bug one step at a time. It can be frustrating to run into bugs when building apps, but it feels great when you're able to fix them.

Lab: Debug Your First App

Overview

The objective of this lab is to find and resolve compiler errors, runtime errors, and compiler warnings.

Step 1: Find and Fix Compiler Errors

Open the Xcode project, "FirstTimeDebugging."
Try to run the app. Note that it won't run due to a few compiler errors. As you've learned in this lesson, compiler errors are indicated by red symbols in line with the mistake—or where the compiler guesses the mistake might be. All compiler errors are also listed in the issue navigator.
Fix the compiler errors so that you can run the app. Here are two of the more common mistakes that may have caused this app's compiler errors:
- Missing or extra parentheses or braces (whether opening or closing)
- Referencing a function or property but with incorrect spelling (The compiler is very literal and expects you to reference a function or property exactly by the name you gave it.) Hint: Sometimes a single mistake can cause the compiler to flag multiple errors. Fix one mistake and you might eliminate all the error symbols.

Step 2: Find and Fix Runtime Errors

Were you able to remove all the red error symbols from the project? If so, try to run the app again.
This time, notice that the app stops execution right after opening in the simulator and that there’s a red line across one of the lines of code on the screen. The fact that the line is red indicates something went wrong. Look at the text in the console area to learn what the issue might be. Try to solve this runtime error. If it’s helpful, you might want to add breakpoints at and before the affected code, then run the app again.

Step 3: Find and Fix Compiler Warnings

Now that the app runs, focus your attention on a few more problems. Open the project's issue navigator. You'll note several warnings, indicated by yellow triangles. Address all of these warnings.

Congratulations! You should now have a project free of compiler errors, runtime bugs, and warnings.