The Finder, and what we think of as files and folders, are not just a big illusion. They are an illusion at many levels, which structures the millions of files in your Mac’s storage into something that makes reasonable sense to humble humans. But there’s more than just files and folders – Macs have bundles, and packages, and sort-of-folders which pretend to be libraries, and all sorts of other oddities. This article helps you make better sense of them.

Files and folders

The basic logical unit in storage is actually the file, an often disparate series of chunks of data which are brought together in the file system as a coherent whole. The folder is the first layer of illusion: effectively another file which lists the files (and folders) which it ‘contains’. When you move a file from one folder to another, it is merely removed from the contents list of the source folder, and added to that of the destination.

Packages

The next layer of illusion is the package, a folder which is masquerading as a file. There are all sorts of different packages which you’ll encounter on a Mac, from Installer packages (the most specific type), to document packages such as Photos Libraries, and even apps. In its most general use, the term package refers to a folder which has been designated to the Finder (through its extension) to be treated as if it were a single file.

Packages can have almost any structure, although that doesn’t mean that they’ll always work. Take any folder on your Mac and append the extension .pkg to it, and the Finder will then pretend that it’s an Installer package. Try opening it with the Installer app and you’ll discover that it doesn’t work as one, but as far as the Finder’s trickery goes, it’s an Installer package. Remove that extension and it reverts to being a normal folder.

If you’re not sure whether what looks like a file is actually a package, select it in the Finder, and use the contextual menu to look if it can be opened. If the Finder reckons its a package, then the second or third item in that menu will read Show Package Contents. And that is the best way to look at what is inside.

Opening a range of different packages shows how varied their internal structures can be. A Photos Library opens to reveal a series of different folders, including a database, Masters (containing the master images), and Thumbnails (for thumbnail images, of course). Each app which uses packages expects different internal structures, most of which are a real pain to deal with manually. If your Photos Library gets damaged, it is almost impossible to repair it yourself, and even recovering the master images is fraught – Photos usually separates the metadata from those images.

Bundles

Some packages have more formally-defined structures, and are known as bundles. These normally contain executable code, and can be apps, frameworks, or plug-ins. Frameworks, although they have a bundle structure, may still appear in the Finder as regular folders. Not all executable code is bundled up: command tools, shell scripts and most libraries are usually single files.

Before the days of code signatures, you could, if you were very skilful or lucky, open a bundle and make changes to it, and it would still work, much of the time. Although the Finder still lets you Show Package Contents on a bundle, even an app, doing much beyond having a quick peek risks damaging the app to the point where its code signature is invalidated. Then Sierra’s (and El Capitan’s) Gatekeeper will not let you open the app, and you’ll have to trash that copy and reinstall it.

That said, I often look inside a new app, specifically to see what its developers have left in the Resources folder. You can find useful PDF documentation there, which would normally only be accessible when the app is running. You can then make a copy to open at your leisure, but never move anything from an app bundle because of the risk of breaking its signature.

Apps have a fairly regular bundle structure. Inside the top-level .app bundle (folder) is just one folder, named Contents. Inside that are at least three folders and two files: the _CodeSignature folder contains those all-important signatures to satisfy Gatekeeper; the MacOS folder contains the app’s main code, and the Resources folder contains most of the supporting material, including the app’s icons, interface components, help files (often themselves help bundles), and more. The two essential files are a tiny PkgInfo, and the app’s main information listing, Info.plist.

Sometimes it can be helpful to open a bundle up to make it easier to access. At the moment I am studying help bundles, and have a little collection kept well away from the apps that they came from. Instead of going through the Finder’s tedious Show Package Contents all the time, I have simply removed the .help extension, and the Finder treats them like normal folders.

More info

You can also manually build your own packages and bundles, if you know how to structure them properly, and can write any Info.plist file which is required. There’s no reason that you can’t make your own help or even app bundles, although these days you’ll need to sign apps and anything else which contains executable code. Apple’s detailed documentation about bundles also contains links to other reference material on most other types of package. For once, it’s also quite up to date, although you’ll need to read up on code signing if you want the whole package.