Moving from Xcode 3 to Xcode 4

The majority of changes that will affect you for Xcode 4 are related to a redesigned user interface. This post offers a general overview of these differences, including hidden panels and integrated Interface Builder.

Overall Interface Redesign
Perhaps the most obvious change is that everything is now unified into a single-window interface.

When you first open a project in Xcode 4 (or create a new one), you’ll notice a lack of items in the lefthand portion (which under Xcode 3 would be the Groups & Files list). For the TextApp project from the first chapter of the book, you’ll find only a single item listed, with an Xcode project icon:

Expand this to see the files within it, and click a file to open it in the editor:

Because Xcode 4 is designed primarily so that everything occurs within a single window (it is still possible to double-click a file to open it in a separate window), many features are “hidden” behind panels and navigator controls.

The left portion of the main window contains Navigators, each of which is used to navigate through different aspects of a project—use the little icon buttons to choose which one. Since you’ll find yourself swapping between navigators fairly frequently, it’s worth pointing out that the icons correspond to the options in the View > Navigators menu, so each has a prominent keyboard shortcut.

If you’re relatively new to coding, or even just to Xcode, it’s easy to become confused as to why you’re not seeing what you think you should be seeing in this navigator pane. To see the list of groups and files, you need the Project Navigator (Cmd-1).

Debugger Console
The Debugger Console (a separate window under Xcode 3) has also been moved into the main interface, and the default keyboard shortcut has changed. You’ll need to use the segmented control labelled View in the main toolbar of the Xcode window to display the “bottom bar.”

This lower panel is known as the Debug Area in Xcode 4, and can also be hidden/shown from the View menu (Shift-Cmd-Y). The Debug Area has several purposes; it’s also used instead of another, separate Debugger window in Xcode 3. Depending on which you need (it’s the Console area on the right for this book), you can choose whether to show both panels or just one using the segmented control that appears in the lower panel of the window:

The default behavior in Xcode 4 is to hide the debug area each time you run an application. If you wish, you can change this—choose Xcode > Preferences… (Cmd-,) and select the Behaviors tab, then set what happens when a Run starts to Show the Debug Area automatically each time:

Note that if you’re particularly attached to any default Xcode 3 keyboard shortcuts, it’s possible to change the Xcode 4 shortcuts using the Key Bindings tab in the Preferences window.

Separate Windows
If you don’t like having everything arranged on the one window, Xcode 4 can open as many extra windows as you like. Double-clicking any file, for example, will open that file in a new window. Working with multiple windows can get confusing, though, particularly when it comes to closing the project. Skip this section if you’re still relatively new to Xcode in any version.

Once you have a new window open, you decide how much you want it to display. If you particularly want a separate debugger console window, for example, choose File > New > New Window (Shift-Cmd-T). By default, a new window opened in this way will display the same information as the previous front-most window. If this is the first new window you’ve opened for a project, you’ll effectively get two identical Xcode project windows. Use the new window’s main toolbar to turn off the left and right bars, and display the bottom bar, then drag the bottom bar up to fill the window:

Once you’ve done that, you can hide the main toolbar itself by clicking the button in the top right of the window’s title bar:

Xcode 4 will remember the window locations and layout when you close the project, but make sure you use File > Close Project to do so (by default this doesn’t have a keyboard shortcut, but you can add one in the Preferences window—in the Key Bindings panel, the command is listed as Close Workspace).

If you instead try to close the project by closing what looks to you like the main project window, the project will still be open, but with only the shrunk console window on display. If you then close this window as well (at which point Xcode will close the project because that’s the last open window), then all you’ll see when you next open the project will be the console window. The first time this happened to me, I had a minor panic trying to figure out how to get back to my original window. If this happens to you, just calmly re-display the main toolbar, and open the left, Navigators area. Hide the bottom bar, and you’ll be back to a normal “project window.”

Execution Controls
To match the iTunes-like single-window interface, the Xcode 3 Build and Run/Stop buttons have been replaced in Xcode 4 with simple Run and Stop buttons in the main toolbar:

The default shortcuts for Building (Cmd-B), Running (Cmd-R), and Cleaning (Shift-Cmd-K) remain the same under Xcode 4—the menu commands are found under the Product menu.

In the middle of the toolbar is a status area, again much like iTunes, to indicate what’s going on. If a Build fails with errors or generates warnings, these are indicated in this area.

Notice also that if errors or warnings are generated, these are displayed in the Issue Navigator pane on the left, which will appear automatically if issues are found. This Issue Navigator (Cmd-4) replaces the separate Build Results window under Xcode 3. As before, errors and warnings are displayed as overlays on top of the relevant code:

And, as mentioned earlier, when you want to get back to the list of files in the project you’ll need to switch to the Project Navigator pane (Cmd-1).

Editors
Xcode 4 has a variety of editor “modes,” including an Assistant editor. Any time you open a file when using the Assistant, Xcode 4 will also display what it thinks is the most closely-related file (such as the class interface header file for a class implementation).

Switch to the Assistant by using the Editor segmented control in the main toolbar, or choose View > Editor > Assistant (Opt-Cmd-Return):

Health Warning: Use of Xcode 4 may cause extreme desire for a larger monitor/display

If you prefer viewing just one file at a time, you can use the Related Files popup menu to jump between counterparts, and even superclasses, protocol definitions, etc:

Note that the default shortcut to display the counterpart file (i.e., jump from an implementation file to an interface file), has changed from Opt-Cmd-UpArrow to Ctrl-Cmd-UpArrow. Take a look at the list of Jump commands in the Navigate menu for a full list of helpful shortcuts.

The third editor, the Version editor, is used for projects under a source code Version Control System, e.g. Git or Subversion. Versioning isn’t something covered in the book, but it’s a great addition to Xcode for when you start using a system like Git.

Integrated Interface Builder
Interface Builder used to be a separate application, which would communicate behind the scenes with the Xcode 3 environment to make sure relevant code changes were represented in the interface. There were a few gotchas with this, including the need to save .xib or .nib files in Interface Builder before Building and Running in Xcode.

Under Xcode 4, the entire interface-editing environment has been integrated into the Xcode application itself.

When you click a .xib file, it will open in the editor:

The left hand side of this editor pane contains the icons representing the objects within the .xib file. If you click the window icon, the window will appear in the pane:

The blue box surrounding the window in the graph paper area includes a Close button to hide the window from the editor; if you need to show lots of objects in the editor pane, you can drag the blue box containers to rearrange items.

Inspectors
The object inspectors are no longer found under separate panels in Xcode 4; instead, you’ll need to use the main toolbar View segmented control to display the “right bar,” or Utilities area:

The top half of this Utilities area contains Inspector panels. Just like Navigators on the left of the window, you use the little icon buttons to swap between the different inspectors, which also have corresponding menu items and keyboard shortcuts:

Libraries
The lower half of the Utilities area is used for Libraries. Again, use the little icon buttons to switch between them (or use the menu options shown above). For interface editing, you’ll need the Object Library (Ctrl-Opt-Cmd-3):

Making Connections
IBOutlet and IBAction connections are made in the same way as they were in the standalone Interface Builder.

If you’re making a connection from one of several objects in the left-hand column of the Interface Editing panel, hover over any icon to show its class name:

Right-click (or Ctrl-click) to show the available connections, and click-drag out from the circle to make the connection:

Under Xcode 4, there’s also another connection option available if you use the Assistant Editor.

The Assistant Editor will display the class interface that it thinks is most closely related to the objects in a .xib file; for the TextApp application, this will likely be the TextAppAppDelegate.h file. Given that the connections you’ll need to make in the book are initially for the NotifyingClass object, you’ll need to use the Assistant’s file dropdown to choose one of the other related files, NotifyingClass.h:

Once you’ve done this, Xcode 4 allows you to make connections directly to the IBAction and IBOutlet entries in the code file:

You’ll need to hover over the code until the words “Connect Action” or “Connect Outlet” appear; if you hover in an empty area, or between lines, Xcode 4 will insert an action or outlet automatically at the code location where you release the mouse button.

If you hover in one place for two long, Xcode 4 may “drill down” into the code, and show you superclass interfaces, etc. If this happens, either use the file dropdown mentioned above, or the back/forward buttons at the top left of the assistant’s code file panel:

Project Template Changes
The templates seem to change with every minor revision of Xcode. For Xcode 4 onwards, you’ll find the organization of the project is slightly different from that shown in the book for Xcode 3. You should find that the files still have the same names, but the Classes group now has the name of your application, and the various resources and other sources are now found either inside this group or inside its Supporting Files group.

The code that’s included in the project templates has also changed a little. You’ll find that any provided init method, which used to look like this:

- (id)init
{
    if (self = [super init]) {
        // Initialization code here.
    }
   
    return self;
}

now looks like this:

- (id)init
{
    self = [super init];
   
    if (self) {
        // Initialization code here.
    }
   
    return self;
}

One change in Xcode 4 that may cause confusion is that you’ll now get a warning if you use the first style—you’ll now get a warning any time you use an assignment inside a conditional if() statement. If you are particularly attached to using this style, you’ll need to add an additional set of parentheses to silence the warning:

- (id)init
{
    if ((self = [super init])) {
        // Initialization code here.
    }
   
    return self;
}