A Xcode project is a file that contains a list of references to other files (source code, resources, frameworks, and libraries) as well as a number of settings that lay out the rules for items within the project. Projects end in .xcodeproj, as in TouchTracker.xcodeproj.

A project always has at least one target. When you build and run, you build and run the target, not the project. A target uses the files in the project to build a particular product. The product that the target builds is typically an application, although it can be a compiled library or a unit test bundle.

When you create a new project and choose a template, Xcode automatically creates a target for you. When you created the TouchTracker project, you selected an iOS application template, so Xcode created an iOS application target and named it TouchTracker.

To see this target, select the TouchTracker item at the very top of the project navigator’s list. In the editor area just to the right of this item, find a toggle button (Figure 14.20). Click this button to show the project and targets list for TouchTracker.

Figure 14.20  TouchTracker project and targets list

Every target includes build settings that describe how the compiler and linker should build your application. Every project also has build settings that serve as defaults for the targets within the project.

Let’s look at the project build settings for TouchTracker first. In the project and targets list, select the TouchTracker project. Then click the Build Settings tab at the top of the editor area (Figure 14.21).

Figure 14.21  TouchTracker project build settings

These are the project-level build settings – the default values that targets inherit. In the top-right corner is a search box that you can use to search for a specific setting. Start typing “Base SDK” in the box, and the list will adjust to show this setting. (The Base SDK setting specifies the version of the iOS SDK that should be used to build your application. It should always be set to the latest version.)

Now let’s look at the target’s build settings. In project and targets list, select the TouchTracker target and then the Build Settings tab. These are the build settings for this specific target. Above the list of settings, find and click the Levels option (Figure 14.22).

Figure 14.22  TouchTracker target build settings

When viewing the build settings with this option, you can see each setting’s value at the three different levels: OS, project, and target. The far right column shows the iOS Default settings; these serve as the project’s defaults, which it can override. The previous column shows the project’s settings, and the one before that shows the currently selected target’s settings. The Resolved column shows which setting will actually be used; it is always equal to the left-most specified value. You can click in each column to set the value for that level.

While you are here, search for “static analyzer” in the build settings list. You can set the Analyze During 'Build' setting to Yes for Xcode to automatically run the static analyzer every time you build your application. This will slightly increase the amount of time that it takes to build, but is generally a good idea.

Build configurations

Each target and project has multiple build configurations. A build configuration is a set of build settings. When you create a project, there are two build configurations: debug and release. The build settings for the debug configuration make it easier to debug your application, while the release settings turn on optimizations to speed up execution.

To see the build settings and configurations for TouchTracker, select the project from the project navigator and the TouchTracker project. Then, select the Info tab (Figure 14.23).

Figure 14.23  Build configurations list

The Configurations section shows you the available build configurations in the project and targets. You can add and remove build configurations with the buttons at the bottom of this section.

When performing a scheme action, the scheme will use one of these configurations when building its targets. You can specify the build configuration that the scheme uses in the scheme editor in the option for Build Configuration in the Info tab.

Changing a build setting

Enough talk – time to do something useful. You are going to change the value of the target build setting Preprocessor Macros. Preprocessor macros allow you to compile code conditionally. They are either defined or not defined at the start of a build. If you wrap a block of code in a preprocessor directive, it will only be compiled if that macro has been defined. The Preprocessor Macros setting lists preprocessor macros that are defined when a certain build configuration is used by a scheme to build a target.

In the project and targets list, select the TouchTracker target and the Build Settings tab. Then search for the Preprocessor Macros build setting. Double-click on the value column for the Debug configuration under Preprocessor Macros. In the table that appears, add a new item: VIEW_DEBUG, as shown in Figure 14.24.

Figure 14.24  Changing a build setting

Adding this value to this setting says, “When you are building the TouchTracker target with the debug configuration, a preprocessor macro VIEW_DEBUG is defined.”

Let’s add some debugging code to TouchTracker that will only be compiled when the target is built with the debug configuration. UIView has a private method recursiveDescription that prints out the entire view hierarchy of an application. However, you cannot call this method in an application that you deploy to the App Store, so you will only allow it to be called if VIEW_DEBUG is defined.

In BNRAppDelegate.m, add the following code to application:didFinishLaunchingWithOptions:.

 ​ ​ ​ ​[​s​e​l​f​.​w​i​n​d​o​w​ ​m​a​k​e​K​e​y​A​n​d​V​i​s​i​b​l​e​]​;​
#​i​f​d​e​f​ ​V​I​E​W​_​D​E​B​U​G​
 ​ ​ ​ ​N​S​L​o​g​(​@​"​%​@​"​,​ ​[​s​e​l​f​.​w​i​n​d​o​w​ ​p​e​r​f​o​r​m​S​e​l​e​c​t​o​r​:​@​s​e​l​e​c​t​o​r​(​r​e​c​u​r​s​i​v​e​D​e​s​c​r​i​p​t​i​o​n​)​]​)​;​
#​e​n​d​i​f​
 ​ ​ ​ ​r​e​t​u​r​n​ ​Y​E​S​;​
}​

This code will send the message recursiveDescription to the window. (Notice the use of performSelector:. recursiveDescription is a private method, so you have to dispatch it in this way.) recursiveDescription will print a view’s description, then all of its subviews, and its subviews’ subviews and so on. You can leave this code in for all builds. Because the preprocessor macro will not be defined for a release build, the code will not be compiled when you build for the App Store.

Now build and run the application. Check out the console and you will see the view hierarchy of your application, starting at the window.