Volume Number: 19 (2003)
Issue Number: 8
Column Tag: Programming

Getting Started

Xcode Rising

by Dave Mark

Beautiful weather. A gorgeous new venue called Moscone West. And a keynote by Steve Jobs. Ah, the annual pilgrimage to Apple's World Wide Developers Conference. I had a great time and met a lot of you at the conference. Moscone West is across 4th street from Moscone Center, the traditional site of MacWorld Expo. A state of the art facility, WWDC marked its maiden voyage. Yes, we were the first conference ever held here. Cool!

As usual, Steve Jobs did an excellent job with the keynote (check out Scott Knaster's July column for a blow-by-blow account). My favorite part was when Steve rolled out Xcode, Apple's replacement for Project Builder. Everyone who attended the conference got a set of Xcode disks, one install for Panther and another for Jaguar. Since Panther is still not released, I thought I'd focus on the Jaguar version of Xcode.

To start off our guided tour of Xcode, let's take a classic Project Builder project and open it in Xcode. First, launch the Xcode app. You'll find it in /Developer/Applications. Once Xcode launches, select Open from the File menu. Navigate into the Sample Code directory in /Developer/Examples/AppKit/. We'll be playing with the Sketch project. In Xcode's open dialog, you could click on the Sketch directory, then scroll through all the files looking for the project file. But do this instead: Click on the Sketch directory, then click the Open button without selecting a file to open. Xcode will find and open the first project file it encounters in that directory. Cool!

Yeah, I know, why not just find the project file in the Finder and double-click it? Two reasons. First, I wanted to show off Xcode's ability to auto-open the project file. And second, I still have Project Builder installed on my machine. Since Sketch's project is a Project Builder file, when I double-click on the project, the Finder launches Project Builder.

Another solution: In the Finder, click on the project file, then do a Command-i to bring up the Get Info window (see Figure 1). Click on the Open with: disclosure triangle and select Xcode from the popup menu. If you have not yet run Xcode, select Other... from the popup and go find the Xcode app. You can click on the Change All... button to make this change for all your Project Builder projects.

When you click the Open button, Xcode will warn you that you are opening an old project file and that it will be upgraded if you continue (See Figure 2). Not a prob. Click the Open button and let's charge forward.

Figure 3 shows the Sketch project window that appears once Xcode upgrades the old Project Builder project file. If your project window looks radically different, perhaps you've mucked with the preferences or customized the toolbar (the strip of icons at the top of the window). To get back the original toolbar, select Customize Toolbar... from the View menu, drag the default toolbar from the bottom of the window that appears to the toolbar at the top of the window, then click Done. Definitely worth spending a minute or two with this, just to get a sense of the kinds of changes you can make to your toolbar.

When Xcode upgrades an existing project file, it converts the project file format, but does not convert the targets themselves. To understand what this means, you have to know a little bit about build systems. Project Builder originally used Make as its build system. Make is a traditional Unix utility that parses dependencies listed in a text-based makefile.

If Make is new to you, take a minute, fire up Terminal, and type in the command man make. This will list the man pages for the make command and will give you the basics on build systems.

Over time, Project Builder moved to an open source build system named Jam. Here's a link that'll give you the basics on Jam:

http://www.perforce.com/jam/jam.html

Jam offers a more compact and sophisticated build language than Make, but is still a text-based build system.

Xcode uses its own, native build system, a build system that is more tightly integrated with the IDE, has a better understanding of the project dependencies and, therefore, produces better build performance. Since the command line and graphical versions of the build system were themselves built from the same frameworks, there is no noticeable performance change when you move between the two.

You can still use the legacy build mechanisms that work with Project Builder. However, you'll need to move to "native builds" if you want to take advantage of Xcode features like Zero Link, Fix and Continue, and Distributed Builds.

Our next step is to upgrade the Sketch target so it uses Xcode's native build system. In the project window's Groups & Files pane, click on the Targets disclosure triangle to reveal the list of targets in this project. At this point, there is a single target, named Sketch. Click on Sketch, then select Upgrade Target to Native from the Project menu.

A panel will appear in the project window that tells you what is about to happen and gives you a chance to name your new target (Figure 4). Leave the name as Sketch (Upgraded) and click the Upgrade button.

Now, when you look at the list of targets in the project window, you'll see your new Sketch (Upgraded) target. Select Sketch (Upgraded) from the popup in the upper-left corner of the project window to make this target the active target (Figure 5). Note that the active target has a small green checkmark in its icon.

Active targets are important! When you do a run, build, or debug, the active target is the one that is run, built, or debugged. You might have one target with full debug info turned on, and a second target that is optimized with no debug info. You might have one target that uses a legacy build system and another that uses Xcode's native build system. Make sure you have the right active target selected before you do your build.

Xcode uses the inspector window to modify target settings. As an example, select the Sketch (Uprade) entry under Targets, then bring up the inspector window (either click on the i-in-a-circle on the toolbar, or type command-i). In the inspector window, click on the Build tab. Each entry in this list is a setting followed by a value. Some values are set via popup menus, some by typing in text, others with checkmarks. Depends on the setting type.

Take a careful look at Figure 6. There's a lot going on here. First, I clicked on the Build tab, then clicked on the little "drawer" icon in the lower left corner of the inspector window. This opened the drawer to the side, which allows me to select from different sets of settings.

I then clicked on the Prebinding setting to select it, then clicked on the split bar at the bottom of the window and dragged it up, revealing an explanation of this setting.

Note also that there is a search field at the bottom of this window. Suppose there were hundreds of settings and I wanted to find anything to do with optimization. If I type "optim" in the search field, the settings are whittled down to two, one of which is called Optimization level and the other of which has the word optimization in its explanation text. Very powerful stuff.

On the left side of the project window and just under the active target popup, you'll find the Groups & Files Pane. First in this list is the Files Group, which lists all the files that make up your project. If you click on this group, you'll see an alphabetical listing of all the project's files, including your Classes, Other Sources (such as main.m and any precompiled headers), Resources (Credits.rtf, Info.plist, InfoPlist.strings, and your nib files), Frameworks, and the Products produced by your project.

Figure 7 shows a default project, based on a Cocoa Document-Based Application template. The five sub-groups that make up the test Files Group are what you get when you create your project. As you might expect, you can create new subgroups (control-click on a group name and select New Group from the contextual menu and edit the name of any group (option-click on the name). You can also click and drag any group to move it up and down in the list or place it within another group in the hierarchy. Very intuitive. Very nice.

The second group in the Groups & Files pane is the Targets group, which we've already discussed. The third group is your Executables group. By default, your project will contain a single executable (see the test executable, shown in Figure 7). Note that when we upgraded our target in the Sketch project, we also created a second executable, called Sketch (Upgraded).

The next group is the Errors and Warnings group. Click on this group and the errors and warnings from your last build are shown. Let's give this a try. In the Sketch project window, click and hold the first hammer icon in the toolbar, then select Build from the popup menu that appears.

Figure 8 shows the result of my Sketch build. This build generated 2 warnings, both of them in the file SKTDrawDocument.m, and 1 error, in the file Sketch_main.m (the warnings are actually part of the shipping Sketch project, the error is one I purposefully introduced). If you click on the Errors and Warnings group itself, you'll see a list of all the errors and warnings in the project. If you click on one of the file names in the group, you'll see a list of errors and warnings in that file. Finally, if you double-click on the Errors and Warnings group, you'll get a separate window with an upper split that lists all the errors and warnings in the project, and a lower split that allows you to edit the source code associated with the selected error or warning. Basically, the project window without the Groups & Files pane.

The Errors & Warnings group is an example of what Apple calls a smart group. Smart groups are dynamic groups that change based on some action or rule. For example, the Errors & Warnings group is rebuilt each time you do a build. As you'll see when we get to the Find Results group a bit further along, smart groups are a very powerful part of Xcode's arsenal.

Next up is the Implementation Files smart group. This is an example of a rule-based smart group. To see what I mean, click on the Implementation Files group and then click on the Show info panel icon (an italic i in a blue circle) in the toolbar or type command-i to bring up the inspector window. Rule-based smart groups can be generated using regular expressions or simple patterns. As you can see in the inspector window shown in Figure 9, the Implementation Files smart group searches the project directory, recursively, to find all files that match the regular expression:

?*\.[mcMC]

In effect, this regular expression matches any file name that ends in one of ".m", ".c", ".M", or ".C", placing the list of matching file names in the Implementation Files smart group. To learn more about regular expressions, check out this link:

http://www.grymoire.com/Unix/Regular.html

O'Reilly also has a book on regular expressions (is there nothing they don't cover?) called Mastering Regular Expressions, 2nd Edition.

When you click on the Implementation Files group, if the main area does not change, bring up the inspector window (command-i), click in the Using Pattern: text field, and hit enter. That should force the list to update. A tiny glitch. Probably fixed already!

The NIB Files smart group is just like the Implementation Files group, except it uses simple pattern matching instead of regular expression matching, returning all files that match the simple pattern "*.nib". Smart groups are sweet.

But they get even sweeter. The Find Results smart group allows you to refine a search using the search field on the right side of the toolbar. Here's an example. Bring up the Sketch project and select Find in Project... from the Find menu. Enter draw in the Find: field and check the Ignore Case checkbox, then click Find (see Figure 10).

A list of files should appear in the detail pane (the main part of the project window) and the status bar (the thin horizontal strip immediately below the toolbar) should say 1 of 294 selected. So our find just found 294 occurrences of the word "draw" in the project hierarchy. The results of this find were added to the Find Results smart group under the name draw.

Now let's refine our search a bit. Click on the draw subgroup (it may already be selected). In the search field (right side of the toolbar), type the word "white". You should see 2 matches, for the function NSDrawWhiteBezel, both in SKTGridView.m. You just did a search within a search. Very cool!

Next on our list is the Project Symbols smart group. Click on the Project Symbols group and a list of project symbols appears. As you might expect, you can use the search field to filter your symbols. If you click on the magnifying glass icon in the search field, a popup menu appears that lets you select from Search by All, Search by Symbol, Search by Symbol Type, and Search by Location (these are the three column headers in the detail area). Pick the type of search you want to do, then start typing. In Figure 11, I did a Search by Symbol Type and typed in "ma". This reduced the symbol list to show the project macros. Nice!

I've been using Xcode like crazy since WWDC and I find the design very intuitive. Xcode does what I expect it to do. I am impressed, and even more so given that this is prerelease software. Yes, there are a few bugs, but for me they've all been minor. But be smart. Be safe. Backup your projects before you port them to Xcode. After all, prerelease is prerelease

There are a few interface elements I'd like to see cleaned up. Some are simple refresh issues. Others are behavioral. For example, I'd like to see the little triangle to the right of the magnifying glass icon in the search field only appear when there is a popup menu for that search field's context. And if there is a popup menu, how about including checkmarks next to any selected items so you can go back and see what the current settings are. Don't let these tiny nits deter you even one nanosecond. Xcode is an incredible leap forward.

Before I go, just a few quick things. First, wheel over to http://developer.apple.com and check it out. They've completely redone the site. I find it much easier to navigate now, with a lot more detail on the front page. I also wanted to thank (profusely) the folks at Apple who spent so much time answering my Xcode and Cocoa questions. A special shout out to the folks who staffed the OS X and Tools labs at WWDC. You rock!

Whelp, I'm out of space and out of time. Next month, we'll dig a little deeper into Xcode. There is so much more to cover. There's Code Completion, Zero Link, Fix and Continue, and Distributed Builds just to name a few. See you then...

Dave Mark is a long-time Mac developer and MacTech contributor. Author of more than a dozen books on various Mac-development topics, he's also a founding partner of the nationally syndicated Online Tonight and Net Music Countdown radio programs. All this and now he's got some fish!