Some developers try and fight Interface Builder, and would rather code up the interfaces rather than let Interface Builder do most of the work for them. Of course, there are instances where this may be useful, but in the grand scheme of things IB is a tool which has lots of useful features that makes interface design a much easier process.

Layout and alignment

Interface Builder provides blue guides to aid positioning of objects, in accordance with the Apple Human Interface Guidelines. However, if you want a tighter grain of control over the layout, there are other guides which help you with this.

Pressing option with an interface object selected causes red arrows to be displayed on the four sides of the object, with labels displaying the number of pixels from the frame of the object to the edges of the container.

With the option key still held down, placing the cursor over another interface object will show you the spacing between the frame of the selected object and the frame of the object you have the cursor over. This can be useful in times when making sure objects have equal alignments with neighbouring objects, or within the window itself.

There are also the Align Vertical Center in Container and Align Horizontal Center in Container options from the Layout > Alignment menu which are useful in centering objects within their container (and which I personally think should also have keyboard shortcuts associated with them).

Option-drag to duplicate objects

It really does what it says on the tin. To duplicate objects just hold down the option key then drag an object. A clone of the object will be created which you can then move to the desired location.

Decompose and Simulate Interface

These are two useful options that are accessible from the File menu.

The first is Decompose Interface. An advantage of using NIBs is that they can be loaded lazily – that is, only when the contained objects are actually needed by the application. This can reduce the memory footprint and loading times, which is particularly useful when developing iPhone applications due to the somewhat limited system resources available.

Therefore a common design pattern for Cocoa/Cocoa-Touch applications is to share different objects – be that menus, windows, view controllers and such – across multiple nibs – not necessarily one per nib, but perhaps two or three that are needed for a particular part of the application and have to be loaded together. What the Decompose Interface action does is split objects in the current nib into separate nibs, which can then be saved and then loaded lazily by the application in this way.

The other action, Simulate Interface, is a convenience when designing an interface; instead of having to go back to Xcode and Build and Run to see what the interface looks like, you can do it straight from Interface Builder, which will simulate the current window and its contents.

However, note that if you use any custom views, any custom visual or behavioural attributes will not be implemented by the simulator – it does not build your application, just simulates the available objects used by your interfaces from the Library.

Size to Fit

Size to Fit is an option available from the Layout menu (or ⌘=) which resizes a view to a size just large enough to fit its contents.

This is useful after changing the contents of an element to then resize it to just the right size to fit its contents.

Precise selection of Views in the view hierarchy

This is another really useful feature of Interface Builder; when making a selection, hold down shift and then right-click on an element. A menu will pop up, which lists the views in the view hierarchy for that element, from the enclosing Window (or other appropriate top-level container) to the interface object that you have clicked on. For example, when clicking on an NSButton, the menu lists Window, Content View, Push Button and Button Cell.

Where I’ve found this to be particularly useful is with Table Views; the particular part of the table that you want to select very much depends on what you want to do; if you are binding to a column for instance, you will want to select the table column; if you are resizing the headers, you will want to select the header view; if you want to change the row height, you want to select the Table View itself, and so forth.

Selection of these individual components is rather difficult and annoying, and you often have to time your clicks appropriately to select the part of the Table View that you want. However, shift-right-clicking on the Table View means that you can select the appropriate item – be that the table column, the cell for a column or the Table View itself – by selecting the appropriate item from the popup menu.

Smart Groups

Smart Groups can be created in Interface Builder much like smart groups in applications such as the Finder or iTunes. These are listed in the Library window, along with the other object groupings.

Smart Groups provide a means of filtering objects based on a predicate (or filter) based on such properties as object label, the most recently used objects, or the kind of class an object is. This last property can be especially useful. For example, if you want a Smart Group that lists all NSView objects or subclasses, you can set the predicate to:

<Is A Kind Of> NSView

And the group will contain all NSView classes or subclasses.

Smart Groups can be created by clicking on the actions button at the bottom of the Library window and selecting New Smart Group.

Font Menu

Another useful menu is the Font menu, which allows you to set the font and font attributes of items in your interface. This can be useful when setting fonts of controls or cells, such as changing the font size, weight or colour of a cell in an NSTableView, for example, which saves you having to do it with code.

Info Panel

The Info panel provides useful information about the nib that you are currently editing and its contained objects. It allows you to specify a deployment and development target, and shows any errors that your interface may have when deploying to that target.

For example, placing an NSCollectionView instance in a window and selecting a deployment target of Mac OS X 10.4 will show an error that the NSCollectionView class is not supported on versions of OS X prior to 10.5.

The Info panel can also show useful information about layout, for example if a window lies partially hidden off the screen which means that it will be partially hidden from view when unarchived and displayed.

Project Breakpoints

Breakpoints are a great convenience method for debugging your code. However, if you have lots of breakpoints, how do you manage them all easily?

When you add a breakpoint it appears in the Breakpoints folder in the Groups & Files list under Project Breakpoints. From here, you can turn breakpoints on and off and remove them, and change the conditions or add/remove breakpoint actions easily (from the accompanying detail view shown above the Editor pane) without having to navigate to each breakpoint directly. This is a great convenience for batch methods, such as removing all breakpoints.

Groups of breakpoints can also be created, by right-clicking on any number of breakpoints and selecting Group from the context menu.

Breakpoints for a specific source file can also be easily shown using the breakpoints popup list button in the Editor window, which lists the breakpoints detailing the method they are set in, and the line number that they apply to. Clicking on a breakpoint in the list will navigate to the source file and highlight the row that that breakpoint is applied to.

Class Navigation

Class navigation is a convenience for exploring the class hierarchy for a given class. It presents itself as a popup menu in the Editor window, which lists the superclasses, the class itself and any categories present on the class. The class that the menu displays information about is flexible: if the text caret in the editor window is within a class interface (between @interface and @end) or a class implementation (between @implementation and @end), the class navigation popup menu will provide information about that class.

This is a useful tool, especially when subclassing an existing class. Since subclassing builds on the existing functionality and implementation of a class (or classes), it may often be necessary to access inherited instance variables or provide custom implementations for inherited methods. By simply clicking on the class name of a superclass in the class navigation menu, you are taken to the superclass interface, which details the instance variables and methods which you can extend in your subclass.

Code Folding and Focus Follows Selection

As any Objective-C programmer knows, it is not the most concise language in the world – it is far from it, and it is so with some reason. However, this can make the readability of your source files difficult, especially if you are working with a class that has lots of methods implemented.

Code Folding and Focus Follows Selection are two options from the View menu which help to increase the readability of code. Code Folding is a way of folding functions and other braced parts of code into stubs, which makes the code dramatically more easy to read, whilst still providing the first line of a function or code block to show what the folded code is a part of. It can be applied from the View > Code Folding menu, with menu items to fold the code block that the text caret is currently placed in, unfold all items in the current source file, fold/unfold all methods and functions, and fold/unfold all comment blocks.

Focus Follows Selection is another feature used to help readability. When this is turned on, Xcode will highlight the block of code that the text caret is placed in (be it a method/function or other parenthesised block such as an if statement) and dim the rest of the editing area, making it easier to see in which block you are working. This can be very useful for nested loops or where there is nesting of braced pieces of code. It is presented as a checkable menu item in the View > Code Folding menu

Smart Groups

Smart Groups are a way of organising your project files based on a filter. Selecting Project > New Smart Group from the menu and then either Simple Filter Smart Group or Simple Regular Expression Smart Group allows you to create a Smart Group based on a wildcard expression (for example, *.nib would match all files ending in .nib) or a regular expression. You can also select where Xcode starts looking for files in the project folder hierarchy by changing the value in the “Start From:” dropdown box. You can then also select whether the group applies to all projects created in Xcode, or just the project that you are currently working on.

This is an easy way to keep your project(s) organised for you, which can reduce clutter across the Groups & Files list. As with all folders in the hierarchy in the Groups & Files list, it is purely virtual – that is, any items placed in Smart Groups will have no effect on their physical location on disk.

There are two Smart Groups that are present with Xcode by default – “Implementation Files” and “NIB Files”, which contain the project’s implementation and NIB files respectively.

Splitting the Editor View

Often it is useful to edit more than one source file at the same time, in the same editor window. This can be achieved easily by clicking on the Split Editor View button. This will add an extra editor view to the current window, resizing the other editor view(s) to fit. Then, when files are selected from the source list they will be loaded into the currently active editor view. There is an editor bar for each editor view (containing the history list, and method list etc) which is applicable to that view. There is also a resizing separator between the editing views to allow you to resize them.

Editor views can then also be easily removed by clicking on the Close Editor view button on that pane, located under the split editor view button for that editor view. This will resize the other editor views accordingly.

Keyboard Shortcuts

There are a plethora of keyboard shortcuts in Xcode to perform common tasks associated with various aspects of the development tool. Here is a handy chart of all the Xcode keyboard shortcuts available (note that this chart was created by Colin Wheeler):

All-In-One View

In the Xcode preferences, the default layout is, oddly enough, the Default layout. This is better set to All-In-One, since it adds extra panes to the main window, such as the Page toolbar item, which allows you to switch between the Project and Debug modes with one click, in the same main window. Also, a tabbed menu is added above the editor window, with tabs for Detail, Project Find, SCM Results and Build, which make it easier to access different windows within your project, keeping them within the same workspace. To change the layout to All-In-One, open up the Xcode preferences (⌘+,) and in the General preferences, change the Layout preference to All-In-One.

The #pragma mark directive

The #pragma mark directive is very useful in organising implementation files, especially those with a large number of methods. It can be placed anywhere in the source files, and is used as a way of grouping common methods. It takes the form:

#pragma mark <Label>

Where <Label> is the name you want to associate. For example:


#pragma mark Drawing- (void)drawRect:(NSRect)rect {
// Drawing code here.
}//... other methods here, if necessary

and it allows you to group together methods in the Project Symbols list; with any method signature following the group name being listed underneath the group title you have assigned.

Clicking on any of the method names selects the method declaration in the file and scrolls down to that point; in this way it is easy to navigate around the implementation files, even if they contain a lot of code or methods.

Finding APIs in the documentation

When writing code in Xcode, it is not uncommon for you to need to take a look at the documentation for a particular symbol, be that method, class, or even data types, for example. You could do this by going to Help > Documentation and then typing in the name of the symbol into the search field, and then hitting return.

However, there is an easier way. In your source file, double-click on the word that you want to look up in the docs, whilst holding down the ⌥ (option) key. This will then open up the documentation window, filling the search field in with the word that you want to look up.

Finding declarations

It may also be the case that you want to look up the declarations for symbols, as defined in the headers. For example, you may wish to find the interface for NSObject or the typedef for NSUInteger. Again, this is easily accomplished. In your source file, double-click on the symbol that you want to find the declaration for, whilst holding down the ⌘ (command) key.

Bookmarking Code

Xcode allows you to add bookmarks to your project, not just of source files themselves, but even lines within the files. These bookmarks get added to the Bookmarks section in the Groups & Files pane. To add a bookmark, place the text caret on the line which you want to bookmark, and select Edit > Add to Bookmarks or (⌘+D); the name of the file the line originates from, and the line number will be displayed as the bookmark name, although this can be renamed by clicking on the bookmark name.

Go to Counterpart

Classes are one of the major additions to the Objective-C superset of C, and are used frequently in. There exists class interface and implementation files for any class, and it is frequent to switch between both, such as when declaring a method in the interface, then implementing it in the implementation. There is a button which makes switching between the two easier, titled Go to Counterpart; clicking on it will change the editor window to the implementation for that class, if working within the class interface file, or the interface if working within the implementation file.

Whether the counterpart is opened in the same editor window or another editor window is determined in the Xcode General preferences, with the “Open counterparts in same editor” checkbox.

Simple Housekeeping

When dealing with Xcode projects, the number of files present can quickly mount up, whether that be source code, resources, NIBs or any other files that your project uses. When adding files to the project, Xcode doesn’t add them to any particular directory in the Groups & Files list, so it is up to you to do this. Note that the directory structure in the Groups & Files list is purely virtual – any movement of files within the hierarchy has no physical effect on disk. To add groups to the list, simply right click in the window and select Add > New Group, and once added, groups can be dragged around like you would in a Finder window. Here is a summary of the various groups and files within the project subdirectory:

1. Classes: as it says on the tin, place class interface (.h) and implementation (.m) files in here. It may be useful to group class files based on their purpose, for example naming groups Controllers or Models, etc to make it easier to find the source files when you need them.
2. Other sources: this group is for source files that do not declare classes; main.m is here by default. Since most source files deal with classes, there are usually not so many files in here, unless you are creating a non-AppKit based application, such as a Foundation Tool.
3. Resources: where all the project resources are placed, be that NIBs, or images, for example, this is the place to keep it. It may be useful to group resources based on their function, especially NIBs since in larger projects the number of these can quickly mount up.
4. Frameworks: this is where the frameworks that your project uses are. Xcode adds the Cocoa, AppKit and Foundation frameworks for you when a project is created, but if you need to link against others, this is the place to put them. If a lot of frameworks are being linked to, it would be best to create extra subdirectories to organise the linked frameworks. Frameworks can be added by right clicking in the Groups & Files window and selecting Add > Existing Frameworks..
5. Products: these are the products of building the target(s). Normally there is only one product, your .app application file, so extra organisation of this subdirectory is not usually particularly necessary.

Debugging

A lot of time is often spent debugging your application. The interface can be made more straightforward in the Debugging pane of the Xcode preferences. There is a popup menu labelled On Start: this is how the workspace will change when debugging of your application begins. Its default is Do Nothing, however selecting Show Console, Show Debugger or Show Console and Debugger are useful so that when you begin to debug your application the workspace can update itself accordingly to make debugging a more straightforward process.

Start with Performance Tool..

The Xcode Tools do not encompass simply Xcode and Interface Builder; there are a few other other tools bundled with the package that are useful when testing projects, such as Instruments and Shark. Instead of having to build your application every time then manually loading it into the designated tool, it can be done from the Run menu. From Run > Start With Performance Tool, you can load your application into Shark, MallocDebug or one of the Instruments templates, such as Leaks.