Running and Testing on the Device

Automating our tests and testing the user interface will eliminate a lot of problems that can come up in our app. But we still have another big blind spot: what if the app behaves differently in the iOS Simulator app than it would on a real device?

This is not idle speculation. Macs are generally more powerful than iOS devices, so apps often run faster in the Simulator than on real iOS hardware. A mouse or trackpad pointer is more precise than a finger touch, so running in the Simulator might also blind us to usability problems in the app. And there is some functionality that simply doesn’t exist in the Simulator: the Simulator won’t pretend that the Mac’s built-in webcam is either of the iPhone cameras, and we can’t tilt our laptop back and forth to test motion-sensing code.

To have full confidence in our app, we need to run it on the device. Let’s close out the chapter by doing that.

Preparing the Device

To start with, we need an iOS device running the current version of iOS, since this is what our app expects to run on. If your device is running something older, you can go to the app target, find the iOS Deployment Target under Build Properties, and set that to a lower version than the default.

Connect the device to the Mac with its USB cable. The first time you do this, Xcode may present a dialog asking if you want to use the device for development; be sure to approve this.

Once the device is connected, it will appear in the scheme selector above the various Simulator, but as being “unavailable.” Running on the device will take a little more work than just plugging in the cable.

Preparing a Developer Account

Apple doesn’t let just anyone run anything on a device. Prior to Xcode 7 and iOS 9, putting our own code on an iOS device required being a member of the developer program. That’s a bridge we’ll cross much later (in Chapter 17, ​Publishing and Maintaining the App​), but in the meantime, it’s now possible to get our app running on our device with just a little fuss.

To put an app on a device, Apple wants to know who we are and what we’re doing. That’s always been the case; what’s different in Xcode 7 is that they’ll let pretty much anyone do it, not just paid-up members. Either way, the first step is to sign into Xcode. Open Xcode’s preferences (⌘,) and select the Accounts tab. We visited this tab back in ​Getting Local Documentation​, in order to download local copies of the documentation. If you skipped that step, well, do it now: click the + to add an Apple ID, and sign in with your credentials (the same ones used for the Mac App Store to download Xcode in the first place).

Just signing in isn’t enough. Go to the target’s General tab, where you’ll see a warning that there are “No code signing identities found.” Code signing is the process of using cryptographic techniques to provably verify that a known developer is the one installing the app to the device, and therefore the operation can be allowed. Fortunately, we don’t have to do the underlying math; there’s a handy Fix Issue button. Go ahead and click it.

If all goes well, this will use our Apple ID from the Accounts tab to download and set up the needed credentials to allow us to put apps on the device. We’ll talk more about how these actually work later, in ​Member Center​. Fixing the issue may also make you choose a Development Team; there should only be one, with your Apple ID name followed by (Personal Team), so use that.

When the issues are resolved, the warning in the target about signing identities becomes a pop-up with a choice of Team. Also, the device will be available in the scheme selector, without the (Not Available).

Select this destination and run the app as usual (be sure to unlock the screen first, since Xcode can’t enter your PIN for you). After a short delay in which Xcode rebuilds the app for the device’s CPU (which is different than the Simulator’s, after all), it copies the app across the USB cable, onto the device.

The first time you run it, there’s one more wrinkle: Xcode trusts you and the device, but the device may not trust you. This shows up as an Xcode error sheet saying “process launch failed; Security.” If this happens, open the settings app on the device itself and select General. You’ll see a new section called Profiles & Device Management and, within it, the section Developer App, which shows your Apple ID. Click this and, on the screen that follows, tap to trust apps from your Apple ID, as shown in the following figure.

With this last security issue resolved, running the app in Xcode will make it run on our device and behave just like before. At least we hope it does! If it doesn’t, then we have a device-specific issue. And in cases where behavior differs between device and Simulator, the device always wins, since that’s what our users will run the app on. In fact, it’s so important to focus on the device that the testing techniques we’ve learned throughout the chapter all work on the device too; just choose a device in the scheme selector before running the test.