Disk images, files that contain the contents of a physical storage medium, go back long before the first Mac. Among other tasks, they were originally used to contain representations of floppy disks for replication in manufacture.

Today disk images are at the heart of macOS, and widely used by third-parties. They’re an essential part of macOS installers, home to Recovery mode, and the basis for cryptexes. They’ve been used to burn and replicate optical disks, to archive disk contents, extensively for network backups, and for the distribution of software.

Classic Mac OS

In Classic Mac OS there were two utilities that worked with different formats: Disk Copy used replicas later in DC42 format, after Disk Copy version 4.2, while compressed formats known as DART were handled by the Disk Archive/Retrieval Tool, hence their name.

Mac OS 9 brought Disk Copy 6.0 with added support for the New Disk Image Format (NDIF), which supported resource forks, and ended with its last release version 6.3.3. This also supported read-only Rdxx formats.

By this time, variants of formats had become complex. Here, Disk Copy is configured to create a read-only compressed .img file containing the contents of a standard 1.4 MB floppy disk. In the upper window, it has completed validating the checksum on a self-mounting .smi disk image that’s part of a DiskSet. These could also be signed, using certificates issued not by Apple but by DigiSign.

Here’s Disk Copy saving an image of a hard disk using a similar read-only compressed format, this time to accommodate 1.5 GB.

Mac OS X

The release of Mac OS X 10.1 Puma in 2001 brought Apple’s new Universal Disk Image Format (UDIF), used in DMG disk images, which only had a single fork as its resource fork was embedded in the data fork. Although pre-release versions of Disk Copy 6.4 and 6.5 were available with UDIF support for Mac OS 9, neither was ever released, leaving Classic Mac OS without access to UDIF images. Its support for compression options in Apple Data Compression (ADC) unified the two disk image types, and extended support for images larger than a floppy disk. This new format enabled disk images to represent whole storage devices, complete with a partition map and disk-based drivers.

Tools provided in Mac OS X for working with disk images include Disk Utility and the command tool hdiutil.

On 21 January 2002, the first version of DropDMG, a third-party substitute for creating disk images, was released by C-Command Software. This quickly enabled developers to create disk images with artwork, licences and other features that weren’t accessible from the tools bundled in Mac OS X. DropDMG has flourished over the last 23 years, and remains popular today.

DropDMG’s options for creating a new disk image far exceed those in Disk Utility. Particularly helpful are the compatible version hints shown on various options, to remind you of which file systems are available in different macOS versions, and which types of disk image container are supported. DropDMG will even convert old NDIF disk images last used in Mac OS 9 to more modern formats. It will also change the password of an encrypted disk image from a menu command.

In Mac OS X 10.2 (2002), UDIF and most other supported formats were served from a kernel extension without requiring a helper process. The following year, 10.3 Panther started using a faceless utility DiskImageMounter to mount disk images. Apple then dropped support for embedded resource forks in disk images in Mac OS X 10.4.7, and newly created disk images became less compatible with older Mac OS versions.

Sparse bundles

Until Mac OS X 10.5 Leopard in 2007, all disk images had used single-file formats, although some could be segmented across file sets. Leopard introduced the sparse bundle with its folder of smaller band files containing data. These enabled the image to grow and shrink in size, and became popular means of storing mountable Mac file systems on servers using different file systems.

This is another third-party tool that improved access to disk images from the GUI, DMG Packager, seen in 2009. Unlike DropDMG, this appears to have vanished without trace.

In 2011, with the release of Mac OS X 10.7 Lion, Apple removed more support for old disk image formats. DiskImageMounter no longer opened NDIF .img, .smi self-mounting, .dc42 and .dart compressed formats, although the hdiutil command tool still retained some access to them.

Disk Utility, seen here in 2011, has provided basic access to many disk image formats, but these are only a small selection of options available in the hdiutil command tool, or in DropDMG.

This shows the complex set of options available when creating a new disk image in Disk Utility in OS X 10.10 Yosemite, before the advent of APFS.

Support for compression was enhanced in OS X 10.11 El Capitan with the addition of lzfse in a new ULFO format, and macOS 10.15 Catalina added lzma in ULMO. In both cases, these new formats aren’t accessible in older versions of macOS.

APFS support

The arrival of a pre-release version of the new APFS file system in macOS 10.12 Sierra brought its support in disk images, although only for experimental purposes, and Apple cautioned users to ensure their contents were well backed up.

In addition to adding the more efficient ULMO compressed format, macOS 10.15 Catalina is the last to support many Classic Mac OS disk image formats, including those from DiskCopy42, DART and NDIF from Disk Copy 6.x. Support for AppleSingle and MacBinary encodings, and dual-fork file support, were also removed in macOS 11.0 Big Sur in 2020.

This ‘warning’ alert from 2020 illustrates one of the longstanding issues with disk images. Although integrity checking of disk images using checksums has been valuable, when an error is found there’s no possibility of repair or recovery as the image can’t be ‘attached’, so its file system can’t be mounted.

macOS 12 Monterey in 2021 brought multiple deprecations of older formats, including UDBZ using bzip2 compression, segmented UDIF images, and embedded resources. It’s also thought to be the first version of macOS in which UDIF read/write images (UDRW) have been stored in APFS sparse file format, although Apple has nowhere mentioned that. This has transformed what had previously been space-inefficient disk images that retained empty storage into a format that can prove almost as efficient as sparse bundles. This results from the Trim on mounting HFS+ and APFS file systems within the image freeing unused space, enabling that to be saved in the sparse file format.

Disk images have never been glamorous, but have remained at the heart of every Mac.

References

man hdiutil
Introduction
Tools
How read-write disk images have gone sparse
Performance
Bands, Compaction and Space Efficiency

Appendix: Disk image formats

Supported

• UDRW – UDIF read/write
• UDRO – UDIF read-only
• UDCO – UDIF ADC-compressed
• UDZO – UDIF zlib-compressed
• ULFO – UDIF lzfse-compressed (OS X 10.11)
• ULMO – UDIF lzma-compressed (macOS 10.15)
• UDTO – DVD/CD-R master for export
• UDSP – sparse image, grows with content
• UDSB – sparse bundle, grows with content, bundle-backed, Mac OS X 10.5
• UFBI – UDIF entire image with MD5 checksum.

Unsupported

• DC42 – Disk Copy 4.2 (Classic)
• DART – compressed, for Disk Archive/Retrieval Tool (Classic)
• Rdxx – read-only Disk Copy 6.0 formats
• NDIF – Disk Copy 6.0, including IMG and self-mounting SMI
• IDME – ‘Internet enabled’, on downloading post-processed to automatically copy visible contents into a folder, then move the image to the Trash. Now deemed highly insecure.
• UDBZ – UDIF bzip2-compressed image (deprecated).

With Mac OS X came a new tool for installing and updating the system, quite different from what had been used in Classic Mac OS. The Mac OS X Installer app uses packages (.pkg), and metapackages (.mpkg) containing multiple packages to be installed together. Apple thus provided installations and updates as metapackages that could either be downloaded from its update servers using Software Update, or from the update’s web page. The same method was used until Big Sur, when updates changed again.

A system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.

This update required just 148 MB of disk space, and could readily be accommodated by any of these volumes of 11.5 GB capacity.

Most updates were concluded by a period ‘optimising system performance’, as determined by the post-install scripts in the package.

Here, Software Update is delivering Security Update 2004-05-03 to Mac OS X 10.3.3 Panther. Some system components like QuickTime were still supplied and installed separately, but the great majority of Mac OS X was integrated into a whole, and there were no options to install separate components.

Over this period, the system and user data shared a single boot volume, and updating the system mainly involved replacement of updated files. Installer packages contained those replacements together with scripts that were run to update the contents of the boot volume. For much of this, firmware updates were still supplied and installed separately, although later they were integrated into macOS updates.

Until the introduction of System Integrity Protection (SIP) in El Capitan, the only protection provided to system files and folders was in their permissions. Incomplete or incorrect installations and updates were therefore not uncommon, as despite its name, SIP didn’t have any means of verifying the integrity of system files. A procedure was introduced to verify directory structures and permissions against those listed in the Bill of Materials (BoM) for macOS updates, by repairing permissions, but that was still unable to verify the integrity of the files themselves.

Installer metapackages are highly portable, and were commonly downloaded to be installed on multiple Macs. To keep updates as small as possible, they were provided in two forms: a Delta update converted only the previous release, while a Combo update contained everything required to update the last major version and all intermediate minor versions in a single step.

The High Sierra 10.13 upgrade in September 2017 brought greatest change, with its inclusion of Apple’s new file system APFS. Macs that didn’t have a Fusion Drive had their system volume converted to APFS during the upgrade, although it was another year before the same happened to Fusion Drives.

Updates didn’t always work out right for everyone. This was a common problem with High Sierra Supplemental Update of 29 November 2017, for example.

This all changed with the first version of macOS to boot from a signed snapshot, Big Sur, in November 2020, to support the improved Secure Boot of Apple silicon Macs. This abandoned the use of Installer packages, relying instead on an Update Brain integrated into each installer app and downloaded update.

From then onwards, Apple has provided several different presentations of macOS installers and updates:

• Updates are only delivered through Software Update or its command tool equivalent softwareupdate, and have to be downloaded from Apple’s servers, or delivered through a local Content Caching Server.
• Full macOS installer apps are offered in the App Store then delivered through Software Update.
• Full macOS installer packages are available through softwareupdate or direct from Apple’s servers, and are named InstallAssistant. When installed, these create a full installer app.
• Full macOS installers are offered in Recovery, from where they’re downloaded from Apple’s servers.
• Full IPSW images containing firmware, Recovery and macOS partitions can be installed to restore Apple silicon Macs in DFU mode, using Apple Configurator 2 or later versions of the Finder. Those effectively reset that Mac to factory condition with that version of macOS pre-installed.

There are further complications to this. For instance, an older macOS Installer app can’t be run in a newer major version of macOS. The workaround for that is to create a bootable installer volume, and boot from that to run its older installer.

macOS updates are supplied compressed, and require up to 30 minutes preparation before they can be installed.

There are now no optional installations, as every copy of any given version of macOS is identical within its Signed System Volume (SSV).

The size of these new updates is considerably greater than those of older Installer packages, particularly in Big Sur, as engineering optimisations were being performed.

This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. Lines shown are best fits by linear regression.

Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.

Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.

macOS Ventura in 2022 experimented with Rapid Security Responses (RSRs), much smaller updates intended to provide urgent security fixes to Safari and some of its supporting components. These take advantage of cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. Updating cryptexes alone is far quicker too, as the SSV is left untouched. Unfortunately, the second RSR resulted in serious problems with Safari so had to be replaced three days later. The last RSR was released on 12 July 2023, and they appear to have been abandoned since.

Upgrading to the first release of the next major version of macOS had required downloading its full installer app from the App Store. Apple broke from this in macOS Ventura in October 2022, when that new macOS was installed as an update instead. Although this reduced its size and installation time required, it caught many users on the hop, as Apple provided no warning of the change. This approach has since become standard with both Sonoma and Sequoia.

Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature.

Early versions of classic Mac OS didn’t offer a lot of choice in terms of settings, and those that did were often implemented in their own tools as printers and networking were in the Chooser. Separate Control Panels came of age with System 7 in 1991, where they became applets accessible from Apple Menu Options. Originally, most were implemented as cdev code resources, but by the time of Mac OS 9 many had become full-blown apps.

Mac OS 9: Control Panels

The Energy Saver control panel offered three separate settings for sleep, each with its own slider: for putting your whole Mac to sleep, including its CPU, and optional separate controls for the display and hard disk(s).

In those days, virtual memory was controlled by the user in the Memory control panel, and RAM disks were popular among those Macs with ample physical memory.

Internet access and app settings were largely configured in a dedicated control panel, among the more complex in classic Mac OS. Details entered here, particularly for incoming and outgoing mail, applied to all compliant apps.

Mac OS X 10.0: System Prefs

By the end of classic Mac OS, there were 32 control panels, from the original Apple Menu Options to Web Sharing. Reproviding similar support in the first version of Mac OS X came in System Prefs, before its name was expanded to System Preferences a little later. These stepped away from being apps, and became the modernised equivalent of cdevs, using the NSPreferencePane API from Mac OS X 10.1 in 2001, and are assembled into bundles. Those have survived to the present, through System Preferences to the current System Settings.

Unlike control panels, System Prefs constrained all its panes to a fixed size, leading to deep and labyrinthine interfaces.

The QuickTime preference pane from 2002 illustrates how complicated these became.

In 2001, the Network pane was still used to configure AppleTalk, as supported by Apple’s own printers, the last of which had been discontinued in 1999. This also shows how individual panes had to cross-reference others, making navigation messy.

Individual views often contained remarkably few settings, here just five popup menus.

Mac OS X: System Preferences

At some time after 2002, System Prefs was expanded in name to System Preferences in a redesign, although its panes remained fixed in size.

QuickTime’s pane changed remarkably little in Mac OS X 10.3 Panther (2003).

In Mac OS X 10.4 Tiger (2005), the customisable favourites bar at the top was replaced by a navigation bar with search. Accessibility had been introduced as Universal Access, and in Mac OS X 10.8 Mountain Lion of 2012 it was revamped under its current name. The following screenshots show examples from around OS X 10.11 El Capitan in 2015.

The most visually impressive of all these panes was that for the Trackpad, containing embedded video clips demonstrating each gesture. These came at a cost, though: the pane was almost 100 MB in size as a result.

Bucking the trend to increasingly complex detail, Energy Saver in El Capitan was stripped down from its three separate sliders of Mac OS 9.

At its peak in macOS 12 Monterey in 2021-22, System Preferences provided around 30 panes arranged in what was intended to be logical order. Only after extensive use did many know where each was located. As some like Touch ID were model-specific, even experienced users sometimes took several seconds to locate the pane they wanted. Some, like Security & Privacy, had long outgrown the limitations imposed by their tiny windows.

macOS 13: System Settings

Apple’s radical redesign in macOS 13 Ventura of 2022 shocked many. Although it finally brought resizing to the System Settings window, that was confined to the vertical direction, resulting in many panes becoming long lists arranged in no obvious order. Given that almost all displays are wider than they are tall, that appeared an odd decision. Moreover, although it’s thought that SwiftUI was used to implement System Settings, little use has been made of its rich and extensible controls.

This is System Settings’ entry view in macOS Sequoia of 2025. Although its search feature has been improved, locating the appropriate section without using that remains a challenge for most.

Extensive use is made of floating modal windows, which in some settings can be nested so deep that reversing out of them is disorientating.

The greatest sin of all was that the wonderful video clips used previously in the Trackpad item had been dropped completely, and replaced by unhelpful static designs. After mass protests, Apple recanted and added animations, as shown above, but they were a pale shadow of System Preferences.

For all its shortcomings, and the limitations of fixed window size, System Preferences is one feature that many would like to see reinstated. Maybe the next redesign will be better conceived and received.

Passwords and other secrets were little-used until the arrival of email and the Internet. Secure storage for them in keychains was developed for the PowerTalk mail engine in Apple Open Collaboration Environment (AOCE), and was first released in about September 1993, probably in System 7.1.1. When AOCE was dropped from Mac OS 8, keychains languished until their revival later that decade, and were probably first supported by the System in around 1999 in Mac OS 8.6.

Those early keychains were the ancestors of what’s now referred to as file-based keychains, in contrast to the data protection keychain that can be shared in iCloud. Although macOS Sequoia still supports classic keychains, their use was discontinued with the introduction of Mac OS X in 2001, when they were replaced with newer keychains supported by the SecKeychain API.

SecKeychains gained full support in Mac OS X 10.2 Jaguar in 2002, and ever since have provided the central login keychain still used in Sequoia over 20 years later. These are encrypted databases containing login credentials and other secrets. Each keychain can be unlocked using a single password, with that of the login keychain being the same as the user’s login password, enabling it to be unlocked following login.

With the introduction of iPhones and their iOS operating system, they didn’t use SecKeychains, but a new and more secure relative known as the Data Protection keychain, with a separate SecItem API. Although support for that was added in Mac OS X 10.6 Snow Leopard in 2009, it wasn’t until OS X 10.9 Mavericks in 2013 that Macs started using Data Protection keychains for their iCloud Keychain. Two years later, with OS X 10.11 El Capitan, SecKeychains and their ancestors were formally deprecated, although much of their APIs still remain.

Throughout Mac OS X and into macOS, the bundled tool for maintaining keychains has been Keychain Access provided in /Applications/Utilities. With the arrival of the iCloud Keychain, Safari provided access to passwords stored in the iCloud Keychain, and that was later augmented in a Passwords item in System Preferences and Settings.

Earlier versions of Keychain Access, such as that seen here in Mac OS X 10.4 Tiger in 2005, provided a valuable First Aid tool to verify and repair keychains. That was dropped some years ago.

After the introduction of iCloud Keychain, the login keychain has steadily lost importance. Here it’s seen at its zenith in Mac OS X 10.6 Snow Leopard.

This shows the login keychain again, in Keychain Access from OS X 10.10 Yosemite in 2014.

macOS Sequoia brought a dedicated app Passwords that only works with the Data Protection keychain, and relegated Keychain Access to /System/Library/CoreServices/Applications, where it can still be used to work with traditional file-based keychains as well.

login keychain

For each user, their default personal file-based SecKeychain is the login keychain, located in ~/Library/Keychains/login.keychain-db. This is unlocked automatically when the user logs in as it has the same password as that user account. It’s here that each user can still store certificates, secure notes, etc. for general use on that Mac.

Although kept unlocked, readable and writeable while the user is logged in, that doesn’t guarantee access to its contents. If an app makes a call to the macOS security system to retrieve a stored password for its use, that system determines whether the app is trusted to access that information, and whether that keychain is locked. Assuming the password is stored there, the app is trusted, and the keychain is unlocked, then the password is retrieved and passed back to the app. If the app isn’t trusted or the keychain is locked, then the security system, not the app, displays a distinctive standard dialog asking for the password to that keychain to authenticate before it will provide the password to the app.

Access to secrets is determined by the security system, the specific access it grants to an app, and to individual items in that user’s keychain. At its most restrictive, the system can limit all other apps from accessing a particular secret in the keychain, but specific secrets can also be shared across several different apps.

System keychains

For the system, there two two vital groups of keychains:

• in /System/Library/Keychains, in the SSV, are SystemRootCertificates and others providing the set of root security certificates for that version of macOS;
• in /Library/Keychains is the System keychain and others providing certificates and passwords required for all users, including those to gain access to that Mac’s Wi-Fi connections.

Data Protection keychain

Since OS X 10.9, Macs have also had one and only one Data Protection keychain that’s accessed using the SecItem API. If you share your keychain in iCloud, this is the local copy of that shared keychain and is known as iCloud Keychain; if you don’t share it in iCloud, then it’s known as Local Items instead. The local copy of this is normally stored in ~/Library/Keychains/[UUID]/keychain-2.db, where the UUID is that assigned to that Mac.

This Data Protection keychain stores all the standard types of secret, including internet and other passwords, certificates, keys and passkeys. Prior to macOS 11, it only synchronised internet passwords using iCloud, but from Big Sur onwards it synchronises all its content, including passkeys, which have now become first class citizens. Unlike file-based keychains, secrets in the Data Protection keychain can be protected by the Secure Enclave in T2 and Apple silicon Macs, and can therefore be protected by biometrics including Touch ID, and Face ID on iOS and iPadOS. Hence they’re required for passkeys, which can’t be supported by traditional file-based keychains.

Future

Much as Apple wants to support only the Data Protection keychain in macOS, there are still many that rely on the login and other file-based keychains. SecKeychain will thus remain supported reluctantly until macOS can finally call it a day on keychains that originated well over 25 years ago.

References

Apple TN3137: On Mac keychain APIs and implementations
Apple Keychain Services

In the elegant simplicity of Classic Mac OS, applications were intended to be single files with much of their contents stored in their resource fork, where they kept all the paraphernalia they required, from code resources to windows, icons and dialogs.

This is QuarkXPress version 4.11 from around 2000, its resources displayed in the resource editor ResEdit. The app icons shown are stored in a resource of type BNDL, a ‘bundle’, but not in the later sense of the term.

In this respect, as in many others, Mac OS X abandoned its Mac past in favour of what had been developed in NeXTSTEP, here a structured directory termed a bundle. These were primarily used for constructs that the user was intended to see as a single item, usually containing executable code and its resources, forming applications, frameworks and plug-ins.

Early bundles

At first, there were two types of bundle in use. Versioned bundles consisted of a file containing executable code, together with a directory containing resources and more directories with further resources, without any Contents directory or top-level property list. New-style bundles contained a minimum of a top-level directory named Contents, and inside that a property list named Info.plist, as continues today. Some implementations of the new-style bundle also contained a file named PkgInfo containing type and creator information that had originated in Classic Mac OS; although apparently not mandatory, PkgInfo has survived to the present in app bundles.

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

• bundle name,
• name of bundle executable,
• version,
• type and creator codes, inherited from Classic Mac OS and duplicating those in PkgInfo,
• app and document icons,
• other metadata.

Current bundles are direct descendants of those new-style bundles.

Fat apps with support for both Classic Mac OS and Mac OS X had a more complex structure. Inside their Contents directory, they had the following:

• MacOSClassic directory, containing the Classic version of their executable code,
• MacOS directory, containing the Mac OS X version of their executable code,
• Info.plist file,
• Resources directory, containing resources such as icons, images, and directories of localised resources such as nibs and strings,
• Other directories such as Frameworks, PlugIns, SharedFrameworks and SharedSupport as necessary.

To enable that to run in Mac OS 9, alongside the Contents directory was an alias to the executable code in Contents/MacOSClassic.

The Finder recognised a directory as a bundle and treated it as a single entity if:

• the directory name had an extension for a standard bundle type, such as .app, .bundle, .framework, .plugin, .kext and others, or
• the directory name had an extension identifying it as a type set as a bundle (or package), such as .rtfd, or
• the directory had its Finder bundle bit set.

Frameworks are an exception to the general rule that the Finder displays bundles as single items, as they are still shown as folders. However, the original reason given by Apple for this, “so that you can browse their header files”, no longer applies.

Packages

By 2005, Apple was drawing a distinction between bundles with the formal structure given above, including the Info.plist inside a Contents directory, and other directories presented to the user as a single item, such as RTFD documents, that had different structures and are strictly termed packages. For example, the Rich Text Format Directory (RTFD) favoured by Apple consists of:

• 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.

This is closer to the versioned bundles of early Mac OS X. Currently, there are distinct UTI types for com.apple.bundle and com.apple.package, with bundles conforming to both, but packages only to the latter. Unfortunately, this distinction between bundles and packages has largely fallen into disuse because of the name collision with Installer packages.

More recently, in its iWork documents, Apple has moved away from plain document packages or bundles to a custom package in a Zip-compressed archive, for example in .pages documents, which still conform to com.apple.package although they can’t be opened in the Finder. Compression has also become popular with space-inefficient formats such as XML.

Signatures

The introduction of code signing in 2007 brought the requirement to store signature information including code directory hashes (CDHashes) inside the app bundle. This has been implemented using an additional directory, _CodeSignature, containing a CodeResources file. Single-file command tools can instead have their signature embedded in their binary.

Most recently, in 2018, notarization has added the requirement to accommodate its ‘ticket’, which is ‘stapled’ as another CodeResources file inside the Contents directory. However, stapling isn’t required, as notarization can be verified by looking up the CDHashes with Apple’s online service in iCloud. There’s also still no way to staple a notarization ticket to a single-file binary.

Platform-specific code

The transition from Classic Mac OS to Mac OS X used separate directories for executable code within app bundles, with that named MacOS containing code to be run in Mac OS X. When the Mac architecture changed from PowerPC to Intel, from 32-bit to 64-bit, and again from Intel to Arm, app bundles have continued to use the MacOS directory, with executable code for each supported architecture being saved within each file.

Key dates

• 1984 single-file application with resource fork, type and creator codes
• 2001 Mac OS X 10.0 Cheetah, with versioned and new-style bundles, PkgInfo for type and creator codes, Info.plist in new-style bundles
• 2005 bundles and packages
• 2007 Mac OS X 10.5 Leopard, _CodeSignature directory for code signatures
• 2018 macOS 10.14 Mojave, CodeResources for notarization ticket.

References

Apple’s Bundle Programming Guide, last updated to 2017
Apple, Inside Mac OS X, System Overview, July 2002, PDF no longer available online.