Apps, frameworks and other items come in bundles, structured hierarchies of folders and files that look like a single file in the Finder. This article explains what bundles are and shows how they are structured.

Bundles came to Mac OS X from its NeXTSTEP parent, not Classic Mac OS. The latter assembled its apps from many resources stored in the app’s resource fork. NeXTSTEP and Mac OS X instead built their apps from component files arranged in a series of directories. Those bundles gathered together all the files required for apps and similar items, into what was then presented to the user as a single item. Modern app bundles are descended from ‘new-style’ bundles introduced in Mac OS X, which had a minimum requirement of a top-level folder named Contents, and inside that a property list named Info.plist.

Bundles and packages

When a folder has a name with an extension for a standard bundle type, such as .app, .bundle, .plugin or .kext, the Finder will display and treat it as if it were a file, also offering to Show Package Contents in its contextual menu. For historical reasons, bundles with the extension .framework aren’t treated as bundles, but are displayed and navigated as if they were still folders.

Although bundles have similarities with packages, Apple draws a clear distinction between them, even if the Finder doesn’t. Directory-based documents and similar items that are used to contain multiple files for Rich Text Format Directory (RTFD) and other documents don’t conform to the rules for bundles, and should be referred to as packages to avoid confusion. Look inside an RTFD package, for example, and you’ll see the structure:

• Contents, a directory containing a PkgInfo file
• files containing graphics to be included within the documents
• TXT.rtf, a Rich Text Format file containing the styled text.

which has some common features, but is structured differently and lacks both an Info.plist file and executable code.

Apps and frameworks

The fundamental requirements for an app or related bundle, including those for app extensions or appexes, are:

• The whole bundle’s contents are within a single top-level folder named Contents.
• Within Contents is an Info.plist property list containing information and settings for the bundle.
• There’s executable code, normally in the form of a Mach-O binary inside the MacOS folder.
• For historical and compatibility reasons, there’s a PkgInfo file containing a Classic Mac OS type and creator code for the bundle, e.g. APPL and ???? for an app.

However, frameworks have a different and more complex structure, lacking a Contents folder, providing at least one version of the framework, and burying the Info.plist file deeper in the hierarchy. This is shown in full later.

App bundles can contain frameworks and other app bundles, as can framework bundles. In the worst case you may need to dive deep into a series of folder hierarchies to reach your goal.

Info.plist

The information property list Info.plist contains key-value pairs in XML format, for attributes such as:

• bundle name (CFBundleName),
• name of bundle executable (CFBundleExecutable),
• version (CFBundleShortVersionString),
• document types handled by the app (CFBundleDocumentTypes),
• app identifier (CFBundleIdentifier),
• other metadata.

Because of the importance of its contents, code signatures protect the Info.plist from being changed in any way.

App bundle

In addition to the minimum requirements of an Info.plist, executable code, and PkgInfo file inside its Contents folder, apps almost invariably contain several additional folders, among them:

• Resources is universal, and contains any of a rich range of images, localised versions of menu and other text contents, the app icon and any for custom document types, storyboards for GUI elements, Help books, and more.
• PlugIns is now common, to contain appexes in particular.
• Library, containing one or more sub-folders with QuickLook and Spotlight support for custom document types, any login items or property lists for LaunchServices, and other support and extensions for the main app.
• Apps obtained through the App Store should contain a _MASReceipt folder with the store receipt inside it.
• Signed apps will have a _CodeSignature folder containing the CodeResources file with signature data.
• Notarized apps may have a notarization ticket in a CodeResources file, but that isn’t required for notarization to work.
• Some apps may have an embedded.provisionprofile file containing their provisioning profile.
• Other folders, such as Frameworks for nested framework bundles.

This layout is shown below, with the essentials in light red.

Framework bundle

In comparison, framework bundles are deeper, lack a top-level Contents folder, contain at least one version of the framework (although two or more are now exceptional), and come with symbolic links. This is shown below, again with the essentials in light red.

Three symlinks merit explanation:

• Versions/Current links to A, the current (and only) version of the framework.
• a symlink with the same name as the framework’s code is at the top level of the bundle, alongside the Versions folder. That links through the Current symlink, giving the path Current/A/.
• a symlink named Resources is also at the top level of the bundle, alongside the Versions folder. That too links through the Current symlink, giving the path Current/A/Resources.

Thus paths to the Info.plist file include Resources ➜ Info.plist via the top-level Resources symlink, Versions/Current ➜ Resources via the Current symlink, and Versions/A/Resources without using any symlinks. This demonstrates how confusing this layout can appear in the Finder.

Frameworks commonly include other nested frameworks, appexes in their PlugIns folder, and a diverse range of other resources including localisations in the Resources folder.

Conclusions

• Bundles are formal structures of folders and files used for apps and their relatives, and for frameworks. Packages used for RTFD and other documents have different structural requirements.
• App bundles have a top-level Contents folder, inside which is an Info.plist property file, and executable code inside a MacOS folder.
• Framework bundles don't have a Contents folder, but contain versions of the framework, normally only one named A. They use important symlinks to provide standard access paths to their contents, and their Info.plist file is inside their Resources folder.
• Info.plist files and other contents are protected by code signatures and can't be modified without breaking the signature. However, they contain valuable information about the app or framework.
• Building bundles by hand is prone to error, causing bugs. When possible, leave it to Xcode.

Reference

Apple's instructions for developers.

英国金融时报FT（Financial Times）有一篇关于圣诞餐通货膨胀（Christmas Dinner […]

我好久都没睡好了，值得记录一下。

从半年前手术开始，接连着出差、二次手术、年前的忙、过年的烦、年后的忙，一直到前几天的连续熬夜和通宵工作，我真的很长一段时间里都没有这么深的睡眠了。

前几天为了最后出方案，熬了两个通宵，公司内部的野心和追求都令我感到很失望，复杂的情绪交融在一起，非常难过。但最后还是用我的方式，引导大家选择了我想要的那个。尽管看上去我在力推另一个方案，但是人呐，对于自己没有概念的事情，靠嘴说是没有用的，对于他们来说，打出高中低来，选中间的，是他们能理解的方式。更好的那个，谈不上多超前，仅仅只是不值得而已。算了，以后总会有机会。

昨晚九点半，终于把所有设计文件、模型和工艺文件、USDZ 文件分别发送到了各个下一环节手中。接下来，不用我熬夜，轮到我监督他们干活交东西了。算是阶段性的胜利吧。

心情一好，我就看了半部《无间道3》。

前段时间跟筱烨一起看《无限超越班》，心里的戏瘾就痒痒，但是现在没有机会上舞台了，就上 Netflix 找了无间道三部曲开始看。之前分两周陆续看完了前两部，昨晚难得松懈一下，一口气看了半部三。

为了帮我补熬夜的气血，筱烨给我买了两次西洋参。第一盒前几天喝完了，前天又到了一盒，昨晚睡前温热地喝了一杯。

大概是工作的疲惫 + 阶段胜利的松懈 + 看电影的愉悦 + 西洋参补的气，一起让我睡了一顿好觉吧？