Overview of the Project Editor in Xcode

By Neal Goldstein, Dave Wilson

You have to work within the context of an Xcode project to develop an iOS app. Having your project selected in the Navigator area’s Project navigator (as shown in the figure) sets a couple of balls rolling.


In the first column of the Project editor, under the Project heading, you see the project itself. A bit below the Project heading, you see the Targets heading. Any project you create defines the default build settings for all the targets in that particular project. (Note that each target can also specify its own build settings, which could potentially override the project build settings.)

A target is really just the app (the product you are building) and includes the information that Xcode requires to build the product from a set of files in a project or workspace — stuff like the build settings and build phases which you can see and edit in the Xcode project editor.

A target inherits the build settings for the project, but you can override one or more of them by specifying different settings at the target level. There is one active target at a time, with the Xcode scheme (iPad Simulator for example) specifying the target.

The Project editor shows tabs across the top; clicking these tabs opens panes that enable you to examine and change project settings. The tabs are as follows:

  • Summary: Each setting in the Summary tab is actually found in one of the other tabs. When you edit a setting, Xcode updates the data in the appropriate tab automatically (which is where the data really resides), meaning you probably won’t have to go into the other tabs.

    The iOS Application Target and iPhone/iPad Deployment Info sections of the Summary tab display settings based on the choices you made when you first created your project. (Notice that one of the settings is Deployment Target. While you must compile your project using the current SDK, you can target it to run on earlier iOS versions.

    There’s a section on the Summary tab for adding an app icon. (The launch image is what is displayed while your app is launching — kind of like provisional eye candy that hangs around until the app is ready to use.)

    The Summary tab is also your go-to place for adding a new framework to your app.

  • Info: An information property list file contains essential configuration information for a bundled executable (the executable code and the accompanying resources, such as the storyboard, nibs, images, sounds, and so on). The system uses these keys and values to obtain information about your application and how it’s configured. As a result, all bundled executables (plug-ins, frameworks, and applications) are expected to have an information property list file.

  • Build Settings: Most developers can get by with the default build settings, but if you have special requirements — ones that require anything from tweaking a setting or two to creating an entirely new build configuration — you’ll take care of them in this tab.

  • Build Phases: This tab has a number of sections that control how Xcode builds your products. For example, Xcode detects when one of your products is dependent on another and automatically builds those products in the correct order. However, if you need to tweak the order in which Xcode builds your products, you can use the Build Phases tab to create explicit target dependencies.

  • Build Rules: Xcode processes your source files according to file type using a set of built-in rules. For example, property list (plist) files are copied into the product using the CopyPlistFile script located in the Xcode directory. Because the built-in rules are fine for almost all circumstances, you won’t need to mess with this particular tab for a long time — and if you’re lucky, never.