To celebrate the New Year, I’m taking a look back at how macOS has changed over the last five years, from 10.14 Mojave to 15.2 Sequoia. While you can read about many of the details in articles here and elsewhere, in this article I focus on its architecture, in particular the contents of the main system library folder, together with its bundled apps. Tomorrow I’ll look in more detail at one phenomenon, the rise of Private Frameworks, and what that tells us.

Mojave was in many ways the last of the traditional versions of what started out as Mac OS X, and not just for its support for 32-bit code. It was most significantly the last to integrate both the system and user files in a single volume, by default quaintly named Macintosh HD. Within that, most system files were concentrated in /System/Library, but many sprawled out from there, and bundled apps were installed in the single main /Applications folder. Although there was a separate Recovery volume, Macintosh HD was macOS and more.

Catalina changed that, first by requiring all code to be 64-bit, and by separating almost all macOS system files into a System volume, with user files on the Data volume. At that stage, System was a real volume mounted read-only, but that was just an intermediate step to the modern boot volume group, with the system being an immutable snapshot of the System volume, the Signed System Volume, SSV. The latter first appeared in macOS 11 Big Sur, and with the addition of a paired Recovery volume, continues in Sequoia.

Over that period, the contents of /System/Library grew considerably in size.

In Mojave, there were just under 4,800 bundles in that folder. Catalina’s reorganisation increased that to around 5,500, and each new major version of macOS since has added another few hundred, culminating in 15.2 with just over 9,000 in all.

Much of that growth has been in Private Frameworks to support macOS and its bundled apps and tools, shown in purple in the bar chart above. Public Frameworks have grown from 546 to 800, similar to kernel extensions, and all the remaining folders from 2,000 to 3,000.

Because bundled apps were only separated in Catalina, their numbers only start in late 2019, as shown in the next chart.

There was a marked rise for Big Sur, since when the total has risen more slowly, from about 55 to 64 today. Some have been removed over that time, such as Network Utility, and others have been relegated to /System/Library/CoreServices/Applications, as has Keychain Access in Sequoia.

The timeline of growth in the number of bundles in the System Library folder matches milestones in Mac history. The first steep rise occurred with Catalina’s novel version of the boot volume group, and since then there have been further steep rises immediately before the release of the first of each family of M-series chips.

The largest of those rises was for the M3 (900), with the M1 (600) and M4 (600) also being substantial. Strangely, that for the introduction of the M2 seems to have taken place over six months in advance, and was smaller at 500 bundles.

Of all the system components that should reflect changing Mac hardware, effects should be greatest on kernel extensions.

Over this period of more than five years the number of kernel extensions stored in /System/Library/Extensions has risen from a low of 515 in 10.15 to 930 in 15.2, five years and two months later. Almost all of that occurred with the release of Big Sur, the first version of macOS to support Apple silicon Macs, when kernel extensions rose from 535 (10.15.7) to 788 (11.0.1). Most of those were required to support all the new hardware devices in the M1 chip. Subsequent families of new M-series chips have required few additional kernel extensions, although their number has been rising more rapidly since macOS 13.0 in October 2022.

It’s hardly surprising that, when someone makes the leap from an old Mac running Mojave to a new model with Sequoia, they’ll encounter so many fundamental differences in macOS. After nearly twenty years of steady evolution, in the last five macOS has changed beyond all recognition.

Given how many of those changes have been required for the introduction of Apple silicon Macs, it’s hard to see how Apple could have reduced the frequency of major macOS upgrades over that period. Even if it had been possible for engineers to have taken macOS from 10.14 to 11.0 in a single step, I suspect that no user or developer could have survived such as huge change at once. Yet without those changes, Apple wouldn’t have been able to release the M1 in late 2020, and we’d probably still be using Intel Macs. I will revisit that in more detail at the weekend.

Tomorrow I’ll look in more detail at how its APIs have changed.