Creating an Xcode Project

Start Xcode. If the first thing you see is the Welcome to Xcode screen, select Create a new Xcode project. Or, create a new project by selecting File ➤ New ➤ Project… from Xcode’s main menu. This starts a wizard, the first step in which is to choose an operating system and a product type for your project. We will start with something fairly simple: select iOS ➤ Application ➤ Single View Application, as shown in Figure 2-1.

Figure 2-1. Start a new iOS Single View Application project in Xcode

At the next step of the wizard name the project HelloXcode. Make sure that Swift is selected as the Language and Devices are set to Universal, and for this project don’t tick any of the checkboxes for creating tests (see Figure 2-2).

Figure 2-2. Name your project and select Swift as the programming language

Click Next, choose where to save the new project and let Xcode create it for you. Now let us see what’s inside.

The Xcode Interface

Our tour of Xcode starts with the big picture. If you set up your iOS Single View Application project following the steps above, your screen should look like Figure 2-3 when the project first appears.

Figure 2-3. The main IDE areas for an Xcode iOS appication project

There are four main areas in the IDE (Figure 2-3):

• The toolbar area

• The editor area

• The navigator area

• The utilities area

The Toolbar Area

On the left-hand side of the toolbar area you have controls for running your app and for choosing which device or simulator it should run on (see Figure 2-4).

Figure 2-4. Controls for running and quitting your app

In the middle you can see a brief summary of your app’s status (Figure 2-5). This answers questions like the following:

• Did the project compile?

• Were there any errors or warnings?

• Is the app running?

Figure 2-5. The toolbar area is the place to get information about the state of your app at a glance

At the right end of the toolbar area there are buttons for showing or hiding the other IDE areas and for toggling various views in them (Figure 2-6).

Figure 2-6. You can show or hide the main areas of the IDE and choose how they are displayed

The Editor Area

This is where you will do most of your work: writing code, designing a user interface (UI), and controlling your project settings. Xcode has three editor modes:

• The Standard editorshows you one thing at a time: you can load a source file, a storyboard, assets, or project settings.

• The Assistant editor displays two files side by side. You can have two source files open, for example, if you want to have a glance at a function call in one and its definition in the other. Or, you can have a look together at a storyboard (UI file) and the source file, in which you implement the storyboard’s actions—we will see how this works later, when we add a bit of UI to our app project.

• The Version editor is useful when your projects are under version control (as they should be): in this view you can see two revisions of the same file and compare what has changed.

If you select the main project in Project navigator, the project settings will appear in the editor area. Under Targets you can see the products that building the project should produce: at the moment we have one: the HeloXcode app. Across the top of the Editor area the project and target settings are distributed between several different tabs (Figure 2-7).

Figure 2-7. Project and target settings

The Navigator Area

Here you can switch between various navigators (Figure 2-8):

• Project navigator: shows the files in your project. You can organize files in groups that logically belong together. Note that the groups don’t have to correspond to folders on disc.

• Find navigator: lets you search for strings in your project.

• Symbol navigator: shows the class hierarchies in your code.

• Issue navigator: has a list of errors and warnings if any appeared during a build. Clicking an issue takes you to the file it was found in.

• Test navigator: if you choose to include unit or UI tests in your project, you can browse them here.

• Debug navigator: this navigator is active during a debug session and lets you drill into stack traces for each thread that is running in your app, as well as see statistics about how your app is utilizing system resources.

• Breakpoint navigator: this is where you can see and manage all of the breakpoints you have put in your code.

• Report navigator: shows you a list of reports about builds, debug sessions, and tests.

Figure 2-8. Your app source files in Project navigator

You can also switch between navigators from the main menu by choosing View ➤ Navigators.

If you open Project navigator, you will see the files Xcode has created for you: in the HelloXcode group there are two source files (AppDelegate.swift and ViewController.swift), two UI files (Main.storyboard and LaunchScreen.storyboard), an Assets folder, and a file called Info.plist, which contains the settings for your app. There is a second group, called Products, where the app executable file will appear when we build it.

Getting Your Fingertips Dirty

Even when you are not expected to write code for your first native app, it doesn’t mean you can’t customize the app. Adding something as simple as a label to the main view can be an excuse to explore one way of designing UI in Xcode 7. We will add a label and a date picker to our app and have Xcode generate code that will let us access them programmatically.

In Project navigator select the Main.storyboard file . In this context a storyboard is the visual representation of your app’s interface and workflow. It shows you and lets you define not only what the screens of your app will look like but also how they will flow from one to the other: the flow is shown with arrows.

With Main.storyboard selected you will notice that the Editor area changes to show you the application’s main screen. The gray arrow coming from the left and pointing to it in effect says, “Here is where the action starts.”

Let us leave a little fingerprint on this app. In the Utility area locate the Object library (see Figure 2-9): it has a list of UI elements you can drag and drop onto the storyboard.

Figure 2-9. Drag and drop a Date Picker onto Main.storyboard

Find a Date Picker controller in the Object library and add it to the storyboard by doing a drag-and-drop as shown in Figure 2-9. You should see the date picker appear both in the UI view and in the Document outline on the left. Select it and let’s change it to show the date, but not the time: in the Attributes inspector on the right set Mode to Date and leave the rest of the properties as they are (Figure 2-10).

Figure 2-10. Select the Date Picker to change its properties

Add a Label from the Object library to the storyboard and place it above the date picker. Double-click the label to change its text to “Day of the week” (Figure 2-11).

Figure 2-11. Add a label to the storyboard

You have probably noticed that the storyboard we are working with is square and doesn’t match the size or the aspect ratio of any iOS device known to man. Before Xcode 7 you needed to provide separate storyboards for the different devices your app was expected to run on. Now we have one storyboard to work with, which has an abstract size. Xcode can help us make our UI adaptive: let us do that.

With the View selected in the Document outline, open File inspector in the Utility area and locate the Interface Builder Document section. Make sure that you tick Use Auto Layout and Use Size Classes (Figure 2-12).

Figure 2-12. Set up the view to Use Auto Layout and Use Size Classes

Now select the date picker and click the Pin button at the bottom right of the screen where the storyboard is. We will constrain the date picker to move and resize itself, so that there is always the same distance between it and its nearest neighbor: the label and the edges of the view in this case. Set Spacing to nearest neighbor to 10 pixels on each side and click Add 4 Constraints. You will see the constraints appear in the Document outline on the left (Figure 2-13).

Figure 2-13. Add constraints to the date picker

Add the same constraints to the label (Figure 2-14).

Figure 2-14. Add constraints to the label

Next, click the Resolve Auto Layout Issues button and let Xcode move the label and the date picker around, so that they fall within the constraints we defined: in the pop-up menu select Update Frames(Figure 2-15).

Figure 2-15. Click Update Frames and let Xcode move the UI around to match the constraints

The constraints on the storyboard should now appear blue, indicating that there are no layout issues (Figure 2-16). When there is ambiguity or conflicts in the layout, you will see them turn orange and red.

Figure 2-16. Make sure that constraints on the storyboard appear blue

The last thing we will do before running the app is to create outlets for the two UI elements we put on the storyboard. An outlet is defined as “a property of an object that references another object.” In this case we will create properties in the ViewController class that will reference the date picker and the label. Correction: we will help Xcode create these properties. I made a promise that you will have an app without writing a line of code and I’m sticking with it.

With the storyboard still in the editor area, activate the Assistant editor. This will split the editor area in two: in one half you have the storyboard and in the other the ViewController.swift file. If a different file or no file appears in the second half, you can manually select ViewController.swiftto be loaded there by clicking the strip above the file, which shows a file path (Figure 2-17).

Figure 2-17. Create properties in ViewController.swift that will reference the label and the date picker

On the storyboard select the label, then Ctrl + drag it into ViewController.swift and drop it at the top of the ViewController class definition.

In the pop-up dialog that appears name the outlet dayOfTheWeek and click Connect (Figure 2-18). This creates a property in the ViewController class of type UILabel, which will let us access the label programmatically—we will do this in Chapter 3 .

Figure 2-18. Name the outlet and let Xcode create a definition for it in the ViewController class

Repeat the steps to create an outlet for the date picker and name it datePicker. The ViewController class should now look like Listing 2-1.

Listing 2-1. The ViewController Class After the Outlets Have Been Added

class ViewController: UIViewController{

    @IBOutlet weak var dayOfTheWeek: UILabel!
    @IBOutlet weak var datePicker: UIDatePicker!

    override func viewDidLoad(){
        super.viewDidLoad()
        // Do any additional setup after loading the view,
        // typically from a nib.
    }

    override func didReceiveMemoryWarning(){
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }
}

Running Your App in the Simulator

Time to see this app in action. Let us run it in Xcode’s simulator first. Click the device drop-down next to your project’s name on the Toolbar (Figure 2-4). If any of your iOS devices are plugged in your machine, their names will appear in the top part of the list under the Device category. The iOS Simulators category contains a number of options: select one, for example iPhone 6 (Figure 2-19).

Figure 2-19. Select an iOS simulator from the list on the toolbar

Click the Run button. This starts the simulator, which does a pretty convincing job of showing you (and making you wait for) the device booting up for the first time. Once the simulated iOS has booted, your app will start and you should be able to see the label you added to its main screen (Figure 2-20).

Figure 2-20. Your app in the iOS simulator

Running Your App on a Device, Using Free Provisioning

Now that we are satisfied that the app builds and runs on a simulator, let us have Xcode install and run it on an actual iOS device.

Provisioning

If you have done iOS development with ActionScript, you know that an app needs to be provisioned in order to be run on a physical device and what that means and thus you can skip this section and move on to the practical part in “Running your app.” But if you are new to programming for iOS, the following sections briefly describe how an app is prepared for installation and what you need to do.

What Is Provisioning ?

An app must match certain criteria in order to launch on an iOS device. Provisioning is Apple speak for what you need to do in order to prepare your app to match these criteria: the information about them is stored in a provisioning profile. A provisioning profile is an encrypted file, which is embedded in the app and is checked when the app tries to install itself on a device.

So, what criteria must be met?

• The app needs to have a unique identifier, App ID. The App ID can be specific to only one app, for example, com.diadraw.ideadrawapp. Alternatively, during development, the App ID can contain a wildcard in the place of the app name and be shared between several apps you are working on, for example: com.diadraw.*.

• Apple must know about you, the developer: this is where the Apple ID you registered before downloading Xcode comes in. Your Apple ID is used to create a signing identity—we helped Xcode create this for you at the end of Chapter 1 . When Xcode builds your app it also cryptographically signs it using this identity and this serves to certify that the app was built by you and not modified by anyone else.

• Before your app is ready for distribution, it can run only on devices that are known to Xcode, are registered for development, and have been set to trust your code signing identity. A third kind of ID helps with that: each iOS device has its own unique device identifier (UDID) that Xcode can access when the device is plugged in your development machine.

• If your app uses special features like push notifications, for example, it must have permission for that: the respective feature entitlements must be enabled in its provisioning profile.

Figure 2-21 illustrates this.

Figure 2-21. Criteria an app’s provisioning profile must meet

Where Does Free Provisioning Come In?

Until recently provisioning an app for development involved a lot of steps: you needed to source the information for the provisioning profile, register your app and device in Apple’s Developer Member Center, create and download the profile, then point Xcode to it. To be able to do all of this also required that you enroll and pay a yearly subscription for Apple’s iOS Development Program.

In contrast to this, Xcode 7 comes as a breath of fresh air: provisioning an app during development has been automated for you and done by the IDE and for the most part you don’t need a paid membership.

Free Lunch?

Maybe. Did you notice in the previous section how I said, “for the most part you don’t need a paid membership”? That’s right: while you develop your apps you can provision and test them for free, as long as they use only the basic iOS features. You will have to purchase membership in the iOS Development Program when you need to include more advanced features, also known as entitlements, or when you want to release your apps on the market. Following is a list of the entitlements that at the moment require you to be a member of the program:

• Apple Pay

• App Sandbox

• Associated Domains

• Game Center

• iCloud

• In-App Purchase

• Personal VPN

• Push Notifications

• Wallet

You can keep up to date with changes and additions to this list on Apples’ web site.

Note

The code in this book can be built and run using free provisioning. The two exceptions are the tutorials for using Push Notifications and iCloud in Part III: being able to implement these will need an iOS Development Program membership.

Running Your App

Before you run your app on a device, ensure that Xcode knows your Apple ID: it should appear in Xcode ➤ Preferences ➤ Accounts. If your account is not there, see the end of Chapter 1 for how to add it.

Now, select the main project in Project navigator. In the editor select the HelloXcode target, go to the General tab and choose your Apple ID from the Team drop-down (Figure 2-22).

Figure 2-22. Select your Apple ID in the project settings: General ➤ Identity ➤ Team

At this point you are likely to see a warning under the Team setting, saying “No code signing identities found.” If this appears, click the Fix Issue button and let Xcode resolve the problem: it will create a signing identity for you (Figure 2-23).

Figure 2-23. Let Xcode create a signing identity for you by clicking Fix Issue

Connecting Your iOS Device

Now connect an iOS device to your Mac. The device’s name should appear in the Scheme toolbar as shown in Figure 2-24.

Figure 2-24. Select your device on the toolbar

The device doesn’t appear on the toolbar?

If this is the first time you are using this device for iOS development, you will need to do a bit of preparatory work. From Xcode’s main menu select Window ➤ Devices. This opens Xcode’s central point for managing devices, which we will take a more detailed look at in Chapter 4 . Register your device for development by adding it to the list of devices known to Xcode: click the + button at the bottom of the window and follow the instructions (Figure 2-25).

Figure 2-25. Register your device for development

The device appears grayed out?

If you can see your device on the toolbar but it appears grayed out, it’s likely that the iOS version that our HelloSwift project is built for is higher than the iOS on your device. When this is the case, Xcode 7 displays a friendly warning next to the device’s name, saying “Unavailable Device” and “(OS version lower than deployment target).”

To fix that, open your app target settings (select the main project in Project navigator, then select the HelloSwift target in the editor), go to the General tab and in the Deployment Info section set Deployment Target to be the same or lower than the iOS version on your device (Figure 2-26).

Figure 2-26. Check if Deployment Target matches the iOS version on your device

Seeing Your App Running

Now, when you click the Run button, Xcode should automatically install and launch the app on your device (Figure 2-27).

Figure 2-27. Your first native app running on an iOS device

App won’t launch?

If this is the first time you have used the combination of this device and your Apple ID to do iOS development, there is yet another step you need to take.

If you see an error message like the one in Figure 2-28, open Settings ➤ General ➤ Device Management on your device. The signing identity Xcode created for you in Chapter 1 should be listed there: tap it and then tap Trust <Your Apple ID➤.

Figure 2-28. To fix this, get the device to trust your signing identity

Summary

In this chapter we created an app in Xcode and ran it in the simulator and on a physical device. This gave us an opportunity to explore the main parts of the Xcode IDE that you will use when you develop apps for iOS. Surprisingly, most of the work that needed to be done had nothing to do with coding but with what is necessary to prepare the app, your Apple account, and your development devices for testing.

With all of this in the bag, we can now move on to another development topic: debugging your apps, which is the subject of the next chapter.