One of the most frequently quoted measurements in Activity Monitor is % CPU. When the fans blow, or a Mac becomes sluggish, it’s often the first figure to look at and wonder why that process is pulling over 100%. That’s the first thing you learn: here, per cent doesn’t mean out of 100, but the sum of the real percentage for each core. As this Mac has eight cores, that allows it up to 800%, until you realise that Intel processors can use Hyper-Threading to pretend that each is two cores, making a maximum of 1,600%, not bad for a single processor. Then you come completely unstuck with Apple silicon.

Apple defines % CPU as “the percentage of CPU capability that’s being used”, a phrase that doesn’t appear to have any definition either in Apple’s documentation or elsewhere. So like everyone else, you assume that 100% for a core represents its maximum processing capacity. Only you couldn’t be more incorrect: in truth, the number given as % CPU is nothing like that.

Tests

To examine this more clearly, I have an app that runs tight loops of assembly code to load CPU cores on Apple silicon chips and measure their performance. For this, I got it to run several threads, each consisting of 500 million loops of floating point calculations. By running those at different Quality of Service (QoS) settings, macOS will send them to different core types.

When I run two threads at low QoS so they’re run only on E cores of a MacBook Pro M3 Pro, each takes 10.2 seconds to complete. If I instead run eight threads at high QoS, the first six of those will be run on the P cores, but the remaining two spill over onto two of the E cores, where they complete in just 3.0 seconds each.

Yet, according to % CPU in Activity Monitor, the two threads on the E cores come to 200%, and the two from eight run in the second test also come to 200%. You can see this in the CPU History window.

Here are the 6 E cores at the top, and 6 P cores below. ① marks the first test on two E cores, and shows the total of 200% spread across all six E cores over the 10.2 seconds it took to complete. ② marks the second test, with all 6 P cores and two E cores hitting 100% each, for a total of 800%, as shown in Activity Monitor’s window.

By now I’m sure you guessing how running the same code on the E cores could vary in speed by a factor of 3.4 (10.2 against 3.0 seconds) although they’re the same % CPU: that measurement doesn’t take into account core frequency.

Frequency

Unlike traditional Intel CPUs, CPU cores in Apple silicon chips can be run at a wide range of frequencies, as set by macOS. To make this frequency control a bit simpler, cores are grouped into clusters, that also share L2 cache, and within each cluster all cores run at the same frequency. The M3 Pro chip consists of two clusters, one of 6 E cores, the other of 6 P cores.

When macOS loads two of those E cores with low QoS threads, it sets them to run at a low frequency to make the most of their energy efficiency. When it loads two E cores with threads that were intended to be run on P cores, as they have a high QoS, it runs the E cluster up to high frequency, so they perform better.

Measuring frequency of CPU cores is straightforward using the powermetrics command tool. When those threads were being run on E cores at low QoS, frequency was held at their minimum of 744 MHz, but run at high QoS their frequency was set to maximum, at 2748 MHz, 3.7 times faster. If full load at maximum frequency is 100% of their capability, then at low QoS they were really running at 27%, not the 100% given by Activity Monitor, and that largely accounts for the difference in time that those threads took to complete their floating point calculations.

What is % CPU?

What Activity Monitor actually shows as % CPU or “percentage of CPU capability that’s being used” is what’s better known as active residency of each core, that’s the percentage of processor cycles that aren’t idle, but actively processing threads owned by a given process. But it doesn’t take into account the frequency or clock speed of the core at that time, nor the difference in core throughput between P and E cores.

The next time that you open Activity Monitor on an Apple silicon Mac, to look at % CPU figures, bear in mind that while those numbers aren’t completely meaningless, they don’t mean what you might think, and what’s shown as 100% could be anything between 27-100%.

In the light of recent news, you might now be wondering whether you can afford to wait until next year in the hope that Apple then releases the M4 Mac of your dreams. To help guide you in your decision-making, this article explains what chip options are available in this month’s new M4 models, and how to choose between them.

CPU core types

Intel CPUs in modern Macs have several cores, all of them identical. Whether your Mac is running a background task like indexing for Spotlight, or running code for a time-critical user task, code is run across any of the available cores. In an Apple silicon chip like those in the M4 family, background tasks are normally constrained to efficiency (E) cores, leaving the performance (P) cores for your apps and other pressing user tasks. This brings significant energy economy for background tasks, and keeps your Mac more responsive to your demands.

Some tasks are normally constrained to run only on E cores. These include scheduled background tasks like Spotlight indexing, Time Machine backups, and some encoding of media. Game Mode is perhaps a more surprising E core user, as explained below.

Most user tasks are run preferentially on P cores, when they’re available. When there are more high-priority threads to be run than there are available P cores, then macOS will normally send them to be run on E cores instead. This also applies to threads running a Virtual Machine (VM) using lightweight virtualisation, whose threads will be preferentially scheduled on P cores when they’re available, even when code being run in the VM would normally be allocated to E cores.

macOS also controls the clock speed or frequency of cores. For background tasks running on E cores, their frequency is normally held relatively low, for best energy efficiency. When high-priority threads overspill onto E cores, they’re normally run at higher frequency, which is less energy-efficient but brings their performance closer to that of a P core. macOS goes to great lengths to schedule threads and control core frequencies to strike the best balance between energy efficiency and performance.

Unfortunately, it’s normally hard to see effects of frequency in apps like Activity Monitor. Its CPU % figures only show the percentage of cycles that are used for processing, and make no allowance for core frequency. It will therefore show a background thread running at low frequency but 100%, the same as a thread overspilt from P cores running at the maximum frequency of that E core. So when you see Spotlight indexing apparently taking 200% of CPU % on your Mac’s E cores, that might only be a small fraction of their maximum capacity if they were running at maximum frequency.

There are no differences between chips in the M4 family when it comes to each type of CPU core: each P core in a Base variant is the same as each in an M4 Pro or Max, with the same maximum frequency, and the same applies to E cores. macOS also allocates threads to different types of core using the same rules, and their frequencies are controlled the same as well. What differs between them is the number of each type of core, ranging from 4 P and 4 E in the 8-core variant of the Base M4, up to 12 P and 4 E in the 16-core variant of the M4 Max. Thus, their single-core benchmark results should be almost identical, although their multi-core results should vary according to the number of cores.

Game Mode

This mode is an exception to normal CPU and GPU core use, as it:

• gives preferential access to the E cores,
• gives highest priority access to the GPU,
• uses low-latency Bluetooth modes for input controllers and audio output.

However, my previous testing didn’t demonstrate that apps running in Game Mode were given exclusive access to E cores. But for gamers, it now appears that the more E cores, the better.

GPU cores

These are also used for tasks other than graphics, such as some of the more demanding calculations required for Machine Learning and AI. However, experience so far with Writing Tools in Sequoia 15.1 is that macOS currently offloads their heavy lifting to be run off-device in one of Apple’s dedicated servers. Although having plenty of GPU cores might well be valuable for non-graphics purposes in the future, for now there seems little advantage for many.

Thunderbolt 5

M4 Pro and Max, but not Base variants, come equipped with Thunderbolt ports that not only support Thunderbolt 3 and 4, but 5, as well as USB4. Thunderbolt 5 should effectively double the speed of connected TB5 SSDs, but to see that benefit, you’ll need to buy a TB5 SSD. Not only are they more expensive than TB3/4 models, but at present I know of only one range that’s due to ship this year. There will also be other peripherals with TB5 support, including at least one dock and one hub, although neither is available yet. The only TB5 accessories that are already available are cables, and even they are expensive.

TB5 also brings increased video bandwidth and support for DisplayPort 2.1, although even the M4 Max can’t make full use of that. If you’re looking to drive a combination of high-res displays, consult Apple’s Tech Specs carefully, as they’re complicated.

Although TB5 will become increasingly important over the next few years, TB3/4 and USB4 are far from dead yet and are supported by all M4 models.

Which M4 chip?

The table below summarises key figures for each of the variants in the M4 family that have now been released. It’s likely that next year Apple will release an Ultra, consisting of two M4 Max chips joined in tandem, in case you feel the burning desire for 24 P and 8 E cores.

Models available next week featuring each M4 chip are shown with green rectangles at the right.

There are two variants of the Base M4, one with 4P + 4E and 8 GPU cores, the same as Base variants in M1 to M3 families. There’s also the more capable variant, for the first time with 4P + 6E, which promises to be a better all-rounder, and when in Game Mode. It also has an extra couple of GPU cores.

The M4 Pro also comes in two variants, this time differing in the number of P cores, 8 or 10, and GPU cores, 16 or 20. Those overlap with the M4 Max, with 10 or 12 P cores and 32 or 40 GPU cores. Thus the gap between M4 Pro and Max isn’t as great as in the M3, with the GPUs in the M4 Max being aimed more at those working with high-res video, for instance. For more general use, there’s little difference between the 14-core Pro and Max.

Memory and storage

Chips in the M4 family also determine the maximum memory and internal SSD capacity. Apple has at last eliminated base models with only 8 GB of memory, and all now start with at least 16 GB. Base M4 chips are limited to a maximum of 32 GB, while the M4 Pro can go up to 64 GB, and the 16-core Max up to 128 GB, although in its 14-core variant, the Max is only available with 36 GB (I’m very grateful to Thomas for pointing this out below).

Unfortunately, Apple hasn’t increased the minimum size of internal SSD, which remains at 256 GB for some base models. Smaller SSDs may be cheaper, but they are also likely to have shorter lives, as under heavy use their small number of blocks will be erased for reuse more frequently. That may shorten their life expectancy to much less than the normal period of up to 10 years, as was seen in some of the first M1 models. This is more likely to occur when swap space is regularly used for virtual memory. I for one would have preferred 512 GB as a starting point.

While Base M4 chips come with SSDs up to 2 TB in size, both Pro and Max can be supplied with internal SSDs of up to 8 TB.

I hope this proves useful in guiding your decision.

This article describes one change that has caught out some using macOS Sequoia, and considers what has changed in Sequoia Virtual Machines (VMs).

periodic has been removed

After many years of deprecation, the periodic scheduled maintenance command tool has been removed from macOS 15.0. In its heyday, periodic was responsible for running daily, weekly and monthly maintenance and housekeeping schedules including rolling the system logs. Over that time, macOS has been given other means for achieving similar ends. For example, logs are now maintained constantly by the logd service, and aren’t retained by age, but to keep the total size of log files fairly constant. I don’t think that Sonoma performed any routine maintenance using periodic.

If you use periodic, then the best option is to use launchd with a LaunchAgent or LaunchDaemon. If you’d prefer to use cron, that’s still available but is disabled in macOS standard configuration.

Sequoia VMs: AI

Sequoia VMs created from an IPSW image of Sequoia (rather than upgraded from Sonoma or earlier) running on Sequoia hosts are the first to gain access to iCloud features. Now that 15.1 has been released with AI, I’ve been trying to discover whether that can also be used in a VM. So far, my 15.1 VM has sat for hours ‘preparing’, but AI still hasn’t activated on it. I suspect that, for the present, AI isn’t available to VMs. If you have had success, please let me know.

Sequoia VMs: macOS builds

My test 15.1 VM has also behaved strangely. It was originally created in 15.0, updated successfully to 15.0.1, then to 15.1, where it was running build 24B83, the version released generally on 28 October. Later that week Software Update reported that a macOS update was available, and that turned out to be a full install of 15.1 build 24B2083, released on 30 October for the new M4 Macs. This VM is hosted on a Studio M1 Max!

Installation completed normally, and that VM now seems to be running the new build perfectly happily, although it hasn’t proved any help in activating AI.

Don’t be surprised if your 15.1 build 24B83 VMs behave similarly. If anyone can suggest why that occurred I’d be interested to know, as it’s generally believed that build 24B2083 has been forked to support only M4 models.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5279. As usual, Apple doesn’t release information about what security issues this update might add or change.

Relative to the last version released for all supported versions of macOS (5278), this version makes a small amendment to the detection rule for MACOS.PIRRIT.CHU.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5279.

For Sequoia only: there’s no sign of this update being made available in iCloud, which now returns an XProtect version of 5278. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command
sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.

I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

Signing and notarization of apps and other executable code is a controversial topic. Over the last decade and more Apple has steadily introduced increasingly demanding standards, now requiring developers to notarize apps and other code they distribute outside the App Store. This article tries to explain why, and how this contributes to Mac security.

I would hope that what we all want is confidence that all executable code that our Mac runs, in particular apps, is exactly as was built by its developer. In addition to that, in the event that any code is found to be malicious, then macOS can promptly protect us by refusing to launch it. The first requirement is thus about verification of apps and code, and the second is about having a system that can block code from being launched in the first place.

CDHashes

The well-proven way to verify that files and bundles haven’t changed is using cryptographic hashes of their contents. Compute a hash, save it in a way that can’t be tampered with, and you can verify a bundle by recomputing its hash and confirming that it hasn’t changed. Apple has been using this for a long time, and its approach is a little more complex, as explained in detail in this excellent tech note.

When an app is signed, hashes are computed for different parts of its contents and assembled into a code directory, a data structure rather than a folder/directory. That data structure is then hashed to form the cdhash, or CDHash with mixed case to aid its reading. Because it’s a hash of hashes, it uniquely identifies that app, bundle or other executable code. CDHashes are thus part of the signing process, and the signature contains those CDHashes. They are also part of the notarization process, in which Apple’s Notary Service signs the CDHashes for code when it undergoes notarization, and that forms the notarization ticket that’s issued for that app, and normally attached or ‘stapled’ to it.

Between them, code signing and notarization thus provide two levels of verification, in a signature attached to the code itself, and in a record kept by Apple following successful notarization.

Unsigned apps

An unsigned app has no CDHashes, so its contents are uncontrolled and no verification is possible. It can change its own contents, morph itself from benign to malicious, forge its identity by posing as a completely different app, or be hijacked to run malicious code. While macOS could compute its CDHashes and Apple could try to track them, there’s no way to verify its identity, so external checks aren’t feasible, and there’s no way to block the code from being launched, as all it would need to do to evade that would be to change itself so its CDHashes changed.

Although macOS running on Intel Macs long tolerated this, from their release four years ago, Apple silicon Macs have refused to run such unsigned code.

Ad-hoc signed apps

Since Apple required code to be signed for Apple silicon Macs, all self-respecting build systems for macOS have automatically signed the code they generate. However, unless the developer has a certificate issued by Apple, by default they use ‘ad hoc’ certificates that are created locally and lack any chain of trust. That enables anyone to create CDHashes at any time, without any traceability to a trusted root certificate.

This is a slight improvement on completely unsigned code, and does enable an app to be identified by its CDHashes, but as they’re so easy to create, there’s no reliable way to verify that the app hasn’t changed since its original build. Although Apple could try to collect those CDHashes, there’s no useful way to block code from being launched, as all an adversary needs is to resign the code to change its CDHashes: they’re simply too labile to be trustworthy.

Certificate signed apps

For many years, before Apple introduced notarization over six years ago, this was the standard expected, but not required, of apps distributed by third-party developers. Although in theory developers could have used certificates provided by other authorities, not all Certificate Authorities are equal in their diligence, and Apple rightly wanted to be responsible for all revocations.

Certificates add control and verification, within limits determined by the certificate user. CDHashes gathered from code can be collected, but again their provenance relies on their user. At one time, they were commonly abused by those distributing malicious software. Although abused certificates were revoked by Apple, before that could happen, the malware had to be detected and identified, which could allow it to be run by many users for long before it could be blocked.

Certificate checks were another problem with this approach. It isn’t practical to check each certificate every time code is to be launched, so approvals have to be cached locally, adding to the delay before any revocation becomes effective.

Notarization

To address the limitations of signing code using developer certificates, Apple introduced the process of notarization. In this context, it adds:

• CDHashes from notarization are known to Apple, and stored in its database, for quicker online checks, and more rapid revocation.
• Apple screens apps being notarized to detect those that may be malicious.
• Apple has a complete copy of every app that has been notarized, and already knows its CDHashes.

This finally checks the provenance of all code being run, through its CDHashes; if they’re not already known to Apple, then that build of the app can’t have been notarized, and can be blocked from launching, provided the user doesn’t disable notarization checks. Screening for malware forces those trying to get malicious code notarized to adopt techniques of obfuscation, but even if those are successful, Apple already has a copy of that app and its CDHashes. That eliminates much of the delay incurred by certificate-signed apps. Together these have proved sufficient disincentive to malware developers to try to abuse notarization.

Key features of notarization are thus:

• Verification that the app or code hasn’t changed since it was built by its developer, up to the moment that it’s run.
• Independent verification against Apple’s database.
• Rapid blocking if the app or code is discovered to be malicious.
• Apple is provided with a full copy of the app or code, to aid any further investigation.
• All apps or code are checked independently for evidence that they’re malicious, before they can be released.

If you can come up with a system that achieves those and could replace notarization, I’m sure that Apple would love to hear of it.

I hope that you enjoyed Saturday’s Mac Riddles, episode 280. Here are my solutions to them.

1: Third prime should run at twice three or four, and four times two.

2: The third of XV brought AI for some.

3: If E > P and E + P = GPU what does E equal?

The common factor

I look forward to your putting alternative cases.

If you encounter problems with QuickLook not creating Thumbnails or Previews properly, one of the first steps is to discover which code is responsible for generating those for QuickLook. Prior to macOS Sequoia, the standard way to do that was using the command tool qlmanage, among whose options is -m, to list all the qlgenerators available on your Mac. If you’ve tried that in Sequoia, you’ll surely have noticed that no longer works.

qlmanage

Since Catalina, Apple has been encouraging developers to switch away from qlgenerators to app extensions to create custom Thumbnails and Previews for QuickLook, and Sequoia is the first version of macOS that can’t use third-party qlgenerators. I have noticed some document types that only a few weeks ago in Sonoma still used custom thumbnails and full previews, but now can’t do so, although others continue to work normally.

These are controlled in the Quick Look item in Login Items & Extensions in General settings.

That should list all third-party app extensions providing this service, and enabling the right one(s) could fix some of those problems. But it turns out this list isn’t complete, and doesn’t in any case tell you which app extension handles which file type. For those, you’d normally turn to qlmanage, but its -m option can only see the qlgenerators in macOS, and no third-party app extensions at all. In fact, qlmanage is now of little help for anything related to QuickLook. I’ve gone back through Sonoma and Ventura, and qlmanage there is no different: although it does list third-party qlgenerators, none of those provided in app extensions appear in its list.

QuickLook app extensions

As far as I can discover, Apple doesn’t provide any equivalent of qlmanage that can report on QuickLook app extensions. The closest it comes is in the pluginkit tool, that can list all app extensions known to macOS. With a bit of tweaking, its -m option can reveal which of those use the QuickLook SDKs for Thumbnails or Previews.

Armed with the appex bundle path from pluginkit, you can then inspect the Info.plist in each, where there’s an array of QLSupportedContentTypes giving the UTIs of all file types supported by that appex. Although I’m sure someone could implement that in a shell script, this seemed an ideal task for my free utility Mints.

Mints and QuickLook

Version 1.20 of my free utility Mints is now available from here: mints120
from Downloads above, from its Product Page, and via its auto-update mechanism.

This adds a twenty-fifth button to the app’s control window, named QuickLook, at the bottom left. Click on that and Mints will open a new window and fill it with information about all the qlgenerators and QuickLook appexes your Mac knows about.

For qlgenerators, you’re given the file UTI, the path to the qlgenerator file, and (when available) its version number, e.g.
com.adobe.pdf /System/Library/QuickLook/PDF.qlgenerator (1002.2.3)

App extensions are divided into two, the first are those providing Previews, and the second those for Thumbnails, e.g.
com.apple.applescript.text /Applications/PreviewCode.app/Contents/PlugIns/Code Previewer.appex

This is an appex provided in one of Black Pyramid Software’s superb Preview series, in PreviewBundle 2 from the App Store (highly recommended).

You will see a few entries like Safari’s
[none] /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/PlugIns/SafariQuickLookPreview.appex
with an appex that doesn’t have a list of file types in QLSupportedContentTypes.

Checking UTIs

It’s easy to guess which UTIs represent many file types, but some are a bit more cryptic. For those, copy and paste the UTI into the UTI field of my free UTIutility and it will give you clues as to its identity, including file extensions.

Unfortunately, some of the system qlgenerators support generic UTIs such as
public.audio /System/Library/QuickLook/Audio.qlgenerator (1002.2.3)
public.image /System/Library/QuickLook/Image.qlgenerator (1002.2.3)
public.movie /System/Library/QuickLook/Movie.qlgenerator (1002.2.3)
which clearly cover broad ranges of more specific file types, but don’t provide any more specific information.

How to identify QuickLook extensions

• List installed QuickLook extensions using Mints’ QuickLook button.
• Identify the file’s UTI using UTIutility.
• Locate the UTI in the list of extensions.
• If no match is found, check UTIs listed in UTIutility as Conforms.
• Check Quick Look item in Login Items & Extensions in General settings, to ensure that extension is enabled.

Next up for Mints is a feature to explore app extensions. I may be a little longer on that one.

Almost exactly a year after it released its first Macs featuring chips in the M3 family, Apple has replaced those with the first M4 models. Benchmarkers and core-counters are now busy trying to understand how these will change our Macs over the coming year or so. Before I reveal which model I have ordered, I’ll try to explain how these change the Mac landscape, concentrating primarily on CPU performance.

CPU cores

CPUs in the first two families, M1 and M2, came in two main designs, a Base variant with 4 Performance and 4 Efficiency cores, and a Pro/Max with 8 P and 2 or 4 E cores, that was doubled-up to make the Ultra something of a beast with its 16 P and 4 or 8 E cores. Last year Apple introduced three designs: the M3 Base has the same 4 P and 4 E CPU core configuration as in the M1 and M2 before it, but its Pro and Max variants are more distinct, with 6 P and 6 E in the Pro, and 10-12 P and 4 E cores in the Max. The M4 family changes this again, improving the Base and bringing the Pro and Max variants closer again.

As these are complicated by sub-variants and binned versions, I have brought the details together in a table.

I have set the core frequencies of the M4 in italics, as I have yet to confirm them, and there’s some confusion whether the maximum frequency of the P core is 4.3 or 4.4 GHz.

Each family of CPU cores has successively improved in-core performance, but the greatest changes are the result of increasing maximum core frequencies and core numbers. One crude but practical way to compare them is to total the maximum core frequencies in GHz for all the cores. Strictly speaking, this should take into account differences in processing units between P and E cores, but that also appears to have changed with each family, and is hard to compare. In the table, columns giving Σfn are therefore simply calculated as
(max P core frequency x P core count) + (max E core frequency x E core count)

Plotting those sum core frequencies by variant for each of the four families provides some interesting insights.

Here, each bar represents the sum core frequency of each full-spec variant. Those are grouped by the variant type (Base, Pro, Max, Ultra), and within those in family order (M1 purple, M2 pale blue, M3 dark blue, M4 red). Many trends are obvious, from the relatively low performance expected of the M1 family, except the Ultra, and the changes between families, for example the marked differences in the M4 Pro, and the M3 Max, against their immediate predecessors.

Sum core frequencies fall into three classes: 20-30, 35-45, and greater than 55 GHz. Three of the four chips in the M1 family are in the lowest of those, with only the M1 Ultra reaching the highest. The M4 is the first Base variant to reach the middle class, thanks in part to its additional two E cores. Two of the M4 variants (Pro and Max) have already reached the highest class, and any M4 Ultra would reach far above the top of the chart at 128 GHz.

Real-world performance will inevitably differ, and vary according to benchmark and app used for comparison. Although single-core performance has improved steadily, apps that only run in a single thread and can’t take advantage of multiple cores are likely to show little if any difference between variants in each family.

Game Mode is also of interest for those considering the two versions of the M4 Base, with 4 or 6 E cores. This is because that mode dedicates the E cores, together with the GPU, to the game being played. It’s likely that games that are more CPU-bound will perform significantly better on the six E cores of the 10-Core version of the iMac, which also comes with a 10-core GPU and four Thunderbolt 4 ports.

Memory and GPU

Memory bandwidth is also important, although for most apps we should assume that Apple’s engineers match that with likely demand from CPU, GPU, neural engine, and other parts of the chip. There will always be some threads that are more memory-bound, whose performance will be more dependant on memory bandwidth than CPU or GPU cores.

Although Apple claims successive improvements in GPU performance, the range in GPU cores has started at 8 and attained 32-40 in Max chips. Where the Max variants come into their own is support for multiple high-res displays, and challenging video editing and processing.

Thunderbolt and USB 3

The other big difference in these Macs is support for the new Thunderbolt 5 standard, available only in models with M4 Pro or M4 Max chips; Base variants still only support Thunderbolt 4. Although there are currently almost no Thunderbolt 5 peripherals available apart from an abundant supply of expensive cables, by the end of this year there should be at least one range of SSDs and one dock shipping.

As ever with claimed Thunderbolt performance, figures given don’t tell the whole story. Although both TB4 and USB4 claim ‘up to’ 40 Gb/s transfer rates, in practice external SSD performance is significantly different, with Thunderbolt topping out at about 3 GB/s and USB4 reaching up to 3.4 GB/s. In practice, TB5 won’t deliver the whole of its claimed maximum of 120 Gb/s to a single storage device, and current reports are that will only achieve disk transfers at 6 GB/s, or twice TB4. However, in use that’s close to the expected performance of internal SSDs in Apple silicon Macs, and should make booting from a TB5 external SSD almost indistinguishable in terms of speed.

As far as external ports go, this widens the gap between the M4 Pro Mac mini’s three TB5 ports, which should now deliver 3.4 GB/s over USB4 or 6 GB/s over TB5, and its two USB-C ports that are still restricted to USB 3.2 Gen 2 at 10 Gb/s, equating to 1 GB/s, the same as in M1 models from four years ago.

My choice

With a couple of T2 Macs and a MacBook Pro M3 Pro, I’ve been looking to replace my original Mac Studio M1 Max. As it looks likely that an M4 version of the Studio won’t be announced until well into next year, I’m taking the opportunity to shrink its already modest size to that of a new Mac mini. What better choice than an M4 Pro with 10 P and 4 E cores and a 20-core GPU, and the optional 10 Gb Ethernet? I seldom use the fourth Thunderbolt port on the Studio, and have already ordered a Kensington dock to deliver three TB5 ports from one on the Mac, and I’m sure it will drive my Studio Display every bit as well as the Studio has done.

If you have also been tempted by one of the new Mac minis, I was astonished to discover that three-year AppleCare+ for it costs less than £100, that’s two-thirds of the price that I pay each year for AppleCare+ on my MacBook Pro.

I look forward to diving deep into both my new Mac and Thunderbolt 5 in the coming weeks.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: Third prime should run at twice three or four, and four times two.

2: The third of XV brought AI for some.

3: If E > P and E + P = GPU what does E equal?

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

One of the novel features in the original Finder in Classic Mac OS was the use of distinctive icons for different types of document in an extensible scheme.

Every file had its type and creator codes, each consisting of four single-byte characters. The Desktop databases contained indexes to those, to enable the Finder to display the appropriate icon for a text document of type TEXT created by an app with the creator code of ttxt, SimpleText, for instance.

Apps provided a custom icon in their Resource fork for each type of document they supported. Periodically, those Desktop databases became broken, and documents lost their custom icons. The solution was to rebuild those Desktop databases from the data in each app’s Resources, a procedure that every Mac user became only too familiar with.

At some stage, perhaps in System 6 of 1988, or System 7 of 1991, document icons such as images could be displayed as miniatures or thumbnails instead. This was accomplished by apps creating that file’s thumbnail and saving it as an ICN# resource in the file’s Resource fork. Amazingly, this still works in Sequoia, where I pasted a prepared Resource fork into a Zip file to give it an inappropriate thumbnail.

The raw Resource fork is shown below in xattred as a com.apple.ResourceFork extended attribute.

Initially, Mac OS X continued a similar system, including custom thumbnails, until Apple introduced Quick Look in Mac OS X 10.5 Leopard, in 2007. This came with built-in support for a wide range of common document types, extending to QuickTime media including audio and video. One curious omission at first was that animated GIFs weren’t supported as animations until OS X 10.7.

Display of Thumbnails used the QuickLook framework documented here. This enabled third-parties to extend coverage to their own document types using QuickLook generators with the extension .qlgenerator. Initially, they were installed into /Library/QuickLook from each app bundle.

Normally, when QuickLook generated a Thumbnail or Preview, that was stored in its cache database kept in NSTemporaryDirectory in the path C/com.apple.QuickLook.thumbnailcache/. Those could give revealing insights into images and other documents accessed recently, and Wojciech Regula and Patrick Wardle discovered that, in High Sierra and earlier, it was easy for malicious software to examine that cache. Apple addressed that in macOS 10.14 Mojave by making the cache completely inaccessible.

In-memory caching of Thumbnails has also proved controversial in more recent versions of macOS. To deliver smooth scrolling of Thumbnails in the Finder’s Gallery views in particular, the Finder has taken to caching them in memory for up to two days, sometimes using several GB in the process. That can readily be mistaken for a memory leak, until those cached Thumbnails are finally flushed.

I described how QuickLook Thumbnails worked in early 2019, in the days before the SSV.

When you select a document in the Finder, a dialog, or somewhere else where you expect its icon to be shown, the Finder passes details of the document path and its type (UTI) to IconServices, to fetch the appropriate icon. This calls on its main service, iconservicesd in /System/Library/CoreServices, to check its icon cache.

Although the main icon store is locked away in /Library/Caches/com.apple.iconservices.store, there’s additional data in a folder on a path based on /private/var/folders/…/C/com.apple.iconservices, where … is an unreadable alphanumeric name. For icons used in the Dock, their cache is at /private/var/folders/…/C/com.apple.dock.iconcache. If the icon should be replaced by a QuickLook Thumbnail, such as in a Finder column view, QuickLook is asked to provide that thumbnail. That in turn may be cached in its protected cache at /private/var/folders/…/C/com.apple.QuickLook.thumbnailcache.

QuickLook then relies on there being an appropriate qlgenerator to create a thumbnail of that document type; if the qlgenerator is flawed or can’t cope with the document’s contents, that could easily fall over. For example, if you renamed a text file with a .jpeg extension so that macOS considered it was a JPEG image, the bundled qlgenerator might have simply resulted in the display of a busy spinner, rather than resolving to a generic JPEG document icon. IconServices should then deliver the appropriate icon back to the Finder to display it.

In macOS 10.15 Catalina (2019), Apple started replacing this system with a new framework named QuickLook Thumbnailing, documented here. That replaces qlgenerators with QuickLook preview extensions, in particular Thumbnail Extensions, as explained to developers at WWDC in 2019.

macOS 15.0 Sequoia has finally removed support for qlgenerators. That has resulted in the unfortunate loss of custom Thumbnails and Previews for document types of third-party apps that are still reliant on qlgenerators, and haven’t yet got round to providing equivalent app extensions. It’s almost as if the Desktop databases need to be rebuilt again.

We back up to ensure that we can recover files, whole volumes, our complete Mac if needed. When that crucial document you were working on earlier has vanished, or becomes damaged, or disaster strikes a disk, backups are essential. But how do you preserve all those documents that used to come on paper, records, correspondence and certificates? How will you or your successors be able to retrieve them in ten or thirty years time? This brief article considers how you should archive them safely, which isn’t the same as backing them up.

By archiving, I mean putting precious files somewhere they can be retrieved in at least ten years time. They may include financial, business, employment and personal records, as well as all finished work that you want to record for posterity. For most, they’ll also include a careful selection of still images, movies, and the more important documents you might create, such as books, theses and papers. They’re what you and the law want you to keep in perpetuity, and to be able to retrieve even after you’re gone.

To see how this can be achieved, I consider: the storage medium to be used, file formats that will be retrievable, how to index them for access, physical storage conditions, and the checks of their integrity that are needed.

Storage medium

While backups are most likely to be kept on hard disks or SSDs, neither of those is in the least suitable for archives, as they have relatively short lifetimes and are too sensitive to storage conditions. Instead, you need a removable medium, today probably Blu-ray disks intended for archival use, such as M-DISC.

For those with copious archives of importance beyond their family, Sony used to offer Optical Disk Archive systems, but those products were discontinued last year and don’t appear to have a suitable replacement. This illustrates one of the problems with planning for the more distant future: today’s technology can all too easily become orphaned.

Businesses are increasingly turning to cloud services to store their archives, but for the great majority of us the recurring cost makes this impractical. In any case, best practice should be to use cloud services as a supplement to a physical archive. iCloud is more affordable for the storage of most important documents, but requires a Legacy Contact to be appointed.

File formats

While it’s fine to archive documents in their original format, as you do in your backups, it’s also important to extract their contents into more permanent formats. Among those most likely to prove durable for the next 50-100 years are:

• UTF-8 (and formerly ASCII) for text files,
• JPEG and PNG for still images,
• audio, video and rich media using one of the widely-used compression standards and file formats,
• XML-based open document standards,
• CSV for data,
• PDF provided that it complies with one of the archival standards PDF/A-1 to /A-4.

You may find it worthwhile tarring together large collections of smaller files, but don’t use an unusual compression or ‘archive’ format, which might prove inaccessible in the future.

Indexing and access

For larger collections, even when structured carefully, a thorough list of contents in UTF-8 text format is essential. While there are index and search tools that could help, in this respect too archives are different from backups. If you’re going to be gathering TB of files, look at some of the commercial solutions. Although some are free to use, like the long-established Greenstone, they aren’t intended for casual users and might prove demanding.

Physical storage conditions

Never print on the disk itself, which can result in its degradation, and keep paper records alongside disks in the same container, but not inside the cases themselves, where they could damage them.

Archive optical disks should be stored in cases with centre hub security, not in sleeves. They must be kept in a cool, dry and dark container, in which there is no mould or fungus. They also need to be protected from physical threats such as flood and fire. Firesafes are popular furniture for this, but you must then ensure that their combination or keys are readily available and not separated from the safe.

There used to be a vogue for commercial data repositories, often underground storage sites that had been repurposed. Not only were those expensive, but many failed to take the care that they promised, and plenty went bankrupt and put their contents at risk. If you can arrange it, store one copy with you, and another at a friend’s or relative’s at least a few miles away.

Integrity checks

If you’re serious about maintaining your archives, some form of integrity checking, such as that provided by my free utilities Dintch, Fintch and cintch, is essential. Check a sample on each disk once a year, to ensure that none has started to deteriorate. If you do detect errors, that’s the time to burn a replacement before the original is lost to decay.

Conclusion

Backups are for recovery, while archives are for posterity. Start building your archives now, and keep them safe for the future.

Further reading

How to burn a Blu-ray disc in Monterey
Wikipedia point of entry

Postscript

Some of you are reporting widespread claims that some Blu-ray burners no longer work in Sequoia. I have therefore repeated the process that I described in Monterey, using exactly the same Pioneer burner connected to a Mac Studio M1 Max running macOS 15.1. I’m delighted to report that it still works perfectly, and I see no reason that any other recent Pioneer optical drive should prove incompatible. All you need to do is follow the instructions.

Happy archiving!

QuickLook is the subsystem in macOS responsible for providing two types of document preview, small Thumbnails and full Previews. If you’ve already upgraded to Sequoia, you’ll have noticed that some document types are no longer displayed with their custom Thumbnails or Previews. This article explains what has happened, and how it should work in the future.

As I’ll detail on Saturday morning, QuickLook (or Quick Look) is the latest in a series of methods for providing custom icons and previews for documents, that started back in the initial versions of Classic Mac OS. macOS ships with its own code to generate Thumbnails and Previews for a wide range of standard file types, from text and PDF to audio and movies. To extend these to other types, developers are encouraged to provide their own code.

Prior to macoS 10.15 Catalina in 2019, the display of Thumbnails was supported by the QuickLook framework. From Catalina onwards, this is provided by a new framework named QuickLook Thumbnailing. The older framework is documented here, and had been deprecated for some years. Its replacement is documented here. To extend these, the older framework used QuickLook generators with the extension .qlgenerator, but in the newer framework this function is provided by QuickLook preview extensions, in particular Thumbnail Extensions, that were explained to developers at WWDC in 2019.

As with most deprecated features, eventually the time comes for Apple to remove support for the old, and for QuickLook generators that has occurred in macOS 15.0 Sequoia. From now on, QuickLook Generator plugins no longer work. Oddly, those provided by macOS in /System/Library/QuickLook are still named with the old extension of .qlgenerator, but all custom support now has to use the new framework in App Extensions.

To check whether an app is still trying to use an old QuickLook Generator, look inside the app bundle in Contents/Library/QuickLook. If you see one or more .qlgenerator bundles there, then those no longer work in Sequoia. Instead, you should see new Thumbnail Extensions in Contents/PlugIns, where you should see App Extension bundles with names ending in something like Thumbnail.appex and QuickLook.appex. Some of the better apps provide both QuickLook Generators for compatibility with Mojave and earlier, and App Extensions for more recent macOS.

If the app you rely on to generate custom QuickLook Thumbnails and Previews doesn’t yet come with those App Extensions, contact their Support and ask them when they’re going to implement the changes brought five years ago in Catalina. Particularly if you’re paying them a subscription, it’s time they caught up. Until they do, I’m afraid those Thumbnails and Previews simply won’t work in Sequoia, and you’ll continue to see generic icons rather than Thumbnails.

Modern Macs and macOS feature multiple layers of protection, most of which I have recently described. This article tries to assemble them into an overview to see how they all fit together, and protect your Mac from startup to shutdown. There are also many additional options in macOS and third-party products that can augment security, but I’ll here concentrate on making best use of those that come with a modern Mac and macOS. My recommendations are for the ‘standard’ user, as a starting point. If your needs differ, then you may of course choose to be different, but should always do so in the full knowledge of what you are doing and what its penalties are.

Startup

Whether your Mac has a T2 or Apple silicon chip, it’s designed to boot securely, which means that every stage of the boot process, from its Boot ROM to running the kernel and its extensions, is verified as being as Apple intends. To ensure that, your Mac should run at Full Security. For a T2 model, that means disabling its ability to boot from external disks; for an Apple silicon Mac, that means no third-party kernel extensions. If you need to run your Mac at reduced security, that should be an informed decision when there’s no good alternative.

A vital part of the Secure Boot process is the firmware loaded by the Boot ROM. That needs to be kept up to date by updating to the latest minor release of the major version of macOS. That doesn’t prevent your Mac from staying with an older supported version of macOS, as Apple supplies the same firmware updates for all three supported versions of macOS.

The System volume should be signed and sealed, as the SSV created by a macOS installer or updater. System Integrity Protection (SIP) should also be fully enabled, as without it many macOS security features work differently or not at all. Some need to disable specific SIP features, but again that should only be set when you’re fully aware of their effects and consequences, and should be the minimum needed for the purpose.

User Data

Having got the system up and running, the boot process moves to what is in mutable storage on the Mac’s Data volume. In the internal SSD of a modern Mac, that’s always encrypted, thanks to the Secure Enclave. Although that might appear sufficient, you should always turn FileVault on if your Mac starts up from its internal SSD. That ensures the encryption is protected by your password: an intruder then has to know your password before they can unlock the contents of its Data volume. They have limited attempts to guess that password before the Mac locks them out from making any further attempts. As FileVault comes free from any performance penalty, there’s no good reason for not using it.

Good security is even more important for Data volumes on external boot disks, where FileVault is just as important, but needs additional physical measures to ensure the external disk isn’t mislaid or stolen. That’s a more complex issue, for which the simplest solution is to start your Mac up from its internal SSD with the benefit from FileVault there.

Run Apps

With the user logged in successfully, and the Data volume fully accessible, the next stage to consider is running apps and other software. For this there’s another series of security layers.

When an app is launched or other code run, Gatekeeper will first check it, and in many circumstances run a check for malware using XProtect. Those shouldn’t be disabled, or macOS will still make those checks, but will simply ignore the results. XProtect looks for evidence that the code about to be run matches that of known malware. Although on its own this won’t detect unknown malware, it’s an effective screen against what’s most common. You also need to keep your Mac up to date with the latest security data updates, as those can change every week or two as new malware is identified and included.

Currently, no well-known malware has been notarized by Apple, and most isn’t even signed using a trusted developer certificate. Most therefore attempt to trick you into bypassing checks made by macOS. In Sonoma and earlier, the most common is to show you how to use the Finder’s Open command to bypass the requirement for notarization. As that has changed in Sequoia, those who develop malware have had to adapt, and some now try to trick you into dropping a malicious script into Terminal. Expect these to become more sophisticated and persuasive as more upgrade to Sequoia.

There are simple rules you can apply to avoid getting caught by these. The first time you run any new app supplied outside macOS or the App Store, drag the app to your Applications folder and double-click it in the Finder to open it. If it can’t be launched that way, don’t be tempted to use the Finder’s Open bypass, or (in Sequoia) to enable the app in Privacy & Security settings. Instead, ask its developer why it isn’t correctly notarized. Never use an unconventional method to launch an app: that’s a giveaway that it’s malicious and you shouldn’t go anywhere near it.

macOS now checks the hashes (CDHashes) of apps and code it doesn’t already recognise, for notarization and known malware. Those checks are run over a connection to iCloud that doesn’t need the user to be signed in. Don’t intentionally or inadvertently block those connections, for instance using a software firewall, as they’re in your interest.

Private Data

Traditional Unix permissions weren’t intended to protect your privacy. Now so many of us keep important or valuable secrets in our Home folders, privacy protection is essential. While you might trust an app to check through some files, you may not expect or want that app to be looking up details of your bank cards and accounts.

Privacy protection is centred on a system known as TCC (Transparency, Consent and Control), and its labyrinthine Privacy & Security settings. One of the most tedious but important routine tasks is to check through these every so often to ensure that nothing is getting access to what it shouldn’t.

No matter how conscientious we might be, there’s always the request for access that you don’t have time to read properly, or items that end up getting peculiar consents, like a text editor that has access to your Photos library or your Mac’s camera. Take the time to check through each category and disable those you don’t think are in your best interests. If you get through a lot of new apps, you might need to do this every week or two, but it needn’t be as frequent in normal use, and shouldn’t become an obsession.

There’s some dispute over whether it’s better to leave an app turned off in a category that you control, like Full Disk Access, or to remove it. I tend to disable rather than remove, with the intention of removal later, but seldom get round to that.

Downloaded Apps

While macOS continues checking apps in Gatekeeper and XProtect, there are a couple of other important protections you need to know about. Since macOS Catalina, every 24 hours or so macOS runs a paired set of scans by XProtect Remediator, looking for signs of known malware. If it finds any, it then attempts to remove, or remediate, that. The snag is that it does this in complete silence, so you don’t know whether it has run any scans, and you don’t know if it came across anything nasty, or removed it. I like to know about such things, and have written my own software that lets me find out, in SilentKnight, Skint and XProCheck. One day Apple might follow suit.

Some browsers like Safari have a potentially dangerous setting, in which they will automatically open files they consider to be safe, once they have been downloaded. This can include Zip archives that might not be as innocent as you expect. If you leave that behaviour set, you could discover your Downloads folder with all sorts of items in it. I much prefer to turn that off and handle those downloads myself. You’ll find this control in Safari’s General settings, where it’s called Open “safe” files after downloading.

Bad Links

Most of the protection so far relies more on features in your Mac and macOS, and less on your habits and behaviour. But it’s the user who is the kingpin in both security and privacy protection. Nowhere is this more important than dealing with links in web pages, emails, messages, and elsewhere. If you’re happy to click on a link without checking it carefully, you can so easily end up in the company of your attackers, inviting them into your Mac and all your personal data.

Unless it’s a trusted web page or contact, I always inspect each link before even considering whether to open it. For emails, my general rule is never, and I inspect the text source of each message to see what that really links to. It’s harder on the web, where even ads placed by Google can whisk your browser into an ambush. One invaluable aid here is Link Unshortener, from the App Store, which is a ridiculously cheap and simple way to understand just where those cryptic shortened links will take you. If you can’t convince yourself that a link is safe and wholesome, then don’t whatever you do click on it, just pass on in safety.

Summary

That has been a whirlwind tour through getting the best from macOS security, summarised in the following diagram. Fuller details about each of those topics are easy to find using the Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s Platform Security Guide.

Work and play safely!

If your Mac is still running Sonoma or Ventura, and you have already updated it to 14.7.1 or 13.7.1, you might have noticed that neither updated Safari, nor has there been a separate update released yet for Safari 18.1.

According to release notes for Safari 18.1 (20619.2.8), this new version has already been released for Sonoma and Ventura, but as of 1600 GMT on 29 October 2024, there’s still no sign of any separate update, nor was it bundled in the x.7.1 updates.

Sonoma and Ventura had Safari 18 released for them on 16 September 2024, concurrently with Sequoia 15.0. On 3 October 2024, at the same time that Apple released Safari 18.0.1 in Sequoia 15.0.1, it also released Safari 18.0.1 for Sonoma and Ventura, without any CVEs being reported as fixed.

Current versions of Safari read:

• in Sequoia 15.1 – Safari 18.1 (20619.2.8.11.10)
• in Sonoma 14.7.1 – Safari 18.0.1 (19619.1.26.111.11, 19619)
• in Ventura 13.7.1 – Safari 18.0.1 (18619.1.26.111.11, 18619)

leaving the latter two due an update to Safari 18.1, which would ordinarily have been released with the x.7.1 macOS updates, but hasn’t been yet.

Update

As of 2150 on 29 October 2024, both Safari updates are now available through Software Update. Version and build numbers are 18.1 (19619.2.8.111.5, 19619) for Sonoma 14.7.1, and 18.1 (18619.2.8.111.5, 18619) for Ventura 13.7.1, and Apple lists the CVEs they address in this note.

Apple has made great play over the privacy provided in its new AI tools. If you’ve just updated your Apple silicon Mac to Sequoia 15.1 and are wondering how you can check on this for Writing Tools, this article explains how.

When running on a capable Mac, with an M-series chip, macOS captures details of all AI use in its Apple Intelligence Report (AIR). Control and access that from its new entry in Privacy & Security settings, where you’ll find it towards the end, just above the final Security section. Open that, and you’ll see you can set the Report Duration to 15 minutes, 7 days, or turn it off altogether. As report sizes can grow quickly with a little use of Writing Tools, I suggest you start off with 15 minutes, or you might get overwhelmed.

When you want to browse a report, simply click on the button to Export Activity, and save the AIR report.

Apple Intelligence Reports are written out to JSON files that can be viewed using a text editor if you don’t have a specialist JSON editor. They’re usually bulky, and much of their content may be encoded binary that’s of little meaningful use. However, at the start you’ll see a series of modelRequests.

Each modelRequest begins with the timestamp of the request, given in decimal seconds since 1970. That’s followed by a UUID, information on the prompt template used, and shortly after that is the text that was extracted and used by Writing Tools. For longer passages of text, you may see that it’s divided up into a series of shorter sections that match the paragraphs given in a summary.

After that input text, the language localisation is given, currently en_US as other variants and languages won’t be available until macOS 15.2 later this year. Next, the response is provided, as inserted into the Writing Tools or text window. That section ends with:

• model, the name of the AI model used, such as com.apple.fm.language.instruct_server_v1.text_summarizer, and the version.
• clientIdentifier, such as com.apple.WritingTools.xpc.WritingToolsViewService for normal use of Writing Tools in an app.
• executionEnvironment, currently expected to be PrivateCloudCompute, which tells you where the AI processing took place.

After the list of modelRequests, you’ll probably see a long series of privateCloudComputeRequests full of incomprehensible data for sepAttestations and provisioningCertificateChains, part of the validation information for use of PrivateCloudCompute. If this all seems a little long-winded, try looking in the logs when Writing Tools are in use!

I’m very grateful to Tim, who has drawn my attention to these reports, and points out that use of PrivateCloudCompute appears confined to macOS at the moment. A similar report is also available for iOS 18.1, but iPhones don’t appear to rely on PrivateCloudCompute in the same way.

We must remember that, while Apple considers Writing Tools now ready for general use, it’s still officially a beta-release, and over the coming months is likely to undergo significant change. This poses the question of whether Writing Tools will run on-device in the future, something only Apple can answer. What appears to happen at present is that the only local processing that takes place is tokenisation of text to prepare it for remote processing using Apple’s PrivateCloudCompute service, which actually performs the heavy lifting before returning its results to the Mac. However, macOS also appears to wake up the slumbering Neural Engine (ANE) for most Writing Tools services. Why that happens remains a mystery.

If you want to watch progress as AI features develop in macOS, you may find Apple Intelligence Reports a useful way to track that. If you do come across entries that seem to have used on-device services instead of PrivateCloudCompute, please let us know.

The macOS 15.1 update is the first scheduled update since Sequoia’s release last month, and brings with it a great many fixes as expected. From user reports, it’s believed to complete correcting problems reported with networking in 15.0, some of which were addressed in 15.0.1, although Apple hasn’t confirmed that.

Apple’s release notes are helpfully more detailed than usual, and include the following:

• new Writing Tools, but only for Apple silicon Macs set to US English as their primary language, with Siri also set to US English,
• a new-look Siri with Type to Siri for those who don’t want to talk to it, richer language understanding and context, and Apple product knowledge,
• Photos can find by description, and now features Clean Up to remove unwanted parts,
• Notifications has summaries, and a new Reduce Interruptions focus,
• Mail and Messages have Smart Reply for suggested responses,
• Notes has transcription summaries,
• iPhone Mirroring now supports drag and drop.

To clarify the requirement to get Writing Tools and other AI to work, the Mac must have an Apple silicon chip (M1 to M4), and:

1. in System Settings, General, Language & Region, the Primary language must be set to English (US), although any other language can be set secondarily, and made the current language in the keyboard menu, and
2. in Apple Intelligence & Siri, the Language set for Siri Requests must be English (United States), although you can turn Listen for Off if you don’t want to converse with Siri vocally.

Once those are set, you should be able to turn Apple Intelligence on. There will then be a short period on the waiting list, for macOS to download the additional models required. You’ll be notified when it’s ready to use.

Security release notes are available here, and list 50 entries, none of which Apple suspects may already have been exploited.

iBoot firmware on Apple silicon Macs is updated to version 11881.41.5, and T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.11072.0.0,0). The macOS build number is 24B83, with kernel version 24.1.0. There are no firmware updates for Intel Macs without T2 chips.

Significant changes seen in bundled apps include:

• Books, to version 7.1
• Freeform, to version 3.1
• iPhone Mirroring, to version 1.1
• Mail and Messages, large build increments
• Music, to version 1.5.1
• News, to version 10.1
• Passwords, to version 1.1
• Photos, large build increment
• Reminders, large build increment
• Safari, to version 18.1 (20619.2.8.11.10)
• Shortcuts, large build increment
• TV, to version 1.5.1
• Tips, to version 15.1.

Inevitably, there are many build increments in components related to Apple Intelligence. Other significant changes to /System/Library include:

• Audio/Plug-Ins/HAL MacAudio driver, to version 510.2
• CoreServices Desk View app, to version 2.0
• CoreServices Siri app, to version 3401.24.3.14.7
• Significant changes across many AGX and AppleEmbeddedAudio kernel extensions
• A new AppleT8140 kernel extension
• APFS is updated to version 2313.41.1
• Many public frameworks have updated build numbers, among them FileProvider
• A new ImagePlayground public framework, which has moved from being private, in anticipation of the new app coming in macOS 15.2
• Many private frameworks have substantial increments in build numbers, particularly Biome, Cloud, Email, Mail, Photo, Photos, Spotlight and FileProvider
• A new DesignLibrary private framework.

Although this isn’t a particularly large update, it does come with the first wave of AI features, and a wide range of other improvements and bug fixes.

Updated 2030 GMT 1 November 2024 with info on non-T2 Intel firmware updates.

As expected, Apple has released the update to macOS 15.1 Sequoia, together with security updates to bring Sonoma to version 14.7.1, and Ventura to 13.7.1. There should also be Safari updates to accompany the latter two.

The Sequoia update is around 2.9 GB for Apple silicon Macs, and about 2.4 GB for Intel models.

As expected, this brings the first release of Writing Tools, in the first wave of new AI features, only for Apple silicon Macs using US English as both their primary language, and that set for Siri. Apple hasn’t got round to providing any list of new or changed features, and you may find that offered by Software Update is the same as for 15.0.

Security release notes are available here for 15.1, which has around 50 entries, here for 14.7.1 with around 39, and here for 13.7.1 with around 36.

iBoot firmware on Apple silicon Macs is updated to version 11881.41.5, T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.11072.0.0,0), and Safari to 18.1 (20619.2.8.11.10).

I will post details of changes found later tonight.

[Updated 1820 GMT 28 October 2024.]

I hope that you enjoyed Saturday’s Mac Riddles, episode 279. Here are my solutions to them.

1: The first year it goes from London to Leeds with the First Eleven on its arm.

2: When intel brought the fifth big cat in a solo or duo.

3: When 6100-8100 came from the aim of seven.

The common factor

I look forward to your putting alternative cases.

Time Machine (TM) has evolved to be a good general-purpose backup utility that makes best use of APFS backup storage. However, it does have some quirks, and offers limited controls, that can make it tricky to use with more complex setups. Over the last few weeks I’ve had several questions from those trying to use TM in more demanding circumstances. This article explains how you can design volume layout and backup exclusions for the most efficient backups in such cases.

How TM backs up

To decide how to solve these problems, it’s essential to understand how TM makes an automatic backup. In other articles here I have provided full details, so here I’ll outline the major steps and how they link to efficiency.

At the start of each automatic backup, TM checks to see if it’s rotating backups across more than one backup store. This is an unusual but potentially invaluable feature that can be used when you make backups in multiple locations, or want added redundancy with two or more backup stores.

Having selected the backup destination, it removes any local snapshots from the volumes to be backed up that were made more than 24 hours ago. It then creates a fresh snapshot on each of those volumes. I’ll consider these later.

Current versions of TM normally don’t use those local snapshots to work out what needs to be backed up from each volume, but (after the initial full backup) should rely on that volume’s record of changes to its file system, FSEvents. These observe two lists of exclusions: those fixed by TM and macOS, including the hidden version database on each volume and recognised temporary files, and those set by the user in TM settings. Among the latter should be any very large bundles and folders containing huge numbers of small files, such as the Xcode app, as they will back up exceedingly slowly even to fast local backup storage, and can tie up a network backup for many hours. It’s faster to reinstall Xcode rather than restore it from a backup.

Current TM backups are highly efficient, as TM can copy just the blocks that have changed; older versions of TM backing up to HFS+ could only copy whole files. However, that can be impaired by apps that rewrite the whole of each large file when saving. Because the backup is being made to APFS, TM ensures that any sparse files are preserved, and handles clone files as efficiently as possible.

Once the backup has been written, TM then maintains old backups, to retain:

• hourly backups for the last 24 hours, to accompany hourly local snapshots,
• daily backups over the previous month,
• weekly backups stretching back to the start of the current backup series.

These are summarised in the diagram below.

Local snapshots

TM makes two types of snapshot: on each volume it’s set to back up, it makes a local snapshot immediately before each backup, then deletes that after 24 hours; on the backup storage, it turns each backup into a snapshot from which you can restore backed up files, and those are retained as stated above.

APFS snapshots, including TM local snapshots, include the whole of a volume, without any exceptions or exclusions, which can have surprising effects. For example, a TM exclusion list might block backing up of large virtual machine files resulting in typical backups only requiring 1-2 GB of backup storage, but because those VMs change a lot, each local snapshot could require 25 GB or more of space on the volume being backed up. One way to assess this is to check through each volume’s TM exclusion list and assess whether items being excluded are likely to change much. If they are, then they should be moved to a separate volume that isn’t backed up by TM, thus won’t have hourly snapshots.

Some workflows and apps generate very large working files that you may not want to clutter up either TM backups or local snapshots. Many apps designed to work with such large files provide options to relocate the folders used to store static libraries and working files. If necessary, create a new volume that’s excluded completely from TM backups to ensure those libraries and working files aren’t included in snapshots or backups.

TM can’t run multiple backup configurations with different sets of exclusions, though. If you need to do that, for instance to make a single nightly backup of working files, then do so using a third-party utility in addition to your hourly TM backups.

This can make a huge difference to free space on volumes being backed up, as the size of each snapshot can be multiplied by 24 as TM will try to retain each hourly snapshot for the last 24 hours.

Macs that aren’t able to make backups every hour can also accrue large snapshots, as they may retain older snapshots, that will only grow larger over time as that volume changes from the time that snapshot was made.

While snapshots are a useful feature of TM, the user has no control over them, and can’t shorten their period of retention or turn them off altogether. Third-party backup utilities like Carbon Copy Cloner can, and may be more suitable when local snapshots can’t be managed more efficiently.

iCloud Drive

Like all backup utilities, TM can only back up files that are in iCloud Drive when they’re downloaded to local storage. Although some third-party utilities can work through your iCloud Drive files downloading them automatically as needed, TM can’t do that, and will only back up files that are downloaded at the time that it makes a backup.

There are two ways to ensure files stored in iCloud Drive will be backed up: either turn Optimise Mac Storage off (in Sonoma and later), or download the files you want backed up and ‘pin’ them to ensure they can’t be removed from local storage (in Sequoia). You can pin individual files or whole folders and their entire contents by selecting the item, Control-click for the contextual menu, and selecting the Keep Downloaded menu command.

Key points

• Rotate through 2 or more backup stores to handle different locations, or for redundancy.
• Back up APFS volumes to APFS backup storage.
• Exclude all non-essential files, and bundles containing large numbers of small files, such as Xcode.
• Watch for apps that make whole-file changes, thus increasing snapshot and backup size.
• Store large files on volumes not being backed up to minimise local snapshot size.
• If you need multiple backup settings, use a third-party utility in addition to TM.
• To ensure iCloud Drive files are backed up, either turn off Optimise Mac Storage (Sonoma and later), or pin essential files (Sequoia).

Further reading

Time Machine in Sonoma: strengths and weaknesses
Time Machine in Sonoma: how to work around its weaknesses
Understand and check Time Machine backups to APFS
Excluding folders and files from Time Machine, Spotlight, and iCloud Drive

Early this coming week those fortunate enough to have an Apple silicon Mac will be able to update Sequoia to version 15.1 and try out Writing Tools at last. I’ve been testing and using them since the first beta of 15.1 back when the daylight lasted well into the night. I’ve been surprised at how lukewarm some have been at their arrival, particularly as most of those comments have come from those who make a living from their writing.

Perhaps the best way to show what Writing Tools can do is with an example, using the text from yesterday’s article A brief history of Mac firmware, a little over a thousand fairly technical words. I concentrate here on Writing Tools’ summary modes rather than its rewriting features, although they’re also thoroughly sound and useful in the right context.

Summary

Producing a succinct single paragraph summary is a challenge for even the most literate of humans. I’m impressed with Writing Tools’ 62 word offering of:
Mac firmware has undergone significant changes, from the Macintosh ROM in Classic Macs to Open Firmware in PowerPC models and EFI in Intel Macs. EFI, later evolving to UEFI, provides hardware access and boot services, while Apple silicon Macs employ a verified chain of trust for enhanced security. Firmware updates are now integrated into macOS installers and updaters, ensuring security and accessibility.

Key points

With so much information in the original, a key point summary should provide a better reflection of my original thousand words. Rather than reproducing the full 250 words generated by Writing Tools, here’s an excerpt covering one of the more challenging sections:

• Firmware Security Issue: Researchers demonstrated proof-of-concept attacks on Mac firmware, highlighting potential vulnerabilities.
• Firmware Update Policy Change: Apple transitioned from separate firmware updates to delivering them through system upgrades and updates.
• Firmware Security Concern: In 2017, Duo Labs researchers discovered many Macs running outdated firmware, raising security concerns.
• Apple’s Response: Apple hired security researchers and developed eficheck, a tool to check and report firmware versions to Apple.

I don’t think I could better that.

List

The third type of summary suitable for that article is a detailed list. This strips everything else out to leave terse factual sentences. For the whole text, it reduces to 833 words, a reflection on its already dense information. You’re unlikely to want to use this with longer passages, but here’s the same section given as key points above:

• In March 2015, two security researchers from LegbaCore demonstrated proof-of-concept attacks on the BIOS of several computers.
• The attacks could have been used to implant malicious code.
• Later that year, Kovah and Trammell Hudson turned their attention to Macs.
• They demonstrated a firmware worm named Thunderstrike 2.
• For the first nine years of Intel Macs, Apple had provided EFI firmware updates separately from updates to OS X.
• In 2015, Apple changed the way that it supplied firmware, delivering it only as part of system upgrades and updates.
• Although older separate firmware updates are still available, those were the last.
• In 2017, Rich Smith and Pepijn Bruienne of Duo Labs discovered that many Macs were running outdated firmware.
• Their concern was about the security risk posed by outdated firmware.
• Apple had already been busy hiring Xeno Kovah and Corey Kallenberg who started work there in November 2015, and Nikolaj Schlej, another firmware security researcher, who joined them the following August.
• They developed a new tool eficheck, released in High Sierra on 25 September 2017.
• eficheck checked current firmware against a local database of versions known to be ‘good’, and with the user’s permission sent a report to Apple in the event that it found discrepancies.

Table

The fourth summary option is to generate a table. Unfortunately, my example wouldn’t produce a useful table without substantial additional knowledge. However, I’ve found this useful on long passages from fiction, where it can summarise relationships between different characters, and similar tasks.

On device and on target

Once Sequoia 15.1 has been released and I’ve had a chance to explore the internals of Writing Tools further, I’ll look at its processing and energy costs. Two important features distinguish it from other contemporary AI tools: all data remains on-device throughout, and it’s primarily using your text rather than a large language model built from vast quantities of text garnered from around the internet.

Privacy doesn’t generally worry me particularly, as much of what I write on Macs is destined in some way or another to be published, whether it’s in an article here, one in the magazines that I write for, or source code that will be built into apps. However, I do take exception to others making money out of my labours without my express consent, so I’ll generally be only too happy to keep my AI on-device.

I also think it’s important to draw a clear distinction between what Writing Tools offers, and the likes of ChatGPT. Now that I’m testing Sequoia 15.2 beta, I have been looking at that contrast. While you can’t ask Writing Tools questions (why would you want to when you have the whole text and its summaries?), I thought I’d see how ChatGPT answered one of my stock test questions for AI: what is the SSV?

At my first asking, ChatGPT didn’t have sufficient context, and told me that it’s a side-by-side vehicle, so I refined my question to what is the SSV in macOS?

Although much of its answer was correct and informative, the second sentence stated with complete confidence that the SSV was introduced in macOS Catalina, which is of course completely incorrect, as Catalina has a read-only System volume but not a Signed System Volume as was introduced in Big Sur. But you’d only spot that serious factual error if you already knew the answer.

Give me Writing Tools and my own fact-checking, thank you.

Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.

1: The first year it goes from London to Leeds with the First Eleven on its arm.

2: When intel brought the fifth big cat in a solo or duo.

3: When 6100-8100 came from the aim of seven.

To help you cross-check your solutions, or confuse you further, there’s a common factor between them.

I’ll post my solutions first thing on Monday morning.

Please don’t post your solutions as comments here: it spoils it for others.

Firmware, software that’s intimately involved with hardware at a low level, has changed radically with each of the different processor architectures used in Macs.

Classic Macs based on Motorola 68K processors come with their own Macintosh ROM. That changed after the first PowerPC models of 1994, and the Power Macintosh 9500 from 1995 supports Apple’s version of Open Firmware. That had originated as OpenBoot in Sun Microsystems’ SPARC-based computers, and is based on the language Forth. Macs with Open Firmware can be booted into an interactive interface that makes it relatively straightforward to support and bring up new hardware. It’s also a security nightmare.

Firmware version numbering was elaborate, with a ROM revision, here $77D.45F6, a Boot ROM version of $0004.25f1, and a Mac OS ROM file version of 8.4, for this Power Mac G4 running Mac OS 9.2.1 in 2002. Apple supplied separate Mac OS ROM file updates as needed.

EFI

In 1998, Intel started work on the original Extensible Firmware Interface (EFI) as its intended replacement for the BIOS in PCs. By the time Apple was beginning its transition from PowerPCs in 2006, EFI was changing into Unified EFI (UEFI), and has since progressed as far as version 2.10 in 2022.

Once an Intel Mac has cleared its initial self-test routines (POST), and key custom chips like the SMC are running, EFI firmware is loaded next. The purpose of the EFI phase and the boot loader boot.efi is to augment the basic facilities provided by BootROM to the point where the macOS kernel can be loaded with its extensions. Key to this is providing access to the Mac’s hardware through the device tree, IODeviceTree, listing and relating all the devices in that Mac. This is built by boot.efi and passed to the kernel when it loads, and forms the basis for IOKit within macOS.

Model-specific boot.efi software also provides ongoing and additional support for boot services, including memory management, basic functions for timers and events, and for hardware access. It supports basic console protocols for input and output, and access to storage systems. Runtime services extend these to give access to variables stored in the NVRAM, and to GUIDs/UUIDs used for key variables in the EFI phase and later. Most importantly, boot.efi looks for startup key commands, originally named snag keys by Apple, such as Command-R to run in Recovery mode, Command-S and -V for Single User and Verbose modes, and Shift for Safe mode.

When Apple introduced Boot Camp in 2006, it made changes to boot.efi to support booting from operating systems other than macOS. This essentially provides a suite of drivers supporting Mac hardware in terms of a Windows hardware platform, engaged when the Mac is to be booted in that operating system rather than macOS.

Firmware security

In March 2015, two security researchers from LegbaCore, Xeno Kovah and Corey Kallenberg, demonstrated proof-of-concept attacks on the BIOS of several computers including Dell, HP, and other PCs that could have been used to implant malicious code. Later that year, Kovah and Trammell Hudson turned their attention to Macs, demonstrating a firmware worm named Thunderstrike 2.

For the first nine years of Intel Macs, Apple had provided EFI firmware updates separately from updates to OS X. That year, Apple changed the way that it supplied firmware, delivering it only as part of system upgrades and updates. Although older separate firmware updates are still available, those were the last.

Then in 2017, Rich Smith and Pepijn Bruienne of Duo Labs discovered that many Macs were running outdated firmware. Their concern was less about potential bugs and other problems, and more about the security risk posed. Apple had already been busy, hiring Xeno Kovah and Corey Kallenberg who started work there in November 2015, and Nikolaj Schlej, another firmware security researcher, who joined them the following August. They developed a new tool eficheck, released in High Sierra on 25 September 2017. Each week until it was dropped from Sonoma, eficheck checked current firmware against a local database of versions known to be ‘good’, and with the user’s permission sent a report to Apple in the event that it found discrepancies.

Back in late 2017, this iMac17,1 was reported as running Boot ROM version IM171.0105.B26.

T2 firmware

In 2016, the year before Smith and Bruienne’s report, Apple introduced first the T1 chip, then hot on its heels the T2 the following year. With two separate CPUs in each T2 Mac, there are two separate sets of firmware, one EFI and the other known as iBridge or BridgeOS. Following the established pattern, both are only updated by macOS installers and updaters.

After standard power-on self-test and SMC initialisation, the T2 sub-system establishes the level of Secure Boot in force, and, if that’s Full or Medium Security, boot.efi is checked before being loaded, providing security throughout the boot process.

Apple silicon Macs

The introduction of Macs using the M1 family of chips in 2020 brought complete change in firmware to support Secure Boot, and moves away from UEFI completely. The aim of boot security in Apple silicon Macs is to provide a verified chain of trust through each step in the boot process to the loading of macOS, that can’t be exploited by malicious components. This consists of four main stages:

• The Boot ROM in the hardware.
• The Low-Level Bootloader, LLB, or first stage.
• iBoot, or second stage.
• The macOS kernel, which loads all its required kernel extensions.

One of many changes made from UEFI is that startup key combinations have been replaced by the Power button to engage Recovery and other special startup modes, which has both improved security of Recovery mode and made its features more accessible. Instead of the user having to memorise a list of different key combinations required to access different features, all are now integrated within a single environment.

Apple silicon Macs are the first Macs whose firmware can be both upgraded and downgraded by restoring them from IPSW image files when the Mac has been put into DFU mode. For the time being, at least, all Apple silicon Macs run a unified firmware version tied not to the chip or model, but to the macOS version, and only delivered in IPSW files and macOS updates.

Apple provided developers with two Release Candidates of macOS Sequoia 15.1 this week. Provided there are no serious problems that come to light in the second of those, it’s likely that 15.1 will be released early next week, probably on Monday 28th. This article looks at what that brings, whether it’s safe to upgrade to Sequoia yet, and what comes next.

All supported Macs

Traditionally, the x.1 update is scheduled to be released about a month after the initial upgrade to a new major version of macOS, and brings with it the first wave of bug fixes, and a few features that weren’t quite ready in time.

Although there are reports of some other bugs in Sequoia, by far the most disruptive have been those affecting networking. Apple fixed the most serious of those in 15.0.1, released on 4 October, but some have continued to experience problems. Opinion from those testing betas of 15.1 are that it does resolve all those, and for the great majority should be ready for general use, provided that third-party apps are compatible. So if you normally wait for the x.1 version to be released before considering upgrading, this should fit the bill.

Apple does provide a list of fixes for developers, although as there’s no mention of any networking problems there, I suspect this isn’t of much help to users.

Apple silicon Macs

For those whose Macs run an M-series chip, the main interest in 15.1 is the first batch of Apple Intelligence features. Over the coming months, these should include:

• Writing Tools, a suite of mainly on-device features for summarising and rewriting text.
• Image Playground, producing synthetic images such as Genmoji, again using on-device methods.
• Siri and related enhancements for user assistance, using on-device methods.
• ChatGPT access, for more general AI features using text.
• App-specific enhancement to Photos, including Clean Up, and others.

Of those, 15.1 brings Writing Tools and some other enhancements, but doesn’t bring Image Playground or ChatGPT. Although some have claimed that makes 15.1 little better, that understates the value and quality of Writing Tools for many.

Writing Tools should be accessible to pretty well any recent app that displays significant amounts of text. Although I haven’t intended the lower text view in SilentKnight to support them, Writing Tools are available there from the contextual menu (Control-click). They work great with all the text editors I have tested, including TextEdit, BBEdit, CotEditor, Pages, my Rich Text editor DelightEd, and even in my PDF viewer Podofyllin.

The initial release of Writing Tools in 15.1 does have language and regional limitations. It requires that your Mac’s primary language, as set in Language & Region settings, is set to English (US), although you can still switch to a secondary language such as English (UK) if you prefer. The other key control is in the new Apple Intelligence & Siri settings, where Siri’s language needs to be English (United States). As I don’t like Siri’s spoken interface, I have disabled that by setting the Listen for control to Off, and instead enabled a Keyboard shortcut to open Siri’s interactive window.

Apple has announced future support for non-US variants of English, and next year for other primary languages. However, Writing Tools still work excellently on British English, even that of Charles Dickens, with the settings described above.

When you have updated or upgraded to Sequoia 15.1, I suggest you download text versions of books by your favourite author(s) from Project Gutenberg and explore features in Writing Tools using those as prose sources.

Future Sequoia updates

Apple has this week released the first beta-test of Sequoia 15.2, with most if not all of the other Apple Intelligence features, including Image Playground and ChatGPT. Assuming testing proceeds well and there are no serious problems, this is likely to be released in the first couple of weeks in December. Although not confirmed yet, this should open supported languages to include most major regional variants of English.

Slated for next year is the extension of Apple Intelligence to cover French, German, Italian, Japanese, Korean, Portuguese, Spanish, Vietnamese, and others. However, these features aren’t likely to appear in the countries of the EU this year, and Apple hasn’t yet indicated when that’s expected.

For those concerned about on- and off-device AI and privacy, all the standard features of Writing Tools and Image Playground involve on-device processing, and don’t send your data to remote servers. If you choose to enable ChatGPT access, then that is handled off-device, but is opt-in, and requires a separate sign-in process to access either an anonymised free account or an existing ChatGPT account. You can also require confirmation of any Siri requests handled with ChatGPT before sending any information off-device.

Apple has already published a list of fixes in the first beta of 15.2, although it remains to be seen what it does for users.

M4 Macs

Apple has also signalled that it will be releasing new Macs next week, widely rumoured to be the first to use the M4 chip.

Summary

• Sequoia 15.1 early next week, probably on 28 October, with Writing Tools in US English, and remaining networking bug fixes.
• Sequoia 15.2 already in beta, probably for release in early December, with Image Playground, ChatGPT, and the remainder of this first wave of AI tools, including most other English variants.
• Try Writing Tools out: I think they’re wonderful.

Earlier this week, I explained how the Signed System Volume (SSV), Data volume and cryptexes are integrated into the boot volume group, to support a secure boot process. This article outlines how modern Macs tackle the problem of booting securely.

The aim of a secure boot process is to ensure that all steps from the Boot ROM to the operating system are verified against any unauthorised change, and the code loaded and run is as intended. A simple operating system might achieve that by running only code contained in a boot ROM, but that’s woefully inadequate for any modern general-purpose operating system such as macOS, which also needs to be updated and upgraded during a Mac’s lifetime. Thus the great bulk of macOS has to be loaded and run from mutable storage, now SSDs. Those and a great deal else require specialised cores, with their own firmware, and features like the Secure Enclave. This is achieved in a cascade, where each step provides access to more of the Mac’s hardware, until many of Sequoia’s 670 kernel extensions are loaded and ready.

Intel Mac without T2 chip

Older models of Macs without a T2 chip follow a classic and insecure process when booting. Their Boot ROM loads UEFI firmware, and that in turn loads boot.efi, the macOS booter, without performing any verification. The macOS booter then loads the prelinked kernel from disk, again without verifying it. When the kernel opens the SSV, any checks on that can only be cursory, as Recovery for these Macs doesn’t offer controls in the form of a Startup Security Utility.

In High Sierra (2017), Apple introduced eficheck to periodically run checks on the version and integrity of UEFI firmware, although that doesn’t take place during the boot process, and was discontinued in macOS 14 Sonoma.

Intel Mac with T2 chip

These are the first Macs to support Secure Boot, thanks to their T2 chip, which is based on a variant of Apple’s A10 chip, dating back to 2016; the first model featuring a T2 chip was released at the end of 2017. As shown in the diagram at the end of this section, these Macs start their boot process with their Boot ROM verifying the iBoot ‘firmware’ for the T2 chip. That in turn verifies the kernel and its extensions for the T2, and that verifies the UEFI for the Intel side of the Mac.

Booting the Intel chipset proceeds similarly to older Intel Macs, but each step verifies the code to be run by the next, until its immutable kernel is loaded and boots the rest of macOS. Early in that stage, the kernel verifies the SSV before proceeding any further. Failure in any of the verifications halts the boot process, if you’re lucky in Recovery or T2 DFU mode.

This diagram compares boot processes in the three modern Mac architectures.

Apple silicon Mac

In the absence of any Intel chipset, Apple decided to implement its own Secure Boot, although there are options that could have allowed it to remain with UEFI. M-series chips tackle this in four steps:

1. Boot ROM, which verifies the Low Level Bootloader (LLB).
2. LLB, sometimes described as the first stage, concerned with loading and booting some auxiliary cores, security policy, and verifying the second stage, iBoot.
3. iBoot, which continues validations and verifications, including signatures and root hash of the SSV, before handing over to the kernel.
4. The kernel, which boots macOS.

Apple silicon chips contain many specialist cores responsible for implementing hardware features such as Thunderbolt. Firmware for each of those has to be verified and loaded to boot those cores, a task performed by LLB and iBoot.

Security policy for each boot volume group is set in its LocalPolicy, and has to be loaded and validated by LLB. The SSV is verified by iBoot prior to handing over to the kernel, to ensure the file system has been checked before it’s mounted.

When running in Full Security, the only kernel extensions to be loaded are those supplied in macOS, forming the standard Boot Kernel Collection. If the user has set that boot volume group to Reduced Security and opted for it to load third-party kernel extensions, those are contained in the Auxiliary Kernel Collection, and validated by iBoot. Once the kernel and extensions collection have been loaded, the latter is locked in memory with SCIP (System Coprocessor Integrity Protection) prior to iBoot handing over to the kernel to boot.

As with T2 Macs, any failure of verification during Secure Boot should leave that Mac either in Recovery mode, or in DFU mode ready to be connected to another Mac for its firmware to be refreshed, or restored from scratch.

External boot disks

T2 Secure Boot doesn’t support booting from an external disk, which is only allowed by reducing the security setting in Startup Security Utility. When designing its M-series Macs, Apple wanted them to benefit from Secure Boot when starting up from an external disk, and incorporated this into its design.

This is implemented by the Mac always starting the boot process internally, with the LLB and iBoot being run from internal storage. Bootable external disks must have an ‘owner’ to associate them with a LocalPolicy loaded by LLB. That enables iBoot to validate the Boot Kernel Collection, SSV and other components in the external boot volume group, then to hand over to its kernel to boot macOS from that disk, instead of the internal SSD.

It took a few versions of Big Sur before this worked reliably, but this should now be robust, provided that it’s set up correctly by the user. However, it’s often incorrectly claimed that Apple silicon Macs can only start up from external disks by reducing security.

Further reading

Apple’s Platform Security Guide:
Boot process for an Intel-based Mac
Boot process for a Mac with Apple silicon
Signed system volume security

This blog:
Booting an M1 Mac from hardware to kexts: 1 Hardware
Booting an M1 Mac from hardware to kexts: 2 LLB and iBoot
Booting an M1 Mac from hardware to kexts: 3 XNU, the kernel
Make a Ventura bootable external disk for an Apple silicon Mac
Booting macOS on Apple silicon: LocalPolicy
Ownership of Apple silicon Macs matters: how it can stop external bootable disks
Booting macOS on Apple silicon: Multiple boot disks

It’s essential to know when an authentication request is genuine. Without that knowledge, it’s all too easy to give your password away to malware, or to a badly-behaved app that’s trying to work around macOS security rules. By far the best way to authenticate now is using Touch ID, but many Macs don’t support it, either because they can’t, or because their keyboard doesn’t, and macOS doesn’t always offer it anyway. This article looks at how you can recognise genuine requests.

All Macs

The traditional non-biometric dialog is still in widespread use, and can appear on any Mac, even when Touch ID is available, and in Sequoia. I’ve been trying to work out a simple rule to predict when you should expect to see a classic request, and it appears to be associated with more traditional apps like Keychain Access, and when asking to access a file-based keychain such as the login keychain. But there don’t appear to be any simple and robust rules.

When an app needs to access a secret that requires authentication, the security system, not the app, displays a dialog asking you for the password to that keychain to authenticate before it will provide the password or other secret to the app.

That authentication dialog is very important: although malware might try to forge it, it contains distinctive features you should always look for:

• The icon consists of a locked padlock, on which is superimposed a miniature icon representing the app or component that has asked to access the keychain.
• The bold text names the app or component that has called for keychain access, and states which item it’s asking to access: here, a named secure note.
• The smaller lettering specifies that it’s asking for the keychain password, that is the password used to unlock the named keychain, not that for your Apple Account or any other password.
• If you’re in any doubt about its authenticity, click on the Deny button and the request will be denied.
• If you’re in any doubt about its authenticity, open Keychain Access, lock the keychain there, and repeat the action while watching the keychain to ensure that it’s unlocked and handled correctly.

Note that this doesn’t provide or ask for your user name, only the password for that keychain.

Macs without Touch ID

If Touch ID isn’t currently available to your Mac, either because it doesn’t support it, or because it doesn’t have a keyboard connected that includes Touch ID support, you should see the non-biometric versions of other dialogs requesting authentication. These are for purposes other than keychain access that require elevated privileges, such as for a process to run a privileged helper, or to make changes in System Settings.

This new vertical format should contain the following:

• The icon consists of a locked padlock, on which is superimposed a miniature icon representing the app or component that is asking for your password.
• Bold text names the app making the request.
• Below that is a general indication of the purpose of the request.
• Below that is the instruction to Enter your password to allow this.
• There are two text boxes, to contain your user name (already completed) and password.
• There are only two buttons, one of which may be OK or something more specific, and the other is Cancel.
• If you’re in any doubt as to its authenticity, click on the Cancel button to deny the request, and consult the app’s documentation.

Macs with Touch ID

If your Mac supports Touch ID (all Intel Macs with T2 chips, and all Apple silicon Macs), and currently has a keyboard connected to it with support for Touch ID, macOS should offer you the biometric version of that authentication dialog.

This should contain the following:

• The icon consists of a Touch ID fingerprint, on which is superimposed a miniature icon representing the app or component that is asking for your password.
• Bold text names the app making the request.
• Below that is a general indication of the purpose of the request.
• Below that is the instruction to Touch ID or enter your password to allow this.
• There are only two buttons, the upper being Use Password…, and the lower is Cancel.
• If you’re in any doubt as to its authenticity, click on the Cancel button to deny the request, and consult the app’s documentation.

This dialog has distinctive behaviour that’s difficult to forge. When you place your fingertip on the Touch ID button on the keyboard, it will either authenticate successfully, so dismissing the dialog, or the dialog shakes to indicate you should try placing your fingertip on the button again.

If Touch ID authentication fails, or you click on the button to Use Password…, the dialog expands to resemble the non-biometric version above, with the following two important differences:

• The icon still consists of a Touch ID fingerprint, with a superimposed miniature icon representing the app or component.
• The instruction remains to Touch ID or enter your password to allow this.

Although you will continue to encounter classic non-biometric authentication dialogs on a Mac with full Touch ID support, you may also come across some that you might have expected still to use the old dialog, but which now use a biometric dialog, such as that below.

Perhaps as Touch ID support extends this will become more consistent.

In macOS Mojave and earlier, all Macs booted from a single integrated volume, containing system and user files arranged in directories based on those common to many Unix systems. That started to change in Catalina, when that volume was divided into two, System and Data, and continued in Big Sur, when macOS started booting from a specially sealed and signed snapshot, the Signed System Volume or SSV. Changes since Big Sur have been smaller and more subtle, with the introduction of the paired recovery system and cryptexes. This article guides you around the volumes and directories that compose the boot volume group in macOS 15 Sequoia.

Internal SSD partitions

All Macs are now intended to be started up from their internal SSDs through a secure boot process that tries to guarantee the integrity of all loaded code from the boot ROM and firmware through to the kernel and macOS. This is simpler in an Intel Mac, whose internal SSD is divided into two partitions, one for EFI, the other for the boot volume group.

Device names given here are examples, and those seen are likely to differ.

The boot volume group is composed of:

• The System volume, used to build the SSV, which is unmounted during normal running.
• The Signed System Volume, a signed and sealed snapshot of the System volume, containing the immutable System.
• The Data volume, by default named Macintosh HD – Data, mounted within the System directory tree, and writable by the user.
• The small Preboot volume, used to store cryptexes.
• The paired Recovery volume, containing a disk image of the Recovery system.
• The VM volume as the backing store for virtual memory.
• Possibly an Update volume that appears to have been used when upgrading to versions of Big Sur. This won’t be present on more recent Macs, and appears to have been disused since macOS 11.

The SSV is created from the System volume during macOS installation and update, and features a tree of cryptographic hashes verifying its integrity, and its signature to verify that its contents match those expected for that version of macOS.

To accommodate the more advanced secure boot of Apple silicon Macs, their internal SSDs are divided into three partitions, with an extra six volumes beyond the boot volume group.

Device names given here are examples, and those seen are likely to differ.

Apple silicon Macs have two Recovery systems: their primary Recovery is run from a disk image in the paired Recovery volume in the active boot volume group, as with Intel models. A previous version of that disk image is stored in the Apple_APFS_Recovery partition/container, where it’s available as the Fallback Recovery system, only in Apple silicon Macs. The contents of the Apple_APFS_ISC partition are small, and largely support secure boot with extended anti-replay technology (xART) for the secure enclave, and other internal features.

Another more curious difference between architectures is that the default name of the Data volume differs: in Intel Macs, it’s normally Macintosh HD – Data, while Apple silicon Macs use just Data.

Inside the boot volume group

macOS now consists of three components:

• the SSV, providing the root file system, and consisting of the main immutable components
• the Data volume, mounted within the root and linked to it by firmlinks, consisting of user-writable directories
• cryptexes, signed and sealed disk images mounted from the Preboot volume during the boot process, containing components that can be updated without creating a new SSV, notably including Safari and its supporting frameworks, shared caches for dynamic loading and, in Apple silicon Macs, those to support Rosetta 2.

These can be traced using the volume IDs and inode numbers of directories and files within the unified file system presented to the user, and summarised in the diagram below.

Volume IDs and inode numbers given here are only examples, and you’re likely to see different ones.

This shows the location of major directories across the three components, with those located in the SSV shown in pink, those of the Data volume in blue, and contributions from cryptexes in green. The effect of firmlinks and ‘grafting’ of cryptexes into the file system is now complex. One important example is how what appears to be the single top-level Applications directory is assembled from:

• bundled apps in the SSV, located in /System/Applications,
• user-installed apps in /Applications in the Data volume,
• Safari.app mounted from the Preboot volume in the App cryptex.

Although the SSV is identical in both Intel and Apple silicon Macs, the two architectures are now differentiated by their cryptexes. Those for Intel Macs contain only dyld shared caches with x86 support; those for Apple silicon Macs provide both ARM and x86 support, as well as AOT shared caches, for Rosetta 2.

Firmlinks

System firmlinks are still the same as listed previously in /usr/share/firmlinks and haven’t changed since Catalina:
/Applications <-> Applications
/Library <-> Library
/System/Library/Caches <-> System/Library/Caches
/System/Library/Assets <-> System/Library/Assets
/System/Library/PreinstalledAssets <-> System/Library/PreinstalledAssets
/System/Library/AssetsV2 <-> System/Library/AssetsV2
/System/Library/PreinstalledAssetsV2 <-> System/Library/PreinstalledAssetsV2
/System/Library/CoreServices/CoreTypes.bundle/Contents/Library <-> System/Library/CoreServices/CoreTypes.bundle/Contents/Library
/System/Library/Speech <-> System/Library/Speech
/Users <-> Users
/Volumes <-> Volumes
/cores <-> cores
/opt <-> opt
/private <-> private
/usr/local <-> usr/local
/usr/libexec/cups <-> usr/libexec/cups
/usr/share/snmp <-> usr/share/snmp
/AppleInternal <-> AppleInternal (on Apple engineering systems only)
in each case shown as the system volume path and the Data volume path which are firmlinked together.

Directory layout

Given the volume ID and inode numbers of directories and files, together with that list of firmlinks, it’s possible to construct a full directory tree for the conjoined SSV, Data volume and cryptexes. A simplified version of that is in the diagram below.

This uses the same colour convention, with pink for the SSV, blue for the Data volume, green for cryptexes, adding red for the mountpoint of the Data volume, and yellow for firmlinked items. This demonstrates graphically how the contents of the main Applications folder are gathered from three sources.

Previous boot volume architectures from High Sierra to Monterey are explained here.

I hope that you enjoyed Saturday’s Mac Riddles, episode 278. Here are my solutions to them.

1: Platform executive arranges props and lighting for window groups.

2: Blank characters open in parks for multiple desktops.

3: Regulate operational flight to exposé them all.

The common factor

I look forward to your putting alternative cases.

Of the two most dependable types of disk image, read-write (UDRW) disk images are the simpler. The only options you can set are its internal file system, whether the container is encrypted, and its maximum capacity. From there on, macOS will automatically Trim the disk image when it’s mounted, and adjust the size it takes on disk accordingly.

Sparse bundles can be more complex to configure in the first place, and may need routine maintenance to ensure their size on disk doesn’t grow steadily with use. This article considers how significant those complications are.

Band size

Most if not all storage divides data into blocks; in the case of SSDs, the default block size in APFS is 4,096 bytes, and that’s effectively the unit of storage in the single file of a read-write disk image.

Its equivalent in a sparse bundle is the maximum size that each of its band files can reach, normally set to 8.4 MB in macOS Sequoia and its predecessors, and equivalent to slightly more than 2,000 SSD blocks. Smaller band sizes are more efficient in the space required to store the contents of a sparse bundle, but require more band files for the same quantity of data stored. Experience with older versions of macOS suggests that it’s not a good idea for the total number of band files to exceed 100,000, but I’m not aware of any recent evidence to support that.

When creating very large sparse bundles, of the order of TB, macOS now may adjust the band size to limit their number. Some users report that those sparse bundles perform better as a result, for instance when being used to store backups on a network. There don’t appear to be any advantages to using band sizes less than 8.4 MB.

Neither DropDMG nor Disk Utility currently appear to allow any control over band size; Spundle and hdiutil not only let you specify custom band sizes when creating sparse bundles, but also allow you to change band size by copying an existing sparse bundle into a new one, which could be useful if you were changing the maximum size of a sparse bundle.

Compaction

Each time a writeable APFS or HFS+ file system is mounted in a disk image, including both sparse bundle and read-write types, storage blocks that are no longer in use should be returned for reuse by the process of Trimming. This is automatic, and in the case of single-file read-write disk images, is the only maintenance that occurs.

Because sparse bundles add another layer of band files over SSD storage, they too require periodic maintenance in the process of compaction. To compact a sparse bundle, macOS scans the band files and removes those that are no longer being used by the file system in the sparse bundle. This only applies to sparse bundles with APFS or HFS+ file systems, though, and isn’t guaranteed to free up any space. One small catch is that, by default, compaction won’t take place on a notebook running on battery power; hdiutil and Spundle provide an option to override that.

Space efficiency in use

I’ve been unable to find any objective comparison between space efficiency of modern read-write disk images and sparse bundles, so have performed my own on a USB4 external SSD connected to my Mac Studio M1 Max. I created two test cases of 125 GB images on a freshly-formatted APFS volume, one a sparse bundle with the default 8.4 MB band size, the other a read-write disk image (UDRW). In macOS Sequoia 15.0.1, the initial size they took on disk was 14.8 MB for the sparse bundle, and 336 MB for the disk image.

Using my utility Stibium, I then wrote and deleted a series of files in each, as follows:

1. 160 files of 2 MB to 2 GB written totalling 53 GB
2. 40 largest of those, sizes 600 MB to 2 GB, were then deleted, leaving 120
3. another 160 files written totalling 53 GB
4. 40 largest of those deleted, leaving a total of 240
5. another 160 files written totalling 53 GB
6. 40 largest of those deleted, leaving a total of 360
7. another 160 files written totalling 53 GB
8. 40 largest of those deleted, leaving a total of 480
9. another 160 files written totalling 53 GB, leaving a total of 640 files.

At that point, the sparse bundle had 104.08 GB stored in 12,408 band files, and the read-write disk image had 91.63 GB stored in its single file. I then deleted all files and folders in each of the images, and unmounted and remounted each image several times to ensure Trimming had completed. The sparse bundle then had 1.12 GB in 135 band files, and offered 124.66 GB of free space when mounted; the read-write disk image was slightly smaller at 937.9 MB on disk and offered exactly the same amount of free space when mounted.

Compacting the empty sparse bundle was reported as reclaiming 52.3 MB, and reduced the disk space taken by the band files slightly to 1.06 GB while retaining the same number of bands, and still offering 124.66 GB of free space when mounted.

In this case, following writing 800 files totalling over 250 GB, and deleting a total of 160 of them, compaction made a remarkably small difference to the free space returned following removal of all files. There is also very little difference in the space efficiency of sparse bundles and modern read-write disk images.

One consistent difference observed throughout was in write speeds: they remained constant at 3.2 GB/s for the sparse bundle, and 1.0 GB/s for the read-write disk image, as reported here previously.

Conclusions

• Sparse bundles are more complicated than read-write disk images (UDRW), with band size to be set, and compaction to be performed.
• Default band size appears to work well, and manually setting band size should seldom be necessary.
• Both types appear highly efficient in their use of disk space, with only small differences between them.
• Although it might be important to compact sparse bundles in some cases, the amount of free space returned by compaction is unlikely to be significant in many circumstances.

Previous articles

Introduction
Tools
How read-write disk images have gone sparse
Performance

I don’t recall seeing any Apple app promoted from the ranks as fast as Tips. It didn’t exist in Monterey, when it was still the neglected HelpViewer app lingering unloved in CoreServices. Then in Ventura it took on its new name, while staying hidden, as it remained in Sonoma too. Come Sequoia, it has leapt from version 10 to 15 and joined Apple’s first league apps between Time Machine and TV in the main Applications folder.

We can all recall the fall from grace of Network Utility and now Keychain Access, in leaving the main Utilities folder to go to their demise in CoreServices, but I don’t remember any other app making that trip in reverse, and so quickly. Of course, the app that now presents itself as Tips knows that it’s still actually com.apple.helpviewer inside, so is this real change, or merely cosplay?

When researching articles here, in most cases my first task is to consult Apple’s support documentation, in both Help pages and its extended support articles. The Tips app could now be a useful front end for that, although it doesn’t seem to offer anything more than a search in Safari does, and in some respects isn’t as helpful. Try searching Tips for terms like pin or pinning and you’ll see anything but its use in iCloud Drive, for which only the official phrase keep downloaded proves fruitful.

Tips currently appears stunted in other respects. Although it reluctantly gives access to the contents of third-party Help books, provided they’re in the traditional format and not PDFs, the only ones it offers for browsing are those for Apple’s apps. Disappointingly, it can’t find or open any man pages, where Apple now keeps a lot of more important information, for which you still have to open Terminal or resort to a third-party alternative.

It’s only when browsing Apple’s own documentation that you realise how much of it now lacks illustrations. Its model-specific hardware guides are the exception, and are accompanied by excellent labelled images, but Tips limits those to currently shipping models. If your Mac is Apple silicon but more than a year or two old, then you’ll just have to resort to the web. Sections aimed at the novice, such as Set your Apple Account picture, are well supported by cutouts from screenshots. But look at Store files in iCloud Drive, and there are five substantial topics with just a single lightbulb icon and no screenshots.

For me the biggest disappointment is that Tips only offers what’s readily available, in terms of technical content. If it isn’t in an existing Help book, then Tips draws a blank. Search for DFU mode, restore firmware, or even how to restore mac firmware, and Tips can’t find anything to suggest from among the main Help books. Extending its scope to include All Topics only finds useful results if you already have Apple Configurator installed, in which case it’s surely simpler just to open that app’s Help book directly, as Tips doesn’t include it in its list of User Guides either. This is all the more disappointing, as Apple has published an excellent support article entitled How to revive or restore Mac firmware, readily found by searching in Safari, but apparently beyond the scope of Tips.

This initial version feels clunky in other respects. Most annoyingly, it’s incapable of remembering what you were last reading. Every time you open the Tips app, it returns to its default home page, rather than restoring its contents to those shown when you last quit the app. As there’s no means of bookmarking items, you’ll find yourself wasting a lot of time navigating back to information you’ve already found. Neither does the app support more than its single window, and has no way of splitting that to allow you to refer to two or more pages at the same time.

In its current state, it’s hard to see how it justifies its place among Apple’s first league apps, which makes me wonder whether it’s destined to use AI in a future release of Sequoia. However, for that to be any improvement, Tips is going to have to broaden and deepen its knowledge, or it may as well crawl back to CoreServices and its former name of HelpViewer.