In NEXTSTEP, OPENSTEP, their lineal descendants Mac OS X, iOS, and in GNUstep, a bundle is a directory that allows related resources such as an application's executable and its graphics to be grouped together, appearing as a single file to the user.
Examples include applications, frameworks, and plugins. They are accessed with the NSBundle class in Cocoa, NEXTSTEP and GNUstep's Foundation frameworks, and with CFBundle in Core Foundation.
A bundle usually contains one file representing executable code, and files that represent resources such as nibs, images, sounds, and other media. On some other systems, such as Microsoft Windows, these resources are usually included directly in the executable file itself at compile time. On older Macintoshes, a similar technique is used, where additional metadata can be added to a file's resource fork. The Finder treats bundles, which can also be referred to as packages, as opaque files with no underlying structure.
The Uniform Type Identifier (UTI) for an Apple bundle is com.apple.bundle.[1]
Similar in concept are the application directories used in RISC OS and on the ROX Desktop, and the RUNZ bundles in Super OS.
Contents |
Application bundles are directory hierarchies, with the top-level directory having a name that ends with a .app extension. In an application bundle, the first directory in the bundle underneath the top-level directory is usually named Contents. Within Contents there is usually another directory (called MacOS on Macs, or using the application's name on GNUstep), which contains the application's executable code. Within the Contents folder there is usually also a directory called Resources, which contains the resources of the application.
Among other things, the Resources folder contains localized versions of the application's nib files.
Other common subdirectories include Plugins, Frameworks, and Shared Frameworks. The Frameworks directory contains frameworks used by the application, and are used even if another version of the framework exists on the system. The Shared Frameworks directory contains frameworks that can be used both by the application that contains them, and other applications; they are used only if a newer version does not exist elsewhere on the system. Plugins contains extensible code used by the application.
Mac OS X frameworks are also stored as bundles; the top-level directory of a framework bundle has a name that is the name of the framework followed by the extension .framework. In the top-level directory is a Versions directory, with subdirectories for one or more versions of the framework, each subdirectory containing the dynamic library code for the framework, in a file whose name is the same as the name of the framework, possibly with a Headers folder containing header files for the framework, and other subfolders such as Resources. The Versions directory also contains a symbolic link Current to the directory for the current version of the framework. In the top-level directory are symbolic links to the contents of Versions/Current.[2].
Loadable bundles are bundles which contain code that can be loaded at runtime.[3] Loadable bundles usually have the extension .bundle and are most often used as plug-ins. An example of an application that traditionally supports bundles is Apple Mail.[4][5] On Mac OS X there is a way to load bundles even into applications that don't support them allowing for third party hacks for popular applications such as Safari.[6]
There are many third-party Mac OS X applications which utilize their own custom bundle format (e.g. CandyBar's .iContainer bundles).
An .lproj file is a bundle that contains localization files for Mac OS X software. It typically contains the .nib files for a given language along with string files and images if need be (for example, ReadMe or license files). These localized files are used by install makers to customize install packages. They are also included into an application bundle.