Bundles and Packages in Mac OS X

When Apple moved to Mac OS X, it wanted to avoid the use of resource forks while still retaining the ability to make complex items appear as single icons. Instead of creating a new container technology, Apple simply modified an existing file system container, the common folder. A bundle is nothing more than a normal folder that is used to group related resources in one location. Packages take this concept a step further: A bundle with the bundle file attribute set appears as single opaque item in the Finder and is known as a package.

This package-based approach allows software developers to easily organize all the resources needed for a complicated product into a single package, while simultaneously making it harder for normal users to interfere with the resources. Where a user sees only a single icon in the Finder representing an application, in reality it is a folder potentially filled with thousands of resources. If you encounter a folder with a name that appears to be a file extension, you are probably looking at a bundle. For example, /System/Library/Frameworks/Cocoa.framework/ is a bundle that contains multiple items related to that software, but it appears as a normal folder. The contents of a package, on the other hand, are revealed only when you right-click (or Control-click) the package and choose Show Package Contents from the shortcut menu.

From a deployment perspective, the use of bundles and packages in Mac OS X presents another dilemma. On the one hand, bundles and packages simplify deployment because otherwise complex items can be managed as single items. Thus, you can copy an entire application and all its accompanying resources by simply copying a single icon. On the other hand, bundles and packages are treated as normal folders by third-party systems and transfer mechanisms, which in many cases means that the bundle-bit attribute will be stripped away, and the once-opaque package will appear as a folder in the Finder. This will prevent the package from opening as intended. Further, it confuses users because they will see a folder instead of an application icon, which can also lead to accidental partial copies if they don’t know to copy all the items.

Using File Containers

To work around these several show-stopping issues that prevent you from successfully using many third-party tools to store or transfer items with Mac-specific file elements, you can place items that you intend to deploy inside file containers. Containers are special files that can encapsulate other files, folders, or even entire file systems. From the outside, a container file appears as a simple monolithic data file that is easily stored and transferred via any method. The contents of the container file, however, can be as varied and complicated as your deployment requires. Container file formats can have other features that make them extremely attractive for deployment use. For example, most container file formats use some form of data compression. Throughout this article you will be introduced to other benefits of using file containers for deployment.

Mac OS X has two built-in file container technologies that allow you to safely deploy items containing file attributes, resource forks, bundles, and packages:

- Archive file This container file type allows you to store individual or multiple files and folders in a single compressed monolithic file.

- Disk image This container file type allows you to store the contents of an entire file system in a single monolithic file. There are many disk image variations and options.

The container files created by these technologies can be safely stored and transferred using nearly any deployment mechanism.

Choosing the Format for Deploying Items

With the archive and disk image container formats, you have a total of three possible formats for deploying items: traditional drag and drop, archived files, and disk images. Consider the following pros and cons before choosing a deployment format:

Drag-and-Drop Deployment

Pros:

- Doesn’t require any encoding or decoding.

- Doesn’t require any special tools on any system. - Simple for inexperienced users.

Cons:

- Mac OS X file elements may not be preserved if storing or transporting using thirdparty mechanisms.

- Multiple items may not be transferred properly when using certain third-party mechanisms, as related items may become separated and lost during the transfer.

- No default file checksums to verify content.

- No default compression, thus no storage or bandwidth savings.

- No default encryption to secure content.