`R. Surati
`12/01/2022
`Mac Dev Center: Resource Programming Guide: Introduction
`11/27/22, 11:20 PM
`The Wayback Machine - https://web.archive.org/web/20100114164340/http://developer.apple.com:80/mac/li…
`Mac OS X Reference Library
`Apple Developer
`Connection
`
`Introduction
`
`Applied to computer programs, resources are data files that accompany a program’s executable code.
`Resources simplify the code you have to write by moving the creation of complex sets of data or graphical
`content outside of your code and into more appropriate tools. For example, rather than creating images pixel
`by pixel using code, it is much more efficient (and practical) to create them in an image editor. To take
`advantage of a resource, all your code has to do is load it at runtime and use it.
`
`In addition to simplifying your code, resources are also an intimate part of the internationalization process for
`all applications. Rather than hard-coding strings and other user-visible content in your application, you can
`place that content in external resource files. Localizing your application then becomes a simple process of
`creating new versions of each resource file for each supported language. The bundle mechanism used in both
`Mac OS X and iPhone OS provides a way to organize localized resources and to facilitate the loading of
`resource files that match the user’s preferred language.
`
`This document provides information about the types of resources supported in Mac OS X and iPhone OS and
`how you use those resources in your code. This document does not focus on the resource-creation process.
`Most resources are created using either third-party applications or the developer tools provided in the
`/Developer/Applications directory. In addition, although this document refers to the use of resources in
`applications, the information also applies to other types of bundled executables, including frameworks and
`plug-ins.
`
`Before reading this document, you should be familiar with the organizational structure imposed by application
`bundles. Understanding this structure makes it easier to organize and find the resource files your application
`uses. For information on the structure of bundles, see Bundle Programming Guide.
`Organization of This Document
`This document includes the following chapters:
`
`•
`
`“About Resources” provides an introduction to the resource types supported in Mac OS X and iPhone
`OS.
`
`“Nib Files” describes the Cocoa-specific support for nib files.
`
`•
`
`“Carbon Resources” describes the Carbon-specific support for nib files.
`
`•
`
`“String Resources” describes the support for localized string resources in applications.
`
`•
`
`“Image, Sound, and Video Resources” describes the support for image, sound, and video resources in
`• - - - - - - - - - - - - - - - - - - - - - -
`applications.
`
`https://web.archive.org/web/20100114164340/http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/Introductio… 1/2
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0001
`Petitioner Apple Inc., Ex. 1071
`
`
`
`11/27/22, 11:20 PM
`
`Mac Dev Center: Resource Programming Guide: Introduction
`
`See Also
`The following ADC Reference Library documents are conceptually related to Resource Programming Guide:
`
`•
`
`Bundle Programming Guide describes the bundle structure used by applications to store executable code
`and resources.
`
`•
`
`Internationalization Programming Topics describes the process of preparing an application (and it’s
`resources) for translation into other languages.
`
`Interface Builder User Guide describes the application used to create nib file resources.
`
`•
`
`•
`
`•
`
`Property List Programming Guide describes the facilities in place for loading property-list resource files
`into a Cocoa application.
`
`Property List Programming Topics for Core Foundation describes the facilities in place for loading
`property-list resource files into a C-based application.
`
`Last updated: 2009-01-06
`
`Did this document help you? Yes It's good, but... Not helpful...
`
`Shop the Apple Online Store (1-800-MY-APPLE), visit an Apple Retail Store, or find a reseller.
`
`Mailing Lists
`RSS Feeds
`
`•
`
`•
`
`Copyright © 2009 Apple Inc. All rights reserved.
`
`Terms of Use
`Privacy Policy
`
`•
`
`•
`
`Mac Dev Center Right arrow Mac OS X Reference Library Right arrow Data Management: File
`Management Right arrow Resource Programming Guide
`
`- - - - - - - ~
`
`https://web.archive.org/web/20100114164340/http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/Introductio… 2/2
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0002
`
`
`
`Mac Dev Center: Resource Programming Guide: About Resources
`11/27/22, 11:21 PM
`The Wayback Machine - https://web.archive.org/web/20091122060420/http://developer.apple.com:80/mac/lib…
`Mac OS X Reference Library
`Apple Developer
`Connection
`
`spyglass
`button
`
`About Resources
`
`There are several reasons to use resources in your application:
`
`They can reduce the amount of code needed to create your application’s user interface.
`
`•
`
`They make it possible to change your application’s user interface without changing any code.
`
`•
`
`They make it easy to localize your application’s user-visible content.
`
`•
`
`They can store other types of custom data that might be difficult or time-consuming to create at runtime.
`
`•
`The following sections describe the types of resources typically found in applications and how you use them.
`Nib Files
`Nib files are the quintessential resource type used to create graphical applications. A nib file is a data archive
`describing the objects, configuration, and layout information associated with an application’s user interface. You
`create nib files using the Interface Builder application, which provides a graphical assembly area for the
`windows and menus that comprise applications. You assemble windows and menus in Interface Builder by
`dragging and dropping custom views, controls, and other components from the provided library of objects. In
`addition to positioning items inside a window or view, you can configure the properties of those items as well so
`that they have the custom look and behavior you want for your application. In Cocoa applications, you can also
`create connections between objects to facilitate the passing of messages between them.
`
`When you load a nib file, the nib-loading code recreates your objects exactly as they were when you designed
`them, including any custom configuration or connection information. Because the objects are given to you fully
`configured, it is possible to create complex user interfaces (see Figure 1-1) with very little code.
`
`Figure 1-1 User interface resources
`
`User interface resources
`
`Nib files are supported widely by both Mac OS X and iPhone OS, although there are some subtle differences in
`how nib files are supported from environment to environment. Mac OS X and iPhone OS both provide the same
`basic level of support for loading nib files and using their contents. For example, both provide nib-loading
`support through the NSBundle class and automated support for loading the application’s main nib file. In Mac OS
`X, Cocoa provides additional support for loading nib files associated with documents and for using the NSNib
`class to load nibs. The Carbon environment also supports the use of nib files, although the semantics for using
`them are different. For Carbon applications, nib files are a repository of user interface items that can be loaded
`one-by-one, instead of all at once.
`
`https://web.archive.org/web/20091122060420/http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/LoadingResources/MOS… 1/5
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0003
`
`
`
`11/27/22, 11:21 PM
`Mac Dev Center: Resource Programming Guide: About Resources
`Note: The term “nib” and the corresponding file extension are an acronym for “NeXT Interface Builder.” The
`Interface Builder application was originally developed at NeXT Computer, whose OPENSTEP operating system
`was used as the basis for creating Mac OS X.
`
`For general information on how to use nib files in Cocoa-based applications (including iPhone applications), see
`“Nib Files.” For information on how to use nib files in Carbon applications, see “Carbon Resources.” For
`information on how to create nib files, see Interface Builder User Guide.
`String Resources
`Text strings are a prominent part of most user interfaces. Text strings are commonly found in an application’s nib
`files but may also be found in other places as well. For example, if an error occurs, an application might load a
`string corresponding to that error and display the string in an alert panel. Instead of hard-coding such strings
`inside source files, which would make localization much more difficult, an application can instead load them
`from a strings resource file.
`
`A strings resource file (also known as a strings file because its file extension is .strings) is a human-readable
`text file (in the UTF-16 encoding) containing a set of string resources for an application. The purpose of strings
`files is to provide an external repository for an application’s localizable text. An application can have any
`number of strings files and each strings file can contain any number of strings. Each entry in a strings file
`consists of a key-value pair where both the key and value are themselves strings. The key portion never changes
`and represents the identifier that your application uses to retrieve the string; however, the value for that key is
`typically translated to one of the languages your application supports.
`
`Mac OS X provides tools to help you automatically generate strings files for your application. The tools search
`your code for any usage of specific string-loading routines and use that code to generate strings files for you. For
`more information about loading string resources and generating strings files, see “String Resources.”
`Image, Sound, and Multimedia Resources
`Mac OS X and iPhone OS make extensive use of image resources (and to a lesser extent sound and multimedia
`resources) to create a unique visual style for the entire system. Some of these image resources are used to
`implement the glossy, three-dimensional texture commonly found in system components, such as the Aqua
`controls. Apple applications make extensive use of high-quality images to create the look and feel typically
`associated with the underlying system. Developers are similarly encouraged to use high-quality images to create
`beautiful and easy-to-use interfaces for their applications. The use of images can not only simplify your drawing
`code but for complex visual elements can improve performance by providing a prerendered version that can be
`cached and reused.
`
`Because images are such an important part of graphical user interfaces in general, and Mac OS X and iPhone OS
`in particular, each system provides extensive support for loading and drawing image resource files. Both Mac
`OS X and iPhone OS provide support for loading and decoding image files saved in a variety of different
`formats. For resource files, however, the most commonly used formats include PNG, TIFF, PDF, GIF, and JPEG.
`
`Just as you use images, you can use sound and multimedia resources to create a unique presentation style for
`your application. Although used less frequently than images, sounds can be used to provide feedback or to alert
`the user to special events. Audio support is provided by the Core Audio family of frameworks and also by
`
`https://web.archive.org/web/20091122060420/http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/LoadingResources/MOS… 2/5
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0004
`
`
`
`Mac Dev Center: Resource Programming Guide: About Resources
`11/27/22, 11:21 PM
`custom classes in the AppKit framework. Similarly, you can use movie clips to present video-based content.
`Mac OS X also provides extensive use for video and multimedia resources through the QuickTime and
`QuickTime Kit frameworks. In iPhone OS, similar support is provided by the Media Player framework.
`
`For information about how to use image, sound, and video resources in your applications, see “Image, Sound,
`and Video Resources.”
`Property Lists
`Property list files are a way to store custom configuration data outside of your application code. Mac OS X and
`iPhone OS use property lists extensively to implement features such as user preferences and information
`property list files for bundles. You can similarly use property lists to store private (or public) configuration data
`for your applications.
`
`A property-list file is essentially a set of structured data values. You can create and edit property lists either
`programmatically or using the Property List Editor application (located in /Developer/Applications/Utilities).
`The structure of custom property-list files is completely up to you. You can use property lists to store string,
`number, Boolean, date, and raw data values. By default, a property list stores data in a single dictionary
`structure, but you can assign additional dictionaries and arrays as values to create a more hierarchical data set.
`
`- - - - - - - - -
`
`For information about using property lists, see Property List Programming Guide and Property List
`Programming Topics for Core Foundation.
`Other Resource Files
`In addition to the resource types listed in the preceding sections, Table 1-1 lists some additional resource file
`types you might find in an application bundle.
`
`Table 1-1 Other resource types
`
`Resource
`Type
`
`Description
`
`AppleScript
`files
`
`In Mac OS X, AppleScript terminology and suite files contain information about the scriptability
`of an application. These files can use the file extensions .sdef, .scriptSuite, or
`.scriptTerminology. Because the actual AppleScript commands used to script an application are
`visible in user scripts and the Script Editor application, these resources need to be localized. For
`information on supporting AppleScript, see AppleScript Overview.
`- - - - - - - - - - - - -
`
`Help files
`
`In Mac OS X, help content typically consists of a set of HTML files created using a standard
`text-editing program and registered with the Help Viewer application. (For information on how to
`register with Help Viewer, see Apple Help Programming Guide.) It is also possible to embed
`PDF files, RTF files, HTML files or other custom documents in your bundle and open them using
`
`https://web.archive.org/web/20091122060420/http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/LoadingResources/MOS… 3/5
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0005
`
`
`
`11/27/22, 11:21 PM
`
`Mac Dev Center: Resource Programming Guide: About Resources
`an external application, such as Preview or Safari. For information on how to open files, see
`Launch Services Programming Guide.
`
`Custom
`files
`
`Your application can put custom data files or templates inside the appropriate bundle directories.
`
`Legacy Resource Files
`In earlier versions of Mac OS, resources were stored in files that used a .rsrc extension. These files were
`capable of storing multiple resources, including images, sounds, user-interface content, configuration data, and
`many others. Although support for these files is still available in Mac OS X through the Resource Manager
`routines, their use is deprecated and strongly discouraged. Old-style resource files are usually holdovers from
`Carbon applications that were ported from Mac OS 9. Even if you are just now porting such an application to
`Mac OS X, it still makes much more sense to replace your old resources with new ones. Improvements in Mac
`OS X, particularly in the area of high-resolution graphics, mean that graphics resources found in these files
`would look out of place in the current system. In addition, most of the other resource types are obsolete or can be
`easily replaced by property lists and other resource types.
`
`If you have legacy code and need to know how to access old-style resource files, see Resource Manager
`Reference.
`
`Last updated: 2009-01-06
`
`Did this document help you? Yes It's good, but... Not helpful...
`
`Shop the Apple Online Store (1-800-MY-APPLE), visit an Apple Retail Store, or find a reseller.
`
`Mailing Lists
`RSS Feeds
`
`•
`
`•
`
`Copyright © 2009 Apple Inc. All rights reserved.
`
`Terms of Use
`Privacy Policy
`
`•
`
`•
`
`- - - - -= - ~
`
`Mac Dev Center Right arrow Mac OS X Reference Library Right arrow Data Management: File
`Management Right arrow Resource Programming Guide
`[;!:
`_
`
`- - - - - - - - - - - ~
`
`https://web.archive.org/web/20091122060420/http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/LoadingResources/MOS… 4/5
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0006
`
`
`
`Mac Dev Center: Resource Programming Guide: Nib Files
`11/27/22, 11:24 PM
`The Wayback Machine - https://web.archive.org/web/20100115044038/http://developer.apple.com:80/mac/library…
`Mac OS X Reference Library
`Apple Developer
`Connection
`
`spyglass
`button
`
`Nib Files
`
`Nib files play an important role in the creation of applications in Mac OS X and iPhone OS. Nib files let you create
`and manipulate your user interfaces graphically, using the Interface Builder application, instead of programmatically.
`Because you can see the results of your changes instantly, this gives you the ability to experiment with different
`layouts and configurations very quickly. It also gives you the flexibility to change many aspects of your user
`interface later without rewriting any code.
`
`For applications built using the AppKit or UIKit frameworks, nib files take on an extra significance. Both of these
`frameworks support the use of nib files both for the visual layout of windows, views, and controls and also for the
`integration of those items with the application’s event handling code. Interface Builder works in conjunction with
`these frameworks, and with Xcode, to help you connect the controls of your user interface to the objects in your
`project that respond to those controls. This integration significantly reduces the amount of setup that is required after
`a nib file is loaded and also makes it easy to change the relationships between your code and user interface later.
`
`Because the level of support for nib files is more extensive in Cocoa applications than it is for Carbon applications,
`the following sections focus on the use of nib files with the AppKit and UIKit frameworks. Although Carbon
`applications can also use nib files, they do so in a very different way than both AppKit and UIKit, and so the use of
`nib files in Carbon applications is discussed separately in “Carbon Resources.”
`
`Note: Although you can create an Objective-C application without using nib files, doing so is very rare and not
`recommended. Depending on your application, avoiding the use of nib files can involve overriding large amounts of
`framework behavior to achieve the same results you would get using a nib file.
`Anatomy of a Nib File
`Nib files are the documents produced by the Interface Builder application. A nib file describes the visual elements of
`your application’s user interface, including windows, views, controls, and many others. It can also describe non-
`visual elements, such as the objects in your application that manage your windows and views. Most importantly, a
`nib file describes these objects exactly as they were configured in Interface Builder. At runtime, these descriptions
`are used to recreate the objects and their configuration inside your application. When you load a nib file at runtime,
`you get an exact replica of the objects that were in your Interface Builder document. The nib-loading code
`instantiates the objects and reestablishes all of the properties and connections that were present between the objects
`in Interface Builder.
`
`The following sections describe how nib files used with the AppKit and UIKit frameworks are organized, the types
`of objects found in them, and how you use those objects effectively.
`
`About Your Interface Objects
`
`Interface objects are what you add to an Interface Builder document to implement your user interface. When a nib is
`loaded at runtime, the interface objects are the objects actually instantiated by the nib-loading code. Most new
`
`https://web.archive.org/web/20100115044038/http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNib… 1/19
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0007
`
`
`
`Mac Dev Center: Resource Programming Guide: Nib Files
`11/27/22, 11:24 PM
`documents in Interface Builder have at least one interface object by default, typically a window or menu resource,
`and you add more interface objects to a nib file as part of your interface design. This is the most common type of
`object in a nib file and is typically why you create nib files in the first place.
`
`Besides representing visual objects, such as windows, views, controls, and menus, interface objects can also
`represent non-visual objects. In nearly all cases, the non-visual objects you add to a nib file are extra controller
`objects that your application uses to manage the visual objects. Although you could create these objects in your
`application, it is often more convenient to add them to a nib file and configure them there. Interface Builder provides
`a generic object that you use specifically when adding controllers and other non-visual objects to a nib file. It also
`provides the controller objects that are typically used to manage Cocoa bindings.
`
`About the File’s Owner
`
`One of the most important objects in a nib file is the File’s Owner object. Unlike interface objects, the File’s Owner
`object is a proxy object that is not created when the nib file is loaded. Instead, you create this object in your code
`and pass it to the nib-loading code. The reason this object is so important is that it is the main link between your
`application code and the contents of the nib file. More specifically, it is the controller object that is responsible for
`the contents of the nib file.
`
`In Interface Builder, you can create connections between the File’s Owner and the other interface objects in your nib
`file. When you load the nib file, the nib-loading code recreates these connections using the replacement object you
`specify. This allows your object to reference objects in the nib file and receive messages from the interface objects
`automatically.
`
`About the First Responder
`
`In Interface Builder, the First Responder is a proxy object that represents the first object in your application’s
`dynamically determined responder chain. Because the responder chain of an application cannot be determined at
`design time, the First Responder proxy acts as a stand-in target for any action messages that need to be directed at
`the application’s responder chain. Menu items commonly target the First Responder proxy. For example, the
`Minimize menu item in the Window menu hides the frontmost window in an application, not just a specific window,
`and the Copy menu item should copy the current selection, not just the selection of a single control or view. Other
`objects in your application can target the First Responder as well.
`
`When you load a nib file into memory, there is nothing you have to do to manage or replace the First Responder
`proxy object. The AppKit and UIKit frameworks automatically set and maintain the first responder based on the
`application’s current configuration.
`
`For more information about the responder chain and how it is used to dispatch events in AppKit–based applications,
`see Event Architecture inCocoa Event-Handling Guide. For information about the responder chains and handling
`actions in iPhone applications, see iPhone Application Programming Guide.
`
`About the Top-Level Objects
`
`When your program loads a nib file, Cocoa recreates the entire graph of objects you created in Interface Builder.
`This object graph includes all of the windows, views, controls, cells, menus, and custom objects found in the nib
`file. The top-level objects are the subset of these objects that do not have a parent object. The top-level objects
`typically include only the windows, menubars, and custom controller objects that you add to the nib file. (Objects
`such as File’s Owner, First Responder, and Application are proxy objects and not considered top-level objects.) In
`
`https://web.archive.org/web/20100115044038/http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNib… 2/19
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0008
`
`
`
`Mac Dev Center: Resource Programming Guide: Nib Files
`11/27/22, 11:24 PM
`Interface Builder, you can see the top-level objects in the nib document window when it is set to icon mode (see the
`circled items in Figure 2-1).
`
`Figure 2-1 Top-level objects in a nib file
`
`Top-level objects in a nib file
`
`Typically, you use outlets in the File’s Owner object to store references to the top-level objects of a nib file. If you
`do not use outlets, however, you can retrieve the top-level objects from the nib-loading routines directly. You should
`always keep a pointer to these objects somewhere because your application is responsible for releasing them when it
`is through using them. For more information about the nib object behavior at load time, see “Nib Object Retention.”
`
`About Image and Sound Resources
`
`In Interface Builder, you can associate external image and sound resources with the contents of your nib files. Some
`controls and views are able to display images or play sounds as part of their default configuration. The Interface
`Builder library provides access to the image and sound resources of your Xcode projects so that you can link your
`nib files to these resources. The nib file does not store these resources directly. Instead, it stores the name of the
`resource file so that the nib-loading code can find it later.
`
`When you load a nib file that contains references to image or sound resources, the nib-loading code also reads in
`those resource files and caches them in memory. In Mac OS X, image and sound resources are stored in named
`caches so that you can access them later if needed. In iPhone OS, only image resources are stored in named caches.
`To access images, you use the imageNamed: method of NSImage or UIImage, depending on your platform. To access
`cached sounds in Mac OS X, use the soundNamed: method of NSSound.
`Nib File Design Guidelines
`When creating your nib files, it is important to think carefully about how you intend to use the objects in that file. A
`very simple application might be able to store all of its user interface components in a single nib file, but for most
`applications, it is better to distribute components across multiple nib files. Creating smaller nib files lets you load
`only those portions of your interface that you need immediately. Smaller nib files results in better performance for
`your application. They also make it easier to debug any problems you might encounter, since there are fewer places
`to look for problems.
`
`When creating your nib files, try to keep the following guidelines in mind:
`
`•
`
`•
`
`•
`
`•
`
`Design your nib files with lazy loading in mind. Plan on loading nib files that contain only those objects you
`need right away.
`
`In the main nib file for a Mac OS X application, consider storing only the application menu bar and an
`optional application delegate object in the nib file. Avoid including any windows or user-interface elements
`that will not be used until after the application has launched. Instead, place those resources in separate nib
`files and load them as needed after launch.
`
`Store repeated user-interface components (such as document windows) in separate nib files.
`
`For a window or menu that is used only occasionally, store it in a separate nib file. By storing it in a separate
`nib file, you load the resource into memory only if it is actually used.
`
`https://web.archive.org/web/20100115044038/http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNib… 3/19
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0009
`
`
`
`Mac Dev Center: Resource Programming Guide: Nib Files
`11/27/22, 11:24 PM
`Make the File’s Owner the single point-of-contact for anything outside of the nib file; see “Accessing the
`•
`Contents of a Nib File.”
`The Nib Object Life Cycle
`When a nib file is loaded into memory, the nib-loading code takes several steps to that ensure the objects in the nib
`file are created and initialized properly. Understanding these steps can help you write better controller code to
`manage your user interfaces.
`
`The Object Loading Process
`
`When you use the methods of NSNib or NSBundle to load and instantiate the objects in a nib file, the underlying nib-
`loading code does the following:
`
`1. It loads the contents of the nib file and any referenced resource files into memory:
`
`0
`
`0
`
`0
`
`The raw data for the entire nib object graph is loaded into memory but is not unarchived.
`
`Any custom image resources associated with the nib file are loaded and added to the Cocoa image
`cache; see “About Image and Sound Resources.”
`
`Any custom sound resources associated with the nib file are loaded and added to the Cocoa sound
`cache; see “About Image and Sound Resources.”
`
`2. It unarchives the nib object graph data and instantiates the objects. How it initializes each new object depends
`on the type of the object and how it was encoded in the archive by Interface Builder. The nib-loading code
`uses the following rules (in order) to determine which initialization method to use.
`
`1. Standard Interface Builder objects (and custom subclasses of those objects) receive an initWithCoder:
`message.
`
`In Mac OS X, the list of standard objects includes the views, cells, menus, and view controllers that are
`provided by the system and available in the default Interface Builder library. It also includes any third-
`party objects that were added to the Interface Builder library using a custom plug-in. Even if you
`change the class of such an object, Interface Builder encodes the standard object into the nib file and
`then tells the archiver to swap in your custom class when the object is unarchived.
`
`In iPhone OS, any object that conforms to the NSCoding protocol is initialized using the initWithCoder:
`method. This includes all subclasses of UIView and UIViewController whether they are part of the
`default Interface Builder library or custom classes you define.
`
`2. Custom views in Mac OS X receive an initWithFrame: message.
`
`Custom views are subclasses of NSView for which Interface Builder does not have an available
`implementation. Typically, these are views that you define in your application and use to provide
`custom visual content. Custom views do not include standard system views (like NSSlider) that are part
`of the default Interface Builder library or part of an integrated third-party plug-in.
`
`When it encounters a custom view, Interface Builder encodes a special NSCustomView object into your
`nib file. The custom view object includes the information it needs to build the real view subclass you
`
`https://web.archive.org/web/20100115044038/http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNib… 4/19
`
`IPR2022-00031 / IPR2022-00032 / IPR2022-00033 / PGR2022-00006
`
`Page 0010
`
`
`
`Mac Dev Center: Resource Programming Guide: Nib Files
`11/27/22, 11:24 PM
`specified. At load time, the NSCustomView object sends an alloc and initWithFrame: message to the real
`view class and then swaps the resulting view object in for itself. The net effect is that the real view
`object handles subsequent interactions during the nib-loading process.
`
`Custom views in iPhone OS do not use the initWithFrame: method for initialization.
`
`3. Custom objects other than those described in the preceding steps receive an init message.
`
`3. It reestablishes all connections (actions, outlets, and bindings) between objects in the nib file. This includes
`connections to File’s Owner and other proxy objects. The approach for establishing connections differs
`depending on the platform:
`
`0
`
`Outlet connections
`
`•
`
`In Mac OS X, the nib-loading code tries to reconnect outlets using the object’s own methods first.
`For each outlet, Cocoa looks for a method of the form setOutletName: and calls it if such a
`method is present. If it cannot find such a method, Cocoa searches the object for an instance
`variable with the corresponding outlet name and tries to set the value directly. If the instance
`variable cannot be found, no connection is created.
`
`In Mac OS X v10.5 and later, setting an outlet also generates a key-value observing (KVO)
`notification for any registered obse