Windows

A typical iOS application has only one window, which provides the backdrop for all of the application’s content. Applications can include additional windows, if desired, but doing so is rare and generally not recommended.

Views and Controls

In iOS, everything that appears onscreen descends from the UIView class. In practical terms, views and controls are rectangular regions that display data and are capable of handling events. Buttons, text fields, image views, and table views are all examples of views, with buttons being a specific type of view called a control.

It's unusual to add views to an iOS application’s main window, set up in the MainWindow nib file. Instead, iOS applications generally contain one or more additional nib files (where the File's Owner is a view controller), each with a view at the top level of the file. In the top-level view, you place other subviews (buttons, text fields and so on). Applications use these additional nib files to display different screens’ worth of content in the main window. To learn more about using these files, see View Controllers.

Custom Views

Although the standard system views and controls provide a variety of choices for building an interface, there are many times when you may want to provide customized behavior for your application. If your nib document is associated with a Cocoa Touch project, Interface Builder is aware of any custom views declared in your source code. You can find your custom views listed in the Classes tab of the Library window. Dragging a custom view object to a window (or to the top level of your nib document) creates an unadorned rectangular area representing the space occupied by the object. Interface Builder sets the object’s class name in the identity inspector, as illustrated in Figure 4-1. To learn about setting the class identity of a generic view object, see Setting the Class of an Object.

Toolbars

Toolbars contain a collection of buttons representing frequently used commands in an application. Toolbars are typically located along the bottom edge of your user interface. You can configure the appearance of a toolbar in different styles to suit your interface needs. You can also configure the buttons in a toolbar using several different styles, which are shown in Figure 4-2.

To add a toolbar to your user interface, drag a tool bar view from the library and drop it in your window or view. The default toolbar contains a single bar button item, but you can add additional items by dragging them from the library. You can configure the properties of each bar button item using the inspector. You can also edit the title of a bar button item by double-clicking it on the design surface.

- (IBAction)myActionHandler:(id)sender;

Controller Objects

In addition to visual objects, Cocoa Touch nib files can include any type of custom object (including non-visual objects) needed by an application. The ability to include any instance of NSObject is typically used as a way to facilitate the Model-View-Controller design pattern used by iOS applications. The non-visual objects in a nib file act as controllers for the visual objects.

Figure 4-3 shows the basic object types you can add to a Cocoa Touch nib file. In addition to the generic object type, Cocoa Touch nib files can include two other special object types. View controller objects provide custom management for an application’s user interface and are used heavily in iOS applications. Because an application’s interface may be spread over multiple nib files, Interface Builder also includes a placeholder object, which you can use to represent any additional objects that are distinct from the File’s Owner placeholder.

View Controllers

Because an iOS application has only one window, the application changes the window’s content by changing the content views displayed in the window. The content view is the portion of an iOS window that you use to display your application’s custom content. The content view is not necessarily a single view but may in fact comprise several views embedded inside a parent (or root) view.

Management of the content view is the responsibility of a view controller object, which coordinates the movement of that content on and off the screen. Because it is a controller, you can also add custom logic to your view controller classes to manage interactions between the content view and your application’s data model.

In addition to providing navigation and tab bar controller objects, Interface Builder provides a generic view controller object that you can use for managing individual views. The most common way to use a view controller is as the File’s Owner of a nib file, but you can also instantiate them inside your nib file as needed.

Adding a View Controller to Your Nib File

If you add a view controller to the top level of your nib file, double-clicking that controller object opens the editor window shown in Figure 4-4. This window acts as the design surface for your view controller’s view. Views you add to it are embedded as child objects of the view controller object in your Interface Builder document. The root view of your hierarchy is also assigned to the view outlet of the view controller by default.

The view controller editor displays a status bar (and other top bars and bottom bars) if the properties of that view controller indicate that one is present. These elements are not saved with your nib file and are provided to help you position your views and other content. You should configure the attributes of your view controller to match the presence of the status bar or other elements in your application window.

Tab Bars

Tab bars give the user a way to switch between different user interface modes in an application. Tab bars are typically used by applications to manage large amounts of information or to present information in different ways for the user. For example, the Clock application uses a tab bar to change between different clock-related utilities, as shown in Figure 4-5. Pressing each button in the tab bar displays a unique interface for that mode.

In Interface Builder, the way to configure a tab bar interface is not by adding views to your window. Instead, you need to add a tab bar controller object to the top level of your nib file and configure your views using the custom editor for that object. When you add a tab bar controller object to your document, Interface Builder actually adds several other objects. In addition to the tab bar controller, it adds a tab bar view and two generic view controllers, each of which contains its own tab bar item. Interface Builder groups these objects together under the tab bar controller, as shown in Figure 4-6.

The grouping of the tab bar objects as children under a tab bar controller reflects the object graph relationships between those objects. A tab bar controller’s children consist of its tab bar view and the view controllers used to manage each of its tabs. The view controllers are actually stored in the viewControllers property of the tab bar controller object, which can also be set programmatically. The tab bar view is added to the overall view associated with the tab bar controller, which is stored in the controller’s view property.

The relationship of objects in the document window also reflects the way those objects are presented by Interface Builder. When you double-click a tab bar controller object, Interface Builder displays the tab bar controller editor window, shown in Figure 4-7. This editor window reflects the child objects of the tab bar controller and is where you configure your tab-based user interface. Items you add using this interface are similarly added as children to the tab bar controller or the view controller that owns them.

The tab bar controller editor displays a status bar (and other top bars and bottom bars) if the properties of that view controller indicate that one is present. These elements are not saved with your nib file and are provided to help you position your views and other content. You should configure the attributes of your tab bar controller to match the presence of the status bar or other elements in your application window.

Selecting one of the tab bar items in the tab bar controller editor window shows the views associated with the corresponding tab. In fact, clicking a tab bar item once selects the view controller that manages that item. Clicking the same item again selects the actual tab bar item.

Although the tab bar controller lets you edit the objects associated with the tab bar interface, simply editing those objects does not make them appear in your application window. To display your tab bar interface, you must programmatically retrieve the tab bar controller’s view and add it to your window as a subview. For example, if your application delegate has outlets referring to your tab bar controller object and application window, its applicationDidFinishLaunching: method would need to look something like the following:

- (void)applicationDidFinishLaunching:(UIApplication *)application

{

    [window addSubview:[myTabBarController view]];

}

For information about configuring tab bars and tab bar controllers programmatically in your application, see Tab Bar Controllers in View Controller Programming Guide for iOS.

Navigation Bars

Navigation bars are a visual element used in conjunction with a navigation controller object to navigate complex data hierarchies quickly and easily. The navigation bar displays the current location in the navigation hierarchy, provides an optional button for navigating back to the previous location, and provides an optional button for manipulating data at the current level. Figure 4-8 shows these components in the navigation bar used by the Mail application.

Although the navigation bar conveys contextual information to the user, the navigation controller provides the driving force behind displaying that interface and managing the view controllers that coordinate each screen’s content view. Therefore, to configure a navigation interface in your nib file, you add a navigation controller object to the top level of your nib file.

When you add a navigation controller object to your Interface Builder document, you actually get several objects. In addition to the navigation controller, you get a navigation bar and a generic view controller. Interface Builder groups these objects together under the navigation controller, as shown in Figure 4-9.

When you double-click a navigation controller object, Interface Builder displays the navigation controller editor window, which is shown in Figure 4-10. This editor window displays the child objects of the navigation controller object and is where you configure the root view of your navigation-based user interface.

The navigation controller editor displays a status bar (and other top bars and bottom bars) if the properties of that view controller indicate that one is present. These elements are not saved with your nib file and are provided to help you position your views and other content. You should configure the attributes of your navigation controller to match the presence of the status bar or other elements in your application window.

Although the navigation controller lets you edit the objects associated with the navigation-style interface, simply editing those objects does not make them appear in your application window. To display your navigation interface, you must programmatically retrieve the navigation controller’s view and add it to your window as a subview. For example, if your application delegate has outlets referring to your navigation controller object and application window, its applicationDidFinishLaunching: method would need to look something like the following:

- (void)applicationDidFinishLaunching:(UIApplication *)application

{

    [window addSubview:[myNavBarController view]];

}

If your navigation-style interface is used in conjunction with a tab bar interface, you would show the tab bar controller’s view in your delegate’s applicationDidFinishLaunching: method instead of your navigation interface. Whenever you combine navigation and tab bar interfaces, the tab bar interface must be used for the root level of your window. You can embed navigation controllers inside of a tab bar interface but you cannot do the reverse.

For information about configuring navigation bars and navigation controllers programmatically in your application, see Navigation Controllers in View Controller Programming Guide for iOS.

MyViewController* vc = [[[MyViewController alloc]

                            initWithNibName:@"MyViewController"

                            bundle:nil] autorelease];

[myNavController pushViewController:vc animated:YES];

Windows and Panels

Windows and panels provide the backdrop for drawing your application’s content. Every application that has a graphical user interface has at least one window associated with it. Some applications may use multiple windows in different styles to present primary content (such as user data) or secondary content (such as inspectors or other utility windows).

In Cocoa applications, windows are based on the NSWindow class of the AppKit framework. In Carbon applications, views are based on the WindowRef data type.

Views

Views are the most commonly used objects in Interface Builder. The standard system views display data, respond to user input, and implement standard interface paradigms such as scrollable areas, controls, and many others. Applications can also create custom views and use them to display custom visual content and respond to user interactions.

In Cocoa applications, views are based on the NSView class of the AppKit framework. In Carbon applications, views are based on the HIViewRef data type.

Custom Views

Although the standard system views and controls provide a variety of choices for building an interface, there are many times when you may want to provide customized behavior for your application. If your nib document is associated with a Cocoa project, Interface Builder is aware of any custom views declared in your source code. You can find your custom views listed in the Classes tab of the Library window. Dragging a custom view object to a window (or to the top level of your nib document) creates an unadorned rectangular area representing the space occupied by the object. Interface Builder sets the object’s class name in the identity inspector, as illustrated in Figure 4-11. To learn about setting the class identity of a generic view object, see Setting the Class of an Object.

Because a custom view is one you are in the process of creating in your Xcode project, Interface Builder does not attempt to draw anything other than a generic box at design time. If you want to see the appearance of your custom view as it would appear at runtime, you must incorporate the finished view into an Interface Builder plug-in and load that plug-in. For more information about plug-ins, see Using Plug-ins to Integrate New Objects into the Library.

Controls and Cells

A control is just a type of view that handles a specific user interaction pattern and delivers messages to your application when that pattern occurs at runtime. When the user interacts with a control, the control object notifies your application in a way that is appropriate for the application type. Controls in a Cocoa application deliver a message to a target object. Controls in a Carbon application post an event to the application’s designated event handler routine.

In Cocoa, the behavior of a control is provided by its cell object. Cells are lightweight objects that draw the control’s contents and respond to user events within the control’s frame. Prior to Interface Builder 3.0, controls and cells were treated as a single unit. In Interface Builder 3.0 and later, however, it is possible to manipulate cell objects independent of their owning control. You can select a cell and inspect its attributes (although in most cases, the attributes are shared with the control) and you can create connections to the outlets and actions of a cell independent of the the parent control object. The only time you might do this, however, is for the NSMatrix class, which can contain multiple cells. In most other cases, you should treat a control and its cell as a single entity.

You add controls to your window and remove them in the same manner as views. If you define custom cell classes, however, you can also substitute your custom cell for the standard cell of a control. To change the class of a cell, do the following:

1. Select the cell using the click-wait-click action on the control. (Alternatively, select the cell from the document window while it is in outline mode.)

2. Open the inspector window and choose the Identity pane.

3. In the Class field of the Class Identity section, enter the new class name for the cell. (If the class is defined in the associated Xcode project, Interface Builder automatically displays any outlets and actions defined by the custom cell class.)

When you save your Cocoa nib file, Interface Builder archives the custom cell information with the control. When the nib file is loaded at runtime, the nib loading code automatically creates your custom cell object instead of the standard one and assigns it to the control. This alleviates the need for you to set the cell object in your awakeFromNib method and also makes it easier to use different cell types for each control.

Custom Cells

Prior to Interface Builder 3.2, the library contained only specific NSCell subclasses such as NSTextFieldCell. This made it impossible to use a class that descended directly from NSCell in Interface Builder. The custom cell solves this problem.

A custom cell is analogous to a custom view. You can use a custom cell to represent any NSCell subclass.

Toolbars

Toolbars provide the user with a convenient way to access frequently used commands without leaving the current window. A toolbar occupies the space between the title bar of a window and the window’s content view. It spans the width of the window and displays one or more commands using a combination of icons and text. Toolbars are configurable by the user at runtime and developers use a very similar technique at design time to create the initial toolbar configuration in Interface Builder.

Adding a Toolbar to a Window

To add a toolbar to a window, simply drag the toolbar item from the Library window and drop it on your window, as shown in Figure 4-12. The default toolbar comes configured with several standard items, including a color panel item, fonts panel item, print item, separator item, and fixed and variable spacer items.

Customizing the Contents of a Toolbar

To customize a toolbar, double-click the toolbar in your window. Doing so opens up the toolbar customization sheet, which you can use to add, remove, and rearrange items in the toolbar (Figure 4-13). This sheet is similar to the customization panel the user sees when configuring a toolbar at runtime and works in much the same way.

To add a new custom item to the toolbar, do the following:

1. Drag an Image Toolbar Item from the Library window and drop it onto the customization sheet.

2. Select the Image Toolbar Item and open the inspector window.

3. In the Attributes pane of the inspector window, set the following attributes:

   • The name of the image to use for the item (Image Name attribute)

   • The item text as it appears in the toolbar (Label attribute)

   • The name of the item as it appears in the user customization sheet (Pal. Label attribute)

4. Position the item in the customization sheet by dragging it to the desired location.

5. If you want the item to be part of the default toolbar, drag it to the toolbar.

6. Click Done to close the customization sheet.

The image name you specify should correspond to an image resource from your associated Xcode project. When specifying the image name in the inspector window, you do not need to include the filename extension. Your images should be sized appropriately for the size of the toolbar you plan to use. Regular size toolbars use images that are 32 by 32 pixels. Small toolbars use images that are 24 by 24 pixels. If an image file contains multiple image representations, the Image Toolbar item chooses the one that is closest to the toolbar size and then scales it as needed.

Menus and Menu Items

Menus are an important part of Mac OS X applications. Every application displays a menu bar with commands for manipulating the application and its data. Menus can also appear in more localized parts of your application. For example, applications often use context-sensitive menus to store commands relevant to the object underneath the cursor. All of these types of menus are represented in Interface Builder using menu resources.

A menu resource is a special type of object that holds a collection of menu items. Menu items represent the actual commands included in the menu. You can also insert submenu items in situations where you want to create a hierarchical organization for your menu items. Figure 4-14 shows the menu objects that appear in the Library window. In addition to the basic menu resource and menu item objects, the library contains preconfigured menu resources representing standard system menus, such as the Font and Window menus.

The following sections describe the standard ways to create and organize menu bar and menu resources. For information on how to tie those menu items to specific parts of your application code, see Connecting Menu Items to Your Code.

Collection Views

In Mac OS X v10.5 and later, you use collection view objects to manage a grid of NSView objects in a Cocoa application. You can use a collection view in situations where using NSCell objects in a matrix would be insufficient. Because they are full-fledged views (and not cells), the views in a collection view can handle events, perform mouse tracking, and do anything else a view could normally do without having to write a lot of custom code.

When you drag a collection view to one of your windows, Interface Builder creates two additional objects at the top level of your nib file:

• A generic NSView object, which acts as a template view for the items in the collection.

• An NSCollectionViewItem object, which is a controller that manages the relationship between a model object and a single view in the collection.

These two objects serve as the prototype for each item in the collection view. The collection view uses the prototype view as a template for creating each new view in the collection. Each time it creates a new view at runtime, it also creates the corresponding NSCollectionViewItem object to manage that view.

Configuring a collection view involves configuring the template view and setting up bindings between it and the corresponding controller object. The contents of your view can be anything you want. You could even use a tab-less tab view to create different interfaces for different views. The controls in your view are then bound to the NSCollectionViewItem object through its representedObject binding.

To provide the actual data behind the representedObject binding, you must set the content of the collection view object itself (not the NSCollectionViewItem controller). You can do so directly using the setContent: method of the NSCollectionView class, or you can set the content using Cocoa bindings. The content attribute of NSCollectionView stores an array of data objects, each of which contains the custom data to be displayed by one view in the collection. As it populates the grid of views, the collection view automatically associates the items in this array with the corresponding NSCollectionViewItem objects used to manage the grid views. Each collection view item then exposes its particular piece of data through its representedObject attribute. If the custom data objects you set as the content for your collection view are KVC and KVO compliant, you can bind to their exposed attributes. For example, if your custom data object exposed a name attribute, you could bind a text field in your template view to the collection item controller using the key path “representedObject.name“.

Controller Objects

In addition to visual objects, Cocoa nib files can include any type of custom object (including non-visual objects) needed by an application. The ability to include any instance of NSObject is typically used as a way to facilitate the Model-View-Controller design pattern used by Cocoa applications. The non-visual objects in a nib file act as controllers for the visual objects.

Including controller objects directly inside a nib file has many advantages over creating them separately. Cocoa nib files are typically managed by a single object (known as the File’s Owner) that exists outside of the nib file itself. However, it is often convenient to use additional controller objects to manage portions of the nib file contents. In particular, Cocoa bindings make extensive use of custom controller objects to manage the interactions between the views and the application’s underlying data model.

Figure 4-15 shows the types of custom objects you can add to a Cocoa nib file. The generic NSObject type lets you create an instance of any object that descends from the NSObject class. In addition to this type, Interface Builder provides specialized objects representing specific NSController subclasses for managing Cocoa bindings. The Core Data objects provide a way to incorporate managed object contexts and interfaces for your Core Data entities into your nib files.

To add a generic NSObject instance to your nib file, simply drag the Object item from the library and drop it on your Interface Builder document window. (Custom objects cannot be embedded inside other objects in your nib file; they must reside at the top level of the Interface Builder document window.) After adding a generic object to your nib file, you should specify the intended class of that object right away. Doing so lets you connect any outlets or actions of that object to other objects in your nib file. For information on how to set the class of an object, see Setting the Class of an Object.

Like generic objects, you must drag controller objects to the top level of your Interface Builder document window. Unlike generic objects, you should not change the class of a bindings controller object. For information on how to configure the bindings controllers, see Using Cocoa Controller Objects.

View Controllers

Applications with only one window often change their content by changing the content views displayed in that window. The content view is the portion of a window that you use to display your application’s custom content. The content view is not necessarily a single view but may in fact comprise several views embedded inside a parent (or root) view. Management of the content view is the responsibility of a view controller object, which coordinates the movement of that content on and off the screen. Because it is a controller, you can also add custom logic to your view controller classes to manage interactions between the content view and your application’s data model.

Interface Builder provides a generic view controller object that you can use for managing individual views. The most common way to use a view controller is to instantiate it inside your nib file, but you can also use it as the File’s Owner of the nib file.

Core Data Objects

Interface Builder works with Xcode to support the creation of user interfaces based on Core Data entities. After creating your data model in Xcode, all you have to do to create an interface for that entity’s data is drag a Core Data Entity object into one of your windows. Interface Builder steps you through the creation of your interface using a series of design panels, which let you pick what you want to display and show you the appearance of the resulting user interface. Upon completion, Interface Builder adds the appropriate views to your nib file and connects them to the corresponding entities in your data model. If you want to manage the data in your Core Data database yourself, you can also add managed object contexts to the top level of your nib file. Figure 4-16 shows the managed object context and entity items as they appear in the library.

For more information about creating user interfaces for Core Data applications, see Xcode Tools for Core Data. For more information about creating Core Data programs, see Core Data Programming Guide.

Formatter Objects

Cocoa applications can use formatter objects to automatically format data displayed in text-based controls. Cocoa provides built-in formatters for number and date values. The formatters themselves use a set of predetermined rules to format the values they receive into something more understandable for the user. For example, you can use a number formatter to display a number as a currency value, with the appropriate separator characters and monetary indicator included in the resulting string.

For information about how to apply formatters to your Cocoa objects, see Applying Formatters.

File’s Owner

File’s Owner is the most commonly used placeholder object in nib files and is supported by both Cocoa and Cocoa Touch nib files. In essence, the File’s Owner placeholder is the main bridge between your application and the contents of a nib file. In a nib file, the File’s Owner placeholder is a placeholder for an object that you plan to specify when you load the nib file. The object does not exist in the nib file itself and is not created when the nib file is loaded.

When you load your nib file into memory, the nib-loading methods expect you to pass along an object that you want to designate as the nib-file owner. The class of the object you specify must match the class of the File’s Owner placeholder in the nib file. As the nib file is loaded into memory, the nib-loading code substitutes the object you provide for any references to the File’s Owner placeholder in the nib file. This substitution results in your object’s outlets and actions being automatically connected to the objects inside the nib file.

You can designate any of your application objects as the File’s Owner of a nib file. Typically, the File’s owner object is a controller object that manages the interactions with the views and other controller objects inside the nib file. Table 4-1 lists some of the standard classes that are commonly used to represent File’s Owner in applications.

To configure the File's Owner placeholder, select it in the Interface Builder document window and open the Identity inspector. In the Class field of the Class Identity section, set the value to the corresponding class in your application. Once the class is set, Control-clicking the File's Owner object displays the outlets and actions defined by that class. You can use these outlets and actions to connect other objects to File's Owner. You can use File's Owner as a target for your bindings. For information about configuring and connecting to File's Owner, see Connections and Bindings.

First Responder

Cocoa and Cocoa Touch applications use the First Responder placeholder object as a placeholder for the first object in the responder chain. The First Responder typically corresponds to the currently selected object or the object with the current focus in the frontmost window. You use the First Responder as a target for any messages that operate on the current selection or need to be handled by the frontmost window or document. For example, if you wanted a menu command to be handled by the frontmost window, you would dispatch that command to the First Responder object.

The First Responder is not required to respond to a given message. If the First Responder does not respond to a given message, Cocoa passes that message to other objects in the responder chain until one does respond. If no object responds, the message is ignored. It is the responsibility of the objects in your responder chain to implement action methods for messages you want to handle.

The First Responder placeholder initially displays all of the actions that are either supported natively by Cocoa or defined in your Xcode source files. If you want to add action methods to the First Responder that are not present in either of these locations, you can do so using the Identity inspector. The First Responder Actions section of the Identity inspector includes a plus (+) button for adding new actions to the available list. For information on how to make connections to the First Responder placeholder, see Establishing Connections to the First Responder.

For more information about event handling and the responder chain in Mac OS X applications, see Cocoa Event Handling Guide. For information about the role of the responder chain in iOS applications, see App Programming Guide for iOS.

Application

In Cocoa nib files, the Application placeholder object gives you a way to connect the outlets of your application’s shared NSApplication object to custom objects in your nib file. The default application object has outlets for its delegate object and, in Cocoa applications, the application menu bar. If you define a custom subclass of NSApplication, you can connect to any additional outlets and actions defined in your subclass.

At load time, the nib-loading code automatically replaces the application placeholder object with the shared application object from your application. You do not need to specify this object explicitly when loading your nib files.

Custom Placeholder Objects

The objects in an iOS application’s user interface tend to be much more intertwined than they are on other platforms. Many iOS application interfaces are organized around view controller objects, which manage a hierarchy of views. These view controller objects may then have to interact with several other controllers and views that are already present in the running application. To accommodate the presence of these extra controllers, Interface Builder supports the specification of custom placeholder objects for iOS applications.

You configure custom placeholder objects in the same way that you configure a generic object. You add the placeholder object to the top-level of your Interface Builder document, set its class, assign it a name, connect its outlets and actions, and save it with the rest of your document to a nib file. At load time, however, the nib-loading code does not instantiate a new instance of your placeholder object. Instead, your call to load the nib must be accompanied by a pointer to the real object that represents the placeholder. The nib-loading code then swaps in the real object for the placeholder and proceeds to reconnect the outlets and actions of that object. You can include any number of custom placeholder objects in your nib file.

The key to replacing a placeholder object at load time is in naming the object. The nib-loading code requires you to specify both the replacement object and the name of that object in a dictionary. You specify the name of the object in the Name field of the Identity inspector. Placeholder object names in your nib file must be unique in order to ensure the correct objects are connected to the right placeholder. The rest of the placeholder object configuration is the same as it is for other objects. You set the class as described in Setting the Class of an Object and configure the actions and outlets as usual.

For information about how to replace placeholder objects with real objects at load time, see Resource Programming Guide.

Factor Your Interfaces Appropriately

Deciding what objects go into a nib file is an important consideration. Because nib files are resource files, it is generally better for performance if a nib file contains only the immediately needed objects. If your nib file contains several unrelated windows and menus, you pay an upfront memory penalty when loading that nib file. Any objects in a nib file that are not put to immediate use remain in memory and increase your application’s footprint. In addition, if an object is paged to disk before it is even used, you pay a penalty for having to load it from disk twice.

Cocoa nib files are typically organized around a single window or menu resource. Cocoa Touch nib files are typically organized around a single window or content view resource. All other objects in the nib file are those that are needed to support the given window, menu, or view resource. For example, the nib file might contain any additional controller objects needed to manage the resource.

If you already have nib files with many unrelated resources, you can use the built-in refactoring tools to break your nib file up into smaller, independent nib files. For information about using the refactoring tools, see Refactoring Your Nib Files.

Use the Embed Commands

Interface Builder makes it easy to embed existing views in your interface inside other views quickly. Rather than dragging a new container view into your window and copying your objects into it, you can use the Layout > Embed Objects In menu instead to create the desired container relationship. This option is the most effective way to create embedded relationships for most container views.