With strong rumours that Apple intends changing its version numbering system for the next major release of macOS and its other operating systems, it’s a good time to see how we got to macOS 15.

Early Classic Mac OS

The first version of Classic Mac OS released with the original Macintosh 128K naturally came with System 1.0 and Finder 1.0. Within a few months, version numbering was already becoming confusing, when the successor System Software 0.1 had apparently started at 0.0, but the System itself had reached 1.1. This worsened when System Software 1.0 was released two years later, and came with System 3.1 and Finder 5.2.

Apple then adopted its first triplet numbering scheme that resembled modern Semantic Versioning in System 6.0 of June 1988. Over the following three years that worked its way steadily up to version 6.0.8, then handed over to System 7 on 13 May 1991 without any minor versions being released.

System 7

The first full use of the triplet numbering scheme came with System 7. That had four minor versions, 7.0, 7.1, 7.5 and 7.6, with each having patch releases such as 7.0.1 in between. This scheme followed the rules:

• the first number gives the major version;
• the second number gives the minor version that should remain backward-compatible in its changes;
• the third number gives the patch version denoting backward-compatible bug fixes.

It was then that Apple started to release special versions of Mac OS to support new models, for example 7.1P5 for Performa models, complicating the numbering. This was even worse with System 7.1.2, which was only supplied with some early Power Macs and a few 68K Quadra models. That was accompanied by System 7.1.2P, a special version for models released around the time that Apple also released System 7.5, in September 1994.

System 7.5 brought a different numbering scheme to deal with exceptions. For example:

• System 7.5.3 Revision 2 followed 7.5.3 without any Revision 1, and made various improvements;
• System 7.5.3 Revisions 2.1 and 2.2 were released on the same day to address problems with Revision 2 on different models;
• System 7.5.4 was never released at all, and the next release was 7.5.5.

Fortunately, the remaining versions of Classic Mac OS were conventional in their numbering, until the last in Mac OS 9.2.2 in December 2001.

Mac OS X

The public beta of Mac OS X introduced build numbers to supplement their triplet version numbering. At this time, the build number was based broadly on three components:

• the first number or build train gives the major version, starting from 4 for 10.0, as this includes NeXTSTEP up to version 3;
• the letter gives the minor version number, starting from A, which can also be bumped for hardware-specific builds, so may not match the triplet minor version number;
• the remaining number is the sequential build number within that minor version, usually incremented daily. That’s normally three digits, but an additional digit can be prefixed to indicate specific hardware platforms.

Triplet versions and build numbers were surprisingly well behaved until 2010, although separate build numbers were used during the transition from PowerPC to Intel architecture in Mac OS X 10.4 Tiger.

The first signs of complications came with Mac OS X 10.6.3, in March-April 2010, which came in three different builds and a v1.1, and 10.6.8 also had a v1.1 released a month after the original update. Mac OS X 10.7 Lion set a trend for a final Supplemental Update to 10.7.5, and frequent Security and Supplemental Updates became the rule by 2018, with macOS 10.12 Sierra and its successors.

By 2019, these updates had become uncontrollable. macOS 10.14 Mojave, for example, had three Supplemental Updates in the two months after its final release, named as 10.14.6 Supplemental Update, 10.14.6 Supplemental Update (a second time), and 10.14.6 Supplemental Update 2 (really 3).

macOS 11

The first version of macOS to support Apple silicon Macs, macOS 11 Big Sur, had been generally expected as macOS 10.16, but shortly before its announcement at WWDC in June 2020 the decision was made for it to become macOS 11, incrementing the major version number for the first time in almost 20 years. As that reset the minor version number from 15 to 0, there was the potential for chaos, as many scripts and much code had come to ignore the major version number, and to rely on the minor version to determine which release was running.

To cater for this, when those checked ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identified itself as macOS 10.16. Apps ported to Xcode 12 used the 11.0 SDK; when they checked ProcessInfo.processInfo.operatingSystemVersion.minorVersion (or its equivalent), Big Sur identified itself as macOS 11.0. Those who relied on command tools were provided with a workaround, as
sw_vers -productVersion
returned 10.16 when running in Big Sur on an Intel Mac, but 11.0 on an Apple Silicon Mac.

This enabled Apple to return to a triplet scheme without the complications of Supplemental Updates or other vagaries. Each year’s major version of macOS has thus been x.0, with scheduled minor versions numbered from x.1 to x.5 or x.6, and intermediate patch releases (usually security updates) from x.x.1 upwards. At the end of its year as the current release of macOS, x.6 marked the start of its first year of security-only support, and x.7 for the second and final year. The exception to this has been Sonoma, which started its first year of security-only support with version 14.7, so its security updates have coincided in their minor and patch numbers with the older Ventura.

The only complication to this much clearer system was introduced in Ventura with Rapid Security Responses (RSRs). Those didn’t change the triplet version, as macOS proper remained unchanged, but added a letter to form, for example, macOS 13.4.1 (c). That proved clumsy, and when reflected in a resulting Safari version number it broke a lot of major websites that were unable to identify the browser version correctly. Since RSRs have fallen out of favour, this proved to be a passing phase.

When I wrote about the unexpected change in version numbering brought in Big Sur, I claimed that “no matter what Apple may eventually settle on, I shouldn’t have to change that again for many years.” I’m not sure that five counts as many, but here we go again.

References

Semantic Versions, SemVer
Apple package version numbering
Robservatory Mac OS X versions and release dates
System updates, including security data etc., since 2016

When the Mac 128K was launched, the computing world was quite happy working with text composed using single-byte characters, and the full 256 characters of Extended ASCII seemed quite sufficient. In those days, encoding text for each language was based on its code page, a different set of 256 characters according to that language’s needs and conventions.

The Mac’s initial version of Extended ASCII became its standard Mac OS Roman encoding by System 6.0.4 in 1989. Since then it has been modified to add support for the euro currency symbol in 1998, and is still supported in macOS. Other code pages for single-byte character encoding extended to Mac OS Icelandic, for example, which formed the basis of Macintosh Latin used by the popular Kermit file-transfer software.

Many languages can’t be encoded in such small character sets, and required 2-byte encodings instead. Dealing with these complexities and support for different writing directions became the task of the Script Manager, introduced in System 4.1 in 1987.

Another fundamental concept in Mac OS has been that text isn’t just a character set, but has to be drawn on the display with other graphics content. Text handling thus became integrated with its rendering and features such as word breaking and ligatures. Support for handling text using mixed scripts came in two optional extensions: WorldScript I for single-byte encodings, and WorldScript II for 2-byte encodings such as Chinese, Japanese and Korean.

There were two more mundane complications for the Classic Mac OS user: line termination, and string handling in code.

While MS-DOS and PCs used the combination of carriage return and line feed characters (\r\n) to terminate lines, Classic Mac OS used carriage return (\r) alone, then Mac OS X followed the Unix convention of using line feed (\n) alone. Although the better text editors supported each of those, and would convert text files between them, that became tedious.

Much application development for Classic Mac OS was performed in Apple’s Macintosh Programmer’s Workshop (MPW) using the extended implementation of Pascal known as Object Pascal. This had adopted UCSD Pascal string format, in which the first byte(s) in its native strings contained the length of the string in bytes, rather than its first character. This was all the more confusing when combining projects with C, whose native string format didn’t preface its characters with length, but terminated every string with a null byte.

In 1985, while working on KanjiTalk, the heart of the Mac’s Japanese localisation, Mark Davis and Ken Krugler developed ideas that eventually led to Unicode. When Davis hired Lee Collins to join him at Apple from Xerox, they developed their proposals further, and in 1987 Apple was one of the founders of the Unicode Consortium. The following year, Apple decided to build Unicode support into TrueType, the new font standard it released in System 7 in 1991.

In 1998 System 8.5 integrated support for Unicode text, in Apple Type Services for Unicode Imaging, ATSUI, which was still supported until 2022, and has finally been removed altogether in macOS 14 Sonoma the following year. Initial support for Unicode included UTF-16 encoding to the Unicode Standard version 2.1. Conversion between text encodings was provided by the Text Encoding Conversion Manager.

Core Text superseded ATSUI in Mac OS X 10.5 Leopard in 2007, and is part of the Cocoa text system inherited from NeXTSTEP.

One unexpected new feature of Unicode was the LastResort, the symbol shown for a code point that doesn’t exist yet, and the product of garbled text, seen here in 2007.

Even in familiar languages like Greek, Unicode offers exotics such as GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI, whatever that might be used for.

However, Unicode has brought its own problems, among them its acceptance of multiple code points (character encodings) for visually identical characters. In normal text use this can impede searching, but becomes more critical with the naming of files and directories.

The letter Å can be represented in UTF-8 as either C3 85 (Form C) or 41 CC 8A (Form D). Search for the word Ångström using Form C, and you won’t find the same word using Form D instead. A file system that allows both forms to appear independently in file and directory names appears to the user to allow items with duplicate names, and that poses further problems for search.

In Apple’s Macintosh Extended (HFS+) file system, Unicode normalisation is used to map characters to Unicode Form D, but when Apple developed APFS it intended to leave any normalisation to apps. Early releases of APFS thus didn’t perform normalisation, resulting in many problems for app developers and users. This was rectified by incorporating a normalisation layer into macOS to return to the relative sanity of Form D.

It would perhaps be better to close without mentioning the annual additions to emoji supported in Unicode, as announced prominently in macOS updates. It has been a long and sometimes arduous journey from Extended ASCII to the of .

Apple Inside Macintosh: Text (1993)
Pascal string types in the Free Pascal and Lazarus Wiki
Unicode – the beginnings, Mark Davis and others
Apple Core Text Programming Guide (2007-2014)
Apple Core Text, current documentation

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.