How macOS has become more private

Yesterday I showed how macOS has changed over the last five years, from 10.14 Mojave to 15.2 Sequoia, in terms of architecture and numbers. One figure I gave was how /System/Library increased in the number of bundles it contained from just under 4,800 in Mojave to over 9,000 in Sequoia. Within that folder, greatest growth has been in Private Frameworks, which have risen from under 1,800 to more than 4,300.

In fact, to be more precise, the number of real bundles in the Private Frameworks folder isn’t as large, as my directory crawler that analyses each release of macOS counts most of those frameworks twice, because of their structure. Halving the numbers returned still shows great growth in Private Frameworks, though:

In macOS 10.14.5 there were at least 273 Frameworks and 878 Private Frameworks.
In macOS 15.2 there are at least 400 Frameworks and 2,154 Private Frameworks.

Thus public Frameworks have risen to 147% of their number in mid-2019, and Private Frameworks have risen to 245%.

This chart provides better detail of these changes, as it gives the percentage of frameworks that were private over time. That percentage is:
PrivateFrameworks x 100 / TotalFrameworks
where PrivateFrameworks is the corrected (halved) number of Private Framework bundles, and TotalFrameworks is the sum of PrivateFrameworks and PublicFrameworks, the corrected number of public Framework bundles.

Each new major version of macOS over this period has brought a substantial increase in the percentage of Private Frameworks, rising from 76% in May 2019 to 84% in December 2024. Over that period, macOS has become increasingly private. Although the greatest increases have largely coincided with the release of new families of M-series chips, the largest rise of all was of 2.1% with the release of macOS 12.0.1, nine months before the release of M2 Macs.

Apple last explained what Frameworks are over a decade ago, in its programming guide for them. They’re bundles providing resources that can be shared across multiple apps at the same time, and typically include at least one dynamic shared library, together with other resources such as images, strings and header files. Those that Apple makes public, in /System/Library/Frameworks, make up much of the macOS app programming interface (API). An invaluable guide to all public Frameworks across macOS and device operating systems is maintained by Marco Eidinger.

One example that I’m becoming increasingly familiar with is the huge Accelerate library, contained in the public Accelerate Framework. That provides a vast range of mathematical functions used when processing media such as audio and images, support for vector and matrix operations, and much more. Those functions are crafted by specialist engineers who may include different techniques optimised for different hardware resources, and deliver a combination of excellent precision and speed.

Look through Marco’s list and you’ll see a single public Framework for Siri, SiriKit. Compare that with those listed in the Private Frameworks for macOS 15.2 Sequoia, where you’ll find a total of 123 for Siri. Apple explains that Private Frameworks “are appropriate for code modules you want to use in your own applications but do not want other developers to use.”

In the past, developers have been able to browse the contents of Private Frameworks directly, and where they expose header files and other information those have been readily accessible, even if they can’t be used by third-party code. Although independently distributed apps can’t be prevented from using Private Frameworks, it’s one of the guaranteed ways of getting an app rejected from an App Store. More recently, dynamic shared libraries (dyld) have been supplied in huge caches within the OS cryptex installed by macOS. Accessing their contents is more complex, and has been explained by Juan Cruz Viotti.

Undoubtedly, much of what’s contained in Apple’s Private Frameworks is of neither use nor interest to third parties, and it’s up to Apple to determine what it exposes in public Frameworks. But this sustained high growth rate in Private Frameworks over the last five years prompts the question as to how much of macOS is now private and proprietary, rather than being accessible and even, where appropriate, open source. Some of us are old enough to remember a time when it was strongly hinted that source code for APFS would be released, but now its documentation isn’t even being maintained.