A way of installing applications designed by Next introduced by Apple into MacOS 9. The application binaries, help files, localisation files, non-system libraries and resources are all contained within a single folder. This folder is presented to the user as the application icon. Installing an application just means dragging over the icon from the CD to the applications folder. Running the application is acheived by double-clicking the icon.

From an HCI point of view, a bundle is fantastic as it appears that the application is a single object. From the user point of view, there is no opaque installation process to follow and no strange files scattered all over the system

The bundle will be the preferred installation method for applications running under MacOSX

In the CPAN module system for Perl, a bundle is a pseudo-module that groups a collection of actual modules into a single entity for installation purposes. For instance, installing Bundle::LWP causes all the LWP modules to be installed in a correct order.

In the beginning there was the resource fork. Macintosh applications, extensions, libraries etc. could store all kinds of data such as window layouts, pictures, sounds, strings inside their resource fork, avoiding a confusing mass of files. Data such as the creator and the type of files was stored in the filesystem There was a convenient API for accessing and manipulating this data. All was well in the kingdom of Apple.

And then there was chaos

But not all filesystems have the concept of having separate forks. When macintosh files travelled via filesystems like FAT32 they would lose their resource fork and more often than not become useless. When people upload and download files, they travel as a simple stream of bytes. Protocols such as HTTP don't care about resource forks and don't know about the Macintosh file and creator types. Even data fork only Macintosh files would arrive devoid of file type, leaving the user to guess what kind of file it was. And so it came to be that all travelling macintosh files had to disguise themselves using encodings such as Macbinary or binhex, that they may reach their destination safely.

From Mac OS X's BSD roots came UFS, a filesystem with no concept of forks. Apple came up with what is basically a kludge to allow files with resource forks to survive and work properly on such disks. It was clear that there needed to be some safer way of putting applications together.

Apple's answer to this problem is the bundle. If you look at it from a terminal window is just a folder. A bundle is capable of containing several types of objects. These can be applications, frameworks (basically a shared library) or loadable code. A kernel extension for example is a special type of loadable code, as are Contextual Menu Item plugins. All though follow the same basic construction.

Anatomy of a bundle

At the very least the bundle's folder will contain another folder, called Contents. It may optionally contain folders called Plug-ins, SharedFrameworks and SharedSupport.

In the Contents folder there are a number of special folders :

  • Folders containing platform specific executables or data. These folders must have names according to the platform they are destined for, right now there is a choice of MacOS or MacOSClassic. If you try to run or load a bundle, the system will look in the appropriate platform folder for the executable. It should be noted that the classic Mac OS does not support bundles (it has a similar concept known as a package). For this a reason when applicable an alias to the classic executable is placed in the bundle's folder.
  • Resources: This contains items such as pictures, sounds, window layouts or strings files. It can contain subfolders with names like English.lproj or French.lproj. When you ask for a given item, for example a window layout (usually stored as a nib), it will check the subfolders in an order determined by the user's language preferences. Thus a single application or library can contain many different languages, or even variants of a language, for example American versus British English.
  • Frameworks: Contains, as you might have guessed, frameworks that the application uses. There is a slight difference between this folder and the SharedFrameworks folder mentioned earlier. If a framework is in the Frameworks folder, then that version of the framework will always be used, even if the system has a more recent version. If it is in SharedFrameworks however, a more recent version can be used.
An important file, named Info.plist must reside inside the Contents folder. It's an xml file that defines some of the key properties of the bundle at hand, for example the name of the file containing executable code, version information to be shown in the Get Info window or types of files that the application can open. Specific types of bundles may have additional properties defined. A CFPlugin, which is a special kind of loadable code bundle has information about the types of Factories the plugin implements. A bundle usually also contains a file called PkgInfo that contains creator and type codes for the bundle. This information is also in Info.plist, however it is accessed sufficiently frequently that it made sense to have a copy of the information available separately.

Advantages of using bundles

The main advantage of a bundle is that is an entirely self-contained item. There are no separate files for a user to forget, install, or rename by accident. You can move a bundled application by dragging and dropping a single item. A bundle is also able to reside on filesystems without separate resource forks. You could also have bundles containing executables for several different processor architectures.

You might be wondering how the OS knows if a given folder is a bundle or not. I haven't been able to find any hard info on this, but through a bit of experimentation I've noticed that a bundle must have an extension and an Info.plist file. Additionally applications and frameworks must use the extensions .app and .framework. Personally I find this encoding of file metadata in file names a big step back, but Apple doesn't seem to care about that anymore.

Bun"dle (?), n. [OE. bundel, AS. byndel; akin to D. bondel, bundel, G. bundel, dim. of bund bundle, fr. the root of E. bind. See Bind.]

A number of things bound together, as by a cord or envelope, into a mass or package convenient for handling or conveyance; a loose package; a roll; as, a bundle of straw or of paper; a bundle of old clothes.

The fable of the rods, which, when united in a bundle, no strength could bend. Goldsmith.

Bundle pillar Arch., a column or pier, with others of small dimensions attached to it. Weale.

 

© Webster 1913.


Bun"dle, v. t. [imp. & p. p.pos> [Bundled[ (); p. pr. & vb.n. Bundling ().]

1.

To tie or bind in a bundle or roll.

2.

To send off abruptly or without ceremony.

They unmercifully bundled me and my gallant second into our own hackney coach. T. Hook.

To bundle off, to send off in a hurry, or without ceremony. -- To bundle one's self up, to wrap one's self up warmly or cumbrously.

 

© Webster 1913.


Bun"dle, v. i.

1.

To prepare for departure; to set off in a hurry or without ceremony.

2.

To sleep on the same bed without undressing; -- applied to the custom of a man and woman, especially lovers, thus sleeping.

Bartlett.

Van Corlear stopped occasionally in the villages to eat pumpkin pies, dance at country frolics, and bundle with the Yankee lasses. W. Irving.

 

© Webster 1913.

Log in or register to write something here or to contact authors.