Common packages: documents which are folders in drag

Packages are one of the Finder’s grand illusions. They’re actually folders containing more folders and files, which are presented to the user as if they were actually a single item, just like a file. You’ll use them daily – RTFD documents, Photos Libraries, and many more.

They’re not as formally-structured as bundles, the term that Apple uses for the folders which make apps and some other key components of macOS. Look inside an app and you’ll see a single folder named Contents, within which are more folders with fairly fixed names, such as _CodeSignature and MacOS, and a crucial file Info.plist. Rename a folder my.app, for example, and it will automatically be assigned the icon to indicate that it’s a broken app, even though the Finder still thinks of it as an app.

You can turn any folder into a package simply by adding the appropriate extension to its name. Create a new folder named this, and add .rtfd to the name: the Finder will think that it’s a Rich Text Document with Attachments package, and display it with the default RTFD icon. Double-click to open it, though, and you’ll be told that it can’t be opened, because it doesn’t contain any component files. A new and empty RTFD package normally consists of a minimum of one RTF file; if your bogus RTFD package doesn’t have that, apps will complain.

Simply giving a folder an extension doesn’t turn it into a package. The extension has to be one of those recognised by macOS to result in that transformation. Test this by creating a new folder and giving it a made-up extension such as .xyza, and it will still look like a normal folder. The association between package extensions and types is managed by Launch Services; although you can sometimes fix problems in Launch Services, in general there isn’t a great deal that you can do.

Here’s a breakdown of some of the most commonly-encountered packages, listed by extension:

.band
A GarageBand document, consisting of the file projectData, and a folder named Media, containing audio files, and other folders.

.bentodb
A Bento database, sadly now defunct. Contains three folders, Contents, Logs, and Preferences, with further files and folders within each.

.fcpbundle
A Final Cut Pro project, which has a complex internal structure, with a folder for each of the clips in the movie. Within those, the folder Original Media contains the original content being used for that clip.

.graffle
An OmniGraffle document, which contains a data.plist containing the skeleton of the document, embedded images, and a QuickLook folder. Not all OmniGraffle documents are packages, though: some may just be a single file.

.help
A macOS Help book containing a wrapper folder named Contents, within which there is an Info.plist property list, and a folder named Resources, which contains the structured HTML and other files for the book.

.imovielibrary
An iMovie project, which has a complex internal structure, with a folder for each of the clips in the movie. Within those, the folder Original Media contains the original content being used for that clip.

.key
A Keynote presentation. This contains preview JPEG images and a Zipped index, and folders named Data and Metadata. Embedded images, movies, and other content are in the Data folder. Older versions of the format are quite different, though.

.migratedphotolibrary
A migrated iPhoto or Aperture library, with complex internal structure. Master images are stored in the Masters folder.

.numbers
A Numbers spreadsheet, containing a compressed XML index and document thumbnail, and two folders, Contents and QuickLook. Some Numbers documents are simple documents rather than packages.

.pages
A Pages document, containing a compressed XML index and two folders, Contents and QuickLook.

.photoslibrary
A Photos library, with complex internal structure. Master images are stored in the Masters folder. Most of the folders contain XML and other data which is used to contain the structure of the library and the information with it, and must not be tampered with.

.playground, .xcplaygroundpage, etc.
Swift Playgrounds. These can contain a Contents.swift source code file, .xcworkspace packages, and others.

.rtfd
Rich Text Document with attachments (‘Rich Text Format Directory’), which allow it to cope with richer content than plain RTF.
Contains at least one RTF file, with a variable number of images and other content. Usually has a folder named Contents, within which there may be a file named PkgInfo which contains the four-character document type (RTFD) and the app signature.

.scptd
A compiled AppleScript. These have quite a complex structure, inside a single wrapper folder named Contents. There is an Info.plist property list, a description.rtfd (which is another RTFD package, within the package), and script files with the extension .scpt.

.workflow
An Automator Workflow, which contains a single folder named Contents, within which are two files document.wflow, the workflow itself, and Info.plist which provides information about it to Automator.

.xcodeproj
An Xcode project. As a minimum, this contains a .pbxproj file.

Bundles with more formal structures include .app, .pkg, .dpkg, and several variants of .plugin. Further details are in this article.

macOS, iOS, etc., are currently the only major operating systems which support packages and bundles, as distinct from plain folders/directories. Although apps which can read RTFD, for example, on other platforms will work with Mac packages, they are seen simply as being directories containing the RTFD content, rather than discrete packages.

The Finder and Quick Look handle packages as if they were single-file documents, and produce properly integrated previews. You can, of course, always look inside a package: Control-click, or right-click, or two-finger-tap, to bring up the Finder’s contextual menu, and use the Show Package Contents command.