Open System Settings, then General, and Login Items & Extensions. Scroll to the end of that list and you’ll see a section titled Extensions. All looks tidy there and in order, but you’re looking at the tip of the iceberg. Click on the ⓘ button at the right of any of those entries, and prepare to be thoroughly confused. These aren’t, of course, kernel extensions, nor are they only system extensions (although some may be), they’re app extensions, conveniently shortened to appexes, the subject of this article.

System Settings

That section in System Settings is unusual as its list depends entirely on what you have installed on your Mac. Among those you’re most likely to see are:

• Actions allow access to an app’s functions from within other apps, such as Markup provided by macOS.
• Dock Tiles customise the Dock and normally run in the background (although not listed in Background items above), including several phantom ‘apps’ added by macOS.
• File Providers allow you to see both local and remote-storage files together in the Finder, and normally run in the background (although not listed in Background items above). Note this isn’t confined to ‘file providers’ in the sense of cloud services like iCloud Drive.
• File System Extensions, userland file systems, including ExFAT and MSDOS in macOS 15.4, which are intended to replace kernel extensions.
• Finder provides enhanced search and other functions for files and more. These can also be accessed directly through the Quick Actions item in the Finder’s contextual menu.
• Photos Editing provides enhanced editing in the Photos app. This also includes Markup provided by macOS.
• Quick Look includes custom QuickLook thumbnail and preview extensions, replacing qlgenerators.
• Sharing includes features provided in the Share menu. These include some from macOS that can’t be disabled, such as Mail and Messages, others that are optional, as well as third-party apps.
• Spotlight includes custom mdimporter modules to extract indexable content from custom file types not supported by macOS.

To add to the uncertainty, not all those available in Sequoia 15.4 are listed in the Mac User Guide’s total of 17 classes, or Apple’s list of 25 for developers.

Where are appexes?

Most of these are installed as .appex bundles inside a PlugIns folder inside the bundle of an app, although some can instead be in a Library folder inside the app. The best information about each is in the Info.plist file in their appex bundle. In that, the nested dictionary of NSExtensionAttributes is most informative. That gives the NSExtensionPointIdentifier type, which for a QuickLook appex might be com.apple.quicklook.preview, indicating that it generates custom previews for QuickLook, in the way that qlgenerators used to. That type corresponds to the SDK entry listed by pluginkit, described below.

Not all appexes are exposed in System Settings, though. New-style drivers supplied in .dext bundles, that are listed as extensions, aren’t included despite there being 17 bundled in macOS 15.4. There’s also no mention of nearly 200 appexes provided in /System/Library/ExtensionKit/Extensions.

pluginkit

In addition to their control in System Settings, the command tool for working with appexes is pluginkit. Most of its options are aimed at those developing and debugging their own appexes, but there’s one command that will dump details of all managed appexes to a lengthy text file, with a form like
pluginkit -m -vv > ~/Documents/pluginkitOut.text
which pipes its output to the file at ~/Documents/pluginkitOut.text. You can add another v to the options for greater details.

The output from pluginkit reveals just how many appexes there are, possibly as many as 500 or more installed in your Mac. Most are system components that aren’t exposed in System Settings, and many have SDK names, specifying their type, that fall outside the categories listed by Apple. For instance, there’s a com.apple.CloudDocs.iCloudDriveFileProvider appex buried deep in the CloudDocs private framework that has an SDK type of com.apple.fileprovider-nonui for iCloud Drive.

Anomalies

Extensions settings currently appears to be a work in progress. It’s among the most opaque sections in System Settings, with all of its controls accessed through ⓘ buttons and floating windows, rather than being laid out clearly. It’s riddled with inconsistencies, and some sections don’t appear to work properly, most notably Quick Look.

This screenshot shows that Apparency’s Quick Look appex is currently disabled, but at the right is a QuickLook preview demonstrating Apparency’s customisation. This applies to other custom Quick Look appexes in Sequoia 15.4: when apparently disabled, they continue to work normally.

As system qlgenerators aren’t included in the Quick Look list, it can’t be used to disable those to allow third-party appexes to generate thumbnails and previews instead, which might have been a useful function.

Summary

• Appexes are app extensions, now found in the PlugIns or Library folders within app bundles.
• Although some appexes are also system extensions, or their relatives, most aren’t, and simply extend that app’s features.
• Many appexes are controlled in System Settings > General > Login Items & Extensions, at the end.
• Lists shown there vary according to which types of appex are installed. Click on the ⓘ button to view and control them.
• Some system appexes are listed but can’t be disabled, while others can be.
• They can also be controlled and listed using the pluginkit command tool, although that’s not straightforward.
• In Sequoia 15.4, Quick Look appex controls appear dysfunctional.

References

man pluginkit
Apple’s developer master page with links to documentation
QuickLook and its appexes
Dock tile appexes.

APFS has two special file types designed to economise on storage space: clone and sparse files. Clone files are two or more distinct files within the same volume whose data is shared; sparse files save space by skipping empty data and only storing data containing information. This article explores how they behave in use, with particular emphasis on Time Machine backups and iCloud Drive. The latter also involves a third type of special file, dataless files.

Clone files

In contrast to hard-linked files, clone files are two or more distinct files within the same file system (volume) whose file extents are identical, so share the same data, as shown below. They’re created by variants of normal file copying, including duplicating in the Finder (and drag-copying within the same volume), and the cp -c command.

Instead of duplicating everything, only the inode and its attributes (blue and pink) are duplicated, together with their file extent information. You can verify this by inspecting the numbers of those inodes, as they’re different, and information in the attributes such as the file’s name will also be different. There’s a flag in the file’s attributes to indicate that cloning has taken place. At first, the two cloned files share the same data blocks and extended attributes, but as the two files are changed by editing, they start to drift apart and become uncloned.

Clone files are becoming more popular thanks to the Hyperspace app, which deduplicates files within the same volume by replacing copies with clones.

Because they can only exist within the same file system, clone files are fragile. Any copy or move to another file system is invariably accompanied by the copying of their full data, and their economy of storage can only remain as long as they stay within the same volume.

Backups

One notable exception to this same-volume rule is in Time Machine backups. As clone files are preserved in local snapshots, when Time Machine constructs a backup as a snapshot in the backup storage volume, shared file extents are retained, so preserving clones. This is reflected in the size of the backup snapshot, and in the report written to the log. For example, when backing up three distinct files and ten clones of one of those, that report included:
14 Total Items in Backup (l: 16 GB p: 11.02 GB)
3 Files Copied (l: 6 GB p: 1.02 GB)
1 Directories Copied (l: Zero KB p: Zero KB)
10 Files Cloned (l: 10 GB p: 10 GB)

Backups made by other utilities are unlikely to reproduce this behaviour, though, as they can’t synthesise snapshots in the way that Time Machine does. To preserve clone files in their backups, they’d have to identify clones in the source and explicitly perform cloning in their backup store. Although Carbon Copy Cloner claims that “in some cases CCC may clone a file on the destination prior to updating its contents”, it doesn’t appear to attempt to preserve clone files in the backups it makes. I’m not aware of any third-party utility that does.

Unfortunately, Time Machine appears unable to restore directly from backup snapshots in the backup store, and performs Finder copies when restoring. That saves each of those clone files as a completely separate file, without any sharing of data. As a result, the space occupied on disk for a restored volume can be substantially greater than the original or its backup. Extensive use of clone files could thus cause problems when restoring from backups.

Of course, rolling a volume back to a local snapshot, such as one made during Time Machine backups, preserves all clone files within that volume.

iCloud Drive

Clone files created within the same volume as local iCloud Drive storage on the Data volume, or cloned when within a folder in iCloud Drive, remain within the same file system and clones are therefore preserved, and when the file is moved to other folders in the same volume.

However, clone files are treated as simple copies as far as iCloud Drive’s remote storage is concerned. While a pair of cloned 5 GB files only use a total of 5 GB local storage, they require a full 10 GB of your iCloud allocation, indicating that their cloud storage is separate and not common to both. Although the effects of eviction (removing local data) and materialisation (restoring local data from cloud storage) are difficult to observe directly, they appear to lose the benefits of cloning.

When the local copy of a file also stored remotely in the cloud is evicted, its data is removed from local storage, rendering it dataless, as shown below.

When that file is to be used locally again, its data has to be downloaded from the cloud service, and the local dataless file is materialised by adding its data back. As far as I can tell, that doesn’t result in the reconstruction of the shared file extents, so changes cloned files into normal copies with different file extents. You would then need to use Hyperspace to restore them as clone files. Other Macs sharing the same iCloud Drive also see them as full copies rather than clones.

These behaviours could also catch the user by surprise.

Sparse files

Unlike clone files, the structure of sparse files in APFS is conventional, as shown below.

They achieve their economy in storage by only including file extents containing non-null data, and thus aren’t dependent on remaining within the same file system (volume), making them more robust. Their primary requirement is that they’re created and maintained using specific file system operations, and are only copied or moved to other APFS file systems.

Backups

When backed up by Time Machine to another APFS volume, sparse files are preserved reliably, and are also restored as sparse files. That isn’t likely to hold, though, if the file is transferred using a network file system such as SMB, as all network transfers currently appear to explode sparse files to full size prior to transfer. Because of the way in which they have to be created, only the app maintaining that file could restore its sparse format. In the case of disk images, this should normally occur the next time they’re mounted in the Finder and Trimmed by APFS.

iCloud Drive

Assessing what happens with sparse files in iCloud Drive is considerably simpler than with clone files. As long as they remain downloaded to local storage, they are preserved, and can be moved in and out of iCloud Drive storage without exploding in size. However, they too are stored in full when in iCloud storage, requiring their full size in your iCloud allocation, and the eviction-materialisation cycle explodes them to full size, and their sparse file flag is removed.

The only way to return a former sparse file to its original economical format is then to open and save it using the app that creates and maintains it. In the case of disk images, this should occur when they’re next mounted and Trimmed.

Conclusions

Clone files:

• are only preserved when moved within the same file system (volume);
• are preserved and restored from local snapshots;
• are preserved in Time Machine backups, but aren’t restored from them;
• aren’t preserved in other backups;
• could result in a restored volume being substantially larger than its original;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can be regenerated using Hyperspace.

Sparse files:

• are only preserved when copied or moved directly between APFS volumes;
• aren’t preserved when copied or moved over network connections, or using SMB;
• aren’t preserved when copied or moved to different file systems, including HFS+;
• are preserved in and restored from local Time Machine backups;
• should be preserved in and restored from other local backups;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can only be regenerated by the app that creates and maintains them.

Both clone and sparse files can result in substantial savings in storage space. However, because that’s fragile, their greatest value is in minimising erase-write cycles in SSDs, hence slowing their ageing.

References

Apple’s APFS Reference (PDF), last revised 22 June 2020.
Dataless files are explained here.
How sparse files work
Files and clones
Special file types, including dataless files

Lambing dates remain one of life’s great mysteries. Here in the UK, farmers in the north usually lamb earliest, often only just after Christmas when it’s usually bitter cold and snowy up there. Down here in the balmy south, lambs are born three months or more later, typically in April, when they’re often struggling to keep cool in the sunshine. Last week we saw the first of this year’s lambs, and Apple’s Spring OS fest, including Sequoia 15.4.

Size

That update was large, but that isn’t exactly unusual:

• 7 March 2024, Sonoma 14.4 was 3.6 GB (Apple silicon) with 64 vulnerabilities fixed, “the most substantial update of this cycle so far”;
• 27 March 2023, Ventura 13.3 was 4.5 GB with 49 vulnerabilities fixed, being “substantial, and brings many improvements and fixes”;
• 14 March 2022, Monterey 12.3 was 5.3 GB with 45 vulnerabilities fixed, being “very substantial, introducing major new features like Universal Control and Spatial Audio, changing several bundled apps, and fixing many bugs”;
• 26 April 2021, Big Sur 11.3 was 6.62 GB with over 50 vulnerabilities fixed, “the largest update to macOS since Mojave, and quite possibly the largest ever”.

(Figures and quotations from links here.)

Although the 15.4 update wasn’t quite as large as 11.3, at 6.2 GB for Apple silicon, it has comfortably surpassed it in the number of vulnerabilities fixed, 131 in all, and came close to the size of the 15.0 upgrade at 6.6 GB. What’s most disappointing is that, while the first release of Sequoia merited long and detailed accounts of much of what had changed, for 15.4 there’s precious little information beyond its lengthy security release notes.

A stroll through the version numbers of its bundled apps and /System/Library confirms the extent of changes. There was no point in my trying to compile an article listing them, as it might have been briefer to report what hasn’t changed. What’s more to the point is what’s new in 15.4, what are its Spring lambs?

Novelties

Among the new kernel extensions is the first version of AppleProcessorTrace, and there’s a brace to support hardware in Apple silicon chips including a T6020 and T8103 for PCIe, and a T6032. Those appear to be for M2 Pro, M1 and M3 Ultra chips, respectively. There are two new public frameworks, one named CLLogEntry that is presumably for Core Location log entries, the other tantalisingly named SecurityUI. Neither seems to align to anything in Apple’s developer documentation, so might be preparing the ground for what we’ll hear about in early June at WWDC, when the lambs have grown a bit.

I keep a track of the total number of bundles in several of the folders in /System/Library. Since the release of Sequoia 15.0, that containing Private Frameworks has grown from 4,255 to 4,398. Because of their layout, this total overestimates the real change in numbers, and that probably represents a true growth of around 70 Private Frameworks in Sequoia so far.

These Private Frameworks contain code features used privately by Apple’s apps, but not exposed to third-party developers. Although much is of little or no use or advantage, they also contain much that supports changing features in macOS. Using Private Frameworks is a sure way to madness, and something explicitly forbidden in the App Store, but, like the unaffordable car or boat we like to gloat at, there’s no harm in wondering what they will bring in the future.

The list of new Private Frameworks in Sequoia 15.4 is long, and includes: AUSettings, Bosporus, ComputationalGraph, CoreAudioOrchestration, CryptexKit, CryptexServer, DailyBriefing, DeepVideoProcessingCore, Dyld, ExclaveFDRDecode, FPFS, FindMyPairing, various GameServices, GenerativePlaygroundUI, MCCFoundation, MLIR_ML, MobileAssetExclaveServices, Morpheus, MorpheusExtensions, an OnDeviceStorage group, OpenAPIRuntimeInternal, OpenAPIURLSessionInternal, PIRGeoProtos, RapidResourceDelivery, SecureVoiceTriggerAssets, SecurityUICore, and VideoEffect.

While many of those names can inform speculation about what we’re about to see in macOS 16, three merit a little more decoding.

Cryptexes are secure disk images loaded during boot that currently deliver Safari and its supporting components, and the dynamic libraries for all those frameworks, public and private. Accessing them from user-level code isn’t something you’d expect to happen, so those two Private Frameworks, CryptexKit and CryptexServer, hint at further expansion in their use and support.

Bosporus

The Bosporus Strait in Turkey connects the Black Sea to the Sea of Marmara, thence through the Dardanelles to the eastern Mediterranean. It’s a busy thoroughfare formerly used heavily by ships carrying grain and other bulk cargoes from Ukraine and Russia.

View of Constantinople and the Bosphorus (1856) is one of many views that Ivan Aivazovsky made of this great city, which he visited on many occasions. The artist kept his studio in Crimea, on the opposite (northern) shore of the Black Sea.

Morpheus

Morpheus is the god of dreams, whose name is the source of the word morphine. Although usually distinct from Hypnos, god of sleep, he’s sometimes associated with Nyx, goddess of the night, most famously in reference to a passage from Virgil’s Aeneid, painted below by Evelyn De Morgan.

She pairs Nyx with Morpheus in her Night and Sleep, from 1878. The further figure is a young woman wearing long red robes, her eyes closed, clutching a large brown cloak with her right hand, and most likely Nyx. Her left arm is intertwined with a young man’s right arm. He also has his eyes closed, and is most probably Morpheus. He clutches a large bunch of poppies to his chest with his left arm, while his right scatters them, so they fall to the ground below.

Virgil’s lines in Book 4, line 486 read:
hinc mihi Massylae gentis monstrata sacerdos,
Hesperidum templi custos, epulasque draconi
quae dabat et sacros servabat in arbore ramos,
spargens umida mella soporiferumque papaver.
haec se carminibus promittit solvere mentes
quas velit, ast aliis duras immittere curas…

Translated (at Perseus at Tufts University), this reads:
From thence is come
a witch, a priestess, a Numidian crone,
who guards the shrine of the Hesperides
and feeds the dragon; she protects the fruit
of that enchanting tree, and scatters there
her slumb’rous poppies mixed with honey-dew.
Her spells and magic promise to set free
what hearts she will, or visit cruel woes
on men afar.

Spargens umida mella soporiferumque papaver, one of Virgil’s greatest lines, is conventionally translated as “scattering moist honey and sleep-inducing poppy”, and describes well the effects of the opiate drugs derived from opium poppies, including morphine.

I look forward to watching the lambs grow up through the coming summer, and learning about those lambs that came with Sequoia 15.4 at WWDC.

Have you been able to update an existing lightweight macOS Virtual Machine on Apple silicon to Sequoia 15.4? So far, I’ve had three failures ending in kernel panics, and no successes. Maybe I’m holding it wrong?

Good news …

I’ve had no problems updating VMs from Sonoma 14.7.4 to 14.7.5, or Ventura 13.7.4 to 13.7.5. Those updates went quickly and without a glitch, but Sequoia has been another matter.

… bad news

I’ve now tried to update from Sequoia 15.x to 15.4 with three different VMs:

• freshly installed 15.2
• freshly installed 15.3.2
• lightly used 15.3.2.

None of them had iCloud enabled, but they were each fairly standard in other respects, and all running in Full Security mode, in my virtualisers Vimy and Viable.

Each has failed early, just a minute or two after the update started to install. That was terminated, and the VM briskly rebooted back into its existing version of Sequoia. Shortly after logging back in, they displayed the panic alert.

One VM was so sick at that stage it couldn’t go any further, so had to be humanely destroyed. However, I managed to capture panic logs for the other two. In both cases, the panicked task was com.apple.Mobile, with com.apple.iokit.AppleVirtIOStorage(1.0) at the top of the kernel extensions in the backtrace. The panic occurred on different cores, and its cause was given as “Kernel data abort”.

And a more innocent bug

In the course of looking at this, I happened to notice that creation dates of files in Shared Folders were all incorrect, giving a standard date of Monday, 1 January 2001 at 00:00. All other creation dates in VM folders, the SSV, and even in iCloud Drive folders, were as expected, but none of those in Shared Folders.

However, when any of those mis-dated files or apps were copied into the VM’s local storage, the expected date of creation returned like magic.

I have checked this in VMs running 15.2, 15.3.2, 15.4, 14.7.5 and 13.7.5, and it’s identical in every one. I suspect this may have been going on for some time. Am I holding this one wrong too?

Over to you

• Have you been able to update a Sequoia VM to 15.4?
• Are file creation dates wrong in your VM’s Shared Folders?

Postscript

Thank you all for your responses. I’ve now confirmed that failure to update to 15.4 appears confined to M4 models, and doesn’t afflict my MBP M3 Pro at all. However, the shared folder creation date bug seems just the same there.

Apple has just released the update to macOS Sequoia to bring it to version 15.4, and security updates for 14.7.5 and 13.7.5.

The Sequoia update for Apple silicon Macs is about 6.2 GB in size, and 3.9 GB for Intel models, making it one of the largest intermediate updates for some years. For Apple silicon Macs, the update to 14.7.5 is about 3.7 GB, and to 13.7.5 about 3.3 GB.

Among the changes listed by Apple for 15.4 are:

• Adds Memory movies in Photos using AI.
• Adds a Sketch Style option in Image Playground, in AI.
• Adds Mail Categorisation.
• Apple silicon Macs with an internal SD card reader now support SDUC cards larger than 2TB.
• This should resolve problems with some M4 Macs being unable to launch Virtual Machines.
• Content filter extensions correctly receive non-TCP/UDP network protocol traffic.
• Finder no longer fails to copy some dataless files from SMB file shares.

Enterprise release notes are here.

Software Update settings will be automatically changed to enable future macOS updates to be downloaded and installed automatically: if you don’t want that, you’ll need to change that setting once your Mac boots in 15.4.

Security release notes are available for Sequoia, Sonoma and Ventura updates. There are a total of 131 vulnerabilities fixed in 15.4, which must be a record. None is reported as being suspected of exploitation in the wild, and the security updates for Sonoma and Ventura are almost as numerous.

Firmware updates include iBoot (Apple silicon) to version 11881.101.1, and T2 Macs to 2075.101.2.0.0 (iBridge 22.16.14248.0.0,0). The macOS build number is 24E248.

The new version of Safari in 15.4 is 18.4 (20621.1.15.11.10). APFS is updated to version 2332.101.1.

As so much has changed, I won’t be posting a separate article listing significant changes: it looks like pretty well everything has!

Just for reference, the Sequoia 15.0 major version upgrade from Sonoma was 6.6 GB for Apple silicon, and 4.9 GB for Intel – those aren’t that much larger than this ‘minor version update’.

Those intending to update Apple silicon Virtual Machines currently running 15.3.2 should be prepared for the 15.4 update to fail. I’ve tried with two VMs now, one with a fresh copy of 15.3.2, and both have failed early during installation with a kernel panic. However, 15.4 does install correctly from the latest IPSW image file. Older VMs with 14.7.4 and 13.7.4 do update correctly to 14.7.5 and 13.7.5 respectively.

[Last updated 1715 GMT 1 April 2025.]

Installing macOS on external bootable disks connected to Apple silicon Macs has been one of the most frustrating experiences of my life, and has driven some more experienced than me to abandon their attempts altogether. The latest bug in this was reported by Michael Tsai earlier this week, and can prevent you from installing any version of macOS prior to Sequoia, on an external disk connected to an Apple silicon Mac running macOS 15.3.2, and likely earlier versions of Sequoia.

To reproduce this, I partitioned an external 2 TB SSD connected to my MacBook Pro M3 Pro, which originally shipped with Sonoma 14.1. I have on many occasions installed macOS on that SSD for use with Apple silicon Macs, and hadn’t had a failure with it. To ensure favourable winds, I connected the SSD to the USB-C port at the right of the left side of the case, which isn’t the designated DFU port.

Apple disables installers for previous major versions of macOS from running in more recent versions. Trying to run a Sonoma installer in Sequoia is therefore doomed to fail. Instead, the installer has to be converted into a bootable installer volume, and the Mac booted from that to perform the installation. Although you can use a USB ‘thumb’ drive for that purpose, I prefer to use a 100 GB partition on a convenient external disk, in this case the same SSD on which macOS was to be installed. One of the quirks of bootable installers is that they must still use HFS+ rather than APFS, hence they get a partition of their own.

The three partitions I created were:

• APFS container with two APFS case-insensitive unencrypted APFS volumes in 900 GB
• APFS container with one APFS case-insensitive unencrypted APFS volume in 1 TB
• HFS+ Journaled volume in 100 GB.

I used two Sonoma full installer apps, one for 14.6.1 taken from my library, the other for 14.7.4 freshly downloaded from Apple, both installed from InstallAssistant packages into /Applications. Each was successfully installed individually into the HFS+ volume on the external SSD following the instructions given by Apple.

In each test, I entered the external installer from Recovery mode as detailed by Apple, and started installation to one of the two APFS volumes in the first APFS container on the external SSD. After long periods attempting the installations, both failed with exactly the same error reported by Michael Tsai: com.apple.OSinstallerSetup.error error 702

Between the two attempted installations, both the HFS+ volume and the destination APFS container were erased and set up again. Following those two failures, I successfully installed macOS 15.2 and 15.3.2 direct to the three APFS volumes on the external SSD without any problems, and verified that all three Sequoia installations had been completely successful.

I therefore conclude that, in Sequoia 15.3.2 at least, it’s not possible to install any version of macOS prior to Sequoia 15.0 on an external SSD connected to an Apple silicon Mac. If your experience differs, then please let me know how you did it.

Michael Tsai appears to have been successful only when running the installation from Sonoma. If you do need access to a non-virtualised installation of Sonoma or earlier, it appears the only way you’re likely to succeed is from Sonoma, which would require you to perform a full DFU Restore to revert the Mac to macOS 14.

Useful tricks

• The Mac must be capable of running that version of macOS.
• The external disk must be connected to a port other than the DFU port.
• When installing an older major version of macOS, perform this from an external bootable HFS+ volume as detailed by Apple.
• Use an HFS+J partition on an external SSD rather than a USB ‘thumb’ drive.
• Boot from the installer volume through Recovery mode.
• When using a laptop model, run it from mains power throughout macOS installation.
• If essential, you can revert the Mac’s internal SSD to an older version of macOS and firmware using a full DFU Restore with an appropriate IPSW image file.
• Use a Virtual Machine instead, if you don’t need to be able to run software from the App Store.

As its name suggests, LaunchServices is responsible for key features integrating the launch of apps and document types. Together with the more recent RunningBoard subsystem, it handles much of the work involved in launching apps, as I explored yesterday for Sequoia. This article looks in more detail at LaunchServices and what you can do to address problems, such as ensuring that only the apps you want are listed in the Finder’s Open With… contextual command.

RunningBoard is concerned with the control of resources such as memory, GPU access, CPU limits and the process lifecycle. Events are handled as assertions, and for apps that it manages those can result in reallocations and changes of state. Each running app has a lengthy and detailed job description created during launch but that doesn’t persist once an app has shut down.

In contrast, LaunchServices compiles a large registry database of apps and their associations with and capabilities for handling different document types. Its records determine which app opens a document when you double-click on its icon in the Finder, and most prominently which are listed when you open the Open With… item in the Finder’s contextual menu. Apps are registered there automatically, and their details are updated each time they’re run. Although the user can’t interact directly with LaunchServices, there is a command tool that offers control over it, lsregister, although it’s buried deep in the system frameworks, doesn’t have a man page, and now works differently.

lsregister

This command tool can be found at /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister, and typing that in with the -h option will show its usage information, as the closest you’ll come to documentation. If you’re going to use it much, you’ll want to create an alias for it, or add it to your PATH with
PATH=/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support:"$PATH"
to use the command as lsregister, as I’ll do here.

Useful lsregister commands follow one of two forms:
lsregister [options] [path]
to register or unregister an item (usually an app) specified by the path, and
lsregister [options] [-apps domainlist] [-libs domainlist] [-all domainlist]
to act on the LaunchServices database for the given types (apps, libs, all) and domains. Domains are usually specified as a list of letters:
u,s,l,n
is the complete set, covering user (your Home folder), system, local and network.

Registration

In the past, apps used to populate the LaunchServices registry were those located in the traditional Applications folders, but recent versions of macOS have extended that to cover almost any accessible folder. This has been explored by Jeff Johnson, who has shown that excluding folders and volumes from Spotlight indexing, by adding them to the list in Search Privacy… in Spotlight settings, will exclude those apps from LaunchServices’ list. Alternatively, you can hide the folder they’re in by adding a dot to the start of its name. However, that can still fail at times, for example if you open that excluded location in the Finder, resulting in those hidden apps being added back into that list.

You can try to remove an app from the LaunchServices registry using the command
lsregister -R -f -u pathname
where pathname is the path and name of the app. In Sequoia, that invariably returns an error that lsregister “failed to scan [path]: -10814 from spotlight,” where the path given is that to the app. That error code comes from LaunchServices, and its name reveals the cause: kLSApplicationNotFoundErr, even when the pathname given to lsregister is correct. Despite that error, if that app is hidden from Spotlight search, this should prove effective until something undoes it again.

This over-enthusiasm to register apps can be even more than a nuisance when running a lightweight macOS Virtual Machine on Apple silicon. If you make the host’s Applications folder a shared folder with the VM, then open that shared folder within the VM, all the apps within it are promptly added to the Open With… list in the guest, a behaviour likely to be unwanted.

Given the current state of LaunchServices discovery, you’re unlikely to want to add an app to the database, as it’s most probably already there, whether wanted or not.

Resetting the registry

In the past, one last-ditch method of addressing LaunchServices problems has been to reset its registry. You can perform that using either
lsregister -kill -r -v -apps u
to affect just the user domain, or
lsregister -kill -r -v -apps u,s,l
to widen its coverage to other domains.

Running either of those in recent versions of macOS including Sequoia is likely to wreak havoc, though. While this appears to be effective with the Open With… list, its effects on System Settings can be catastrophic. This can remove its entire contents, and even blow the wallpaper away. Normal function should start to return after restarting the Mac, but even then problems can persist.

Dumping the registry

Even on a minimal Mac, LaunchServices’ registry is very large. If you want to inspect its contents, use a command like
lsregister -dump > ~/Documents/lsregisterDump.text
to write its contents to the file lsregisterDump.text. Browsing that should keep you occupied for many hours or days.

Summary

• LaunchServices is responsible for making associations between apps and documents, and maintains a large registry of all apps and document types.
• Its registry is used to populate the list for the Open With… item in the Finder’s contextual menu.
• LaunchServices now tries to include all apps in accessible volumes and folders.
• You can control (to a limited degree) its registry using the hidden lsregister command tool.
• You can exclude apps only if their location is excluded from Spotlight search by adding it to Search Privacy… in Spotlight settings.
• LaunchServices in a VM will also try to include all apps in shared folders on the host.
• Resetting the registry using lsregistry -kill can wreak havoc with System Settings and should be avoided.
• Dump the registry to text using lsregister -dump if you enjoy a long read.

Each new version of macOS has increased the complexity of launching apps, from the basics of launchd, the addition of LaunchServices, to security checks on notarization and XProtect. This article steps through the major landmarks seen when launching a notarized app that has already passed its first-run checks and is known to macOS Sequoia 15.3, on an Apple silicon Mac.

Rather than trying to provide a blow-by-blow account of what’s written in the log over the course of thousands of entries, I’ve extracted landmarks that demonstrate when each subsystem gets involved and its salient actions. These have been gleaned from several similar app launches, and are ultimately timed and taken from one complete record of one of my simpler notarized apps that has no entitlements and uses only basic AppKit features. The app hadn’t been through quarantine as it had been built and notarized on the same Mac, and had been run previously but not in that session since the previous boot. It had thus been previously registered with LaunchServices and other subsystems. The host was a Mac mini M4 Pro, so timings should be briefer than on many other Macs, it was run from the main Applications folder on the internal SSD, and AI was enabled.

LaunchServices and RunningBoard

LaunchServices has been around for many years, and handles many of the tasks exposed in the Finder, including mapping of document types to app capabilities, Recent Items and Open Recent lists, making it the backbone of app launching. RunningBoard was introduced in Catalina and has steadily assumed responsibility for managing resources used by apps, including memory and access to the GPU. Although the test app doesn’t have any of its resources managed by RunningBoard, LaunchServices launched it through RunningBoard.

RunningBoard’s first task is to create a job description, which it helpfully writes to the log as a dictionary. This is a mine of useful information, and has replaced the copious information compiled by LaunchServices in the past. This includes:

• a dictionary of Mach services
• whether Pressured Exit is enabled
• a full listing of environment variables, such as TMPDIR, SHELL, PATH
• RunningBoard properties including another TMPDIR
• whether to materialise dataless files.

Once that job description has been constructed for the app, RunningBoard tracks the app and its assertions, providing a detailed running commentary through the rest of the app’s life. LaunchServices still performs its traditional tasks, including creating an LSApplication object and sending an oapp AppleEvent to mark the opening of the app, and launchd still reports that it’s uncorking exec source upfront.

When the app is running, its preferences are loaded from the user CFPrefsD, and its pasteboard is created. Almost 0.1 second later (0.3 seconds after the start of launch) there’s a sustained flurry of log entries concerning Biome, and signs of AI involvement (Apple silicon only). The latter include a check for the availability of generative models and WritingTools. There are also entries referring to the loading of synapse observers.

LaunchServices log entries are readily accessed through its subsystem com.apple.launchservices, and RunningBoard through com.apple.runningboard.

Security and privacy

The first serious engagement in security is the verification of the app’s signature and its evaluation by Apple Mobile File Integrity (AMFI, using amfid). Shortly after that comes the standard Gatekeeper (GK) assessment, with its XProtect scan, starting less than 0.1 second after the start of launch. Immediately after the start of that scan, XProtect should report which set of data files it’s using. In Sequoia those should be at /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara. That scan took just over 0.1 second.

While XProtect is busy, syspolicyd checks the app’s notarization ticket online, through a CloudKit connection with the CKTicketStore. That’s obvious from log entries recording the network connections involved, and the complete check takes around 0.05 second. Once that and the XProtect scan are complete, syspolicyd reports the GK scan is complete, and evaluates its result.

At about the same time that the Gatekeeper checks are completing, privacy management by TCC (Transparency Consent and Control, in tccd) is starting up. Its initialisation includes establishing the Attribution Chain for any Mach-O binaries run by the app, so that TCC knows where to look for any required entitlements. Following that, TCC writes bursts of entries as different components such as the Open and Save Panel service are set up for the app.

The final phases of security initialisation come in provenance tracking, which first appeared in macOS Ventura. This may be associated with presence of the extended attribute com.apple.provenance, but details are currently sketchy.

Following syspolicy in the log is best through its subsystem com.apple.syspolicy, you can watch XProtect using com.apple.xprotect, and TCC is com.apple.TCC.

Overall

Downloadable PDF: applaunch153

Main landmarks with elapsed time in seconds:

• 0.000 Finder sendAction
• 0.023 LaunchServices, launch through RunningBoard
• 0.029 RunningBoard launch request
• 0.043 AMFI evaluate
• 0.066 Gatekeeper assessment
• 0.080 XProtect scan
• 0.085 check notarization ticket
• 0.187 TCC checks
• 0.204 launched

Previous article

Launching apps in Sonoma 14.6.1: Conclusions

This week’s new features in my lightweight log browser LogUI tackle two important areas: initial checks to confirm that the app can access the log, and improving the filtering of log entries using predicates.

LogUI has three key requirements:

• that the Mac is running macOS 14.6 or later, as enforced by macOS;
• that it’s run from an admin account, as that has the privileges required to access the log;
• that there are log records it can access in the path /var/db/diagnostics, as without those it hasn’t got anything to work with.

LogUI 1.0 build 31 now contains code to check the latter two, run soon after launch. If either fails, you’ll see an informative alert, and the app will quit when you click to dismiss that.

LogUI now has internal features to support a wide range of filters that can be applied when fetching log entries. These are an essential means of reducing the number of entries displayed, and of focussing your attention on what’s important.

This is reflected in its Settings, which now refer to Text rather than a Subsystem. The window toolbar now has a Predicate popup menu, and its text box is labelled text rather than Subsystem.

This menu offers the following options:

• none, which applies no filtering and displays all log entries;
• subsystem, which uses the text entered as the name of the subsystem whose entries are to be displayed, as in the previous builds;
• eventMessage, which shows only those log entries whose message contains the text entered;
• processImagePath, which shows only entries whose process name (or path) contains the text entered;
• [Edit], which in future will open an on-the-fly predicate editor, but currently doesn’t filter;
• TimeMachineBasic to blowhole, which use set predicates to display log entries for those features. The first two are different levels of detail for Time Machine backups, error finds entries with that word in their message, kernel finds entries with the kernel as their process, and blowhole finds entries made by my command tool for writing entries in the log.

Text entered is not case-sensitive.

Although it’s currently possible to change and extend those, that involves delicate surgery to LogUI’s preferences Property List, and I don’t intend you to hack that just yet. The next features will provide a proper editor in LogUI’s Settings, and the on-the-fly editor accessed through this menu.

Otherwise LogUI should work just the same as the last build. These new features are documented in its Help book, a separate copy of which is supplied in its Zip archive.

LogUI 1.0 build 31 is now available from here: logui131
and I will shortly be giving it an entry in my log browser Product Page, to make it easier to access. I’m also looking at building an auto-update mechanism into it.

Please let me know how you get on with this, and whether it proves useful to you. Enjoy!

Last week’s security updates to macOS have left some confusion over version numbers, and firmware for T2 Macs. This article attempts to clarify what happened, and where supported versions of macOS are going next.

Security updates 11 March 2025

Apple released:

• macOS 15.3.2 Sequoia
• Safari for macOS 14.7.4 Sonoma
• Safari for macOS 13.7.4 Ventura.

There were no security updates for Sonoma or Ventura other than their Safari updates.

There was also a firmware update included in the 15.3.2 update, changing the version of iBridge firmware in the T2 chip of Intel Macs from 22.16.13051.0.0,0 to 22.16.13060.0.0,0. There were no firmware updates for Apple silicon Macs, nor for Intel models without T2 chips, I understand.

Sequoia

If your Mac is running macOS Sequoia and has been updated, it should now be running 15.3.2 (build 24D81). If it has a T2 chip, it should have updated its firmware to read
EFI 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0)

Safari should be version 18.3.1 (20620.2.4.11.6).

Sonoma

If your Mac is running macOS Sonoma and has been updated, it should still be running 14.7.4 (build 23H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (19621.1.14.11.3, 19621).

Ventura

If your Mac is running macOS Ventura and has been updated, it should still be running 13.7.4 (build 22H420). If it has a T2 chip, its firmware should remain at
EFI 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Safari should have been updated to version 18.3.1 or 18.4 (18621.1.14.11.3, 18621).

SilentKnight

To keep a complex situation as simple as possible, SilentKnight only considers one firmware version to be current for each model of Mac. If it tried anything more complex, I’d not be able to cope. As there are presently two different ‘current’ and supported versions of T2 firmware in use, SilentKnight goes with the older one. That way it doesn’t complain, but politely remarks for Sequoia 15.3.2:
EFI version found 2069.80.3.0.0 (iBridge: 22.16.13060.0.0,0) ;
expected 2069.80.3.0.0 (iBridge 22.16.13051.0.0,0)

Please bear with me until Apple resyncs T2 firmware across the three supported versions of macOS. I’m sure that will return with the release of 15.4, 14.7.5 and 13.7.5. If not, we can all scream together.

Sonoma 14.7.5 and Ventura 13.7.5

Many have been reporting that their Macs have been updated to 14.7.5 or 13.7.5, and some have claimed that those versions have been released by Apple. They are in fact beta-releases of the next scheduled updates to Sonoma and Ventura, and haven’t yet been generally released. If your Mac is running one of those, you might like to check it against recent beta-releases:

• 21 February 2025 betas: Sonoma 14.7.5 (23H510), Ventura 13.7.5 (22H510)
• 10 March 2025 betas: Sonoma 14.7.5 (23H520), Ventura 13.7.5 (22H520)
• 17 March 2025 betas: Sonoma 14.7.5 (23H525), Ventura 13.7.5 (22H525)

App Store full installers

If you download a full installer from the App Store or elsewhere, the current releases are:

• Sequoia 15.3.2 (build 24D81)
• Sonoma 14.7.4 (build 23H420), which will then need Safari updated
• Ventura 13.7.4 (build 22H420), which will then need Safari updated.

How has this happened?

Normally, when the current version of macOS has a security update, the two older versions that are still supported have matching security updates. That would have brought 14.7.5 and 13.7.5 along with 15.3.2. However, in this case the patch to be applied could be supplied in a Safari update for the older two. As that’s much smaller and simpler than a full macOS update, Apple opted to supply those as Safari updates alone, which can’t of course be a new version of macOS.

This is possible because Safari and some of its supporting frameworks and components aren’t part of the Signed System Volume, so updating them doesn’t require the System volume to be rebuilt, turned into a snapshot, and installed as a new Signed System Volume.

However, firmware updates can only be supplied and installed as part of a full macOS update, so it was only possible to update T2 firmware in Sequoia systems being updated the long way to 15.3.2.

I hope this dispels any remaining confusion.

I’m grateful to ExcleX for pointing out that Safari versions can vary according to when you updated.

Macs have developed their own mythology, and this week I unintentionally came across a myth that developed over a year ago. Like so many it was born from a chance observation, this time of a new background process that appeared on 25 October 2023 in macOS Sonoma 14.1, and was reported in 9to5Mac on 3 November 2023.

Discovery

The process in question is liquiddetectiond, and as 9to5Mac’s headline claimed, it meant that “Macs can now inform Apple if any liquids have been detected in the USB-C ports”. That article argued that “it seems more likely that the data collected by this daemon will be used for technicians to determine whether a Mac is eligible for free repair.” “Putting a digital liquid detector on USB-C ports is just another way to ensure that technicians are right about claiming that a Mac has been exposed to liquids.”

That, and a couple of linked reports elsewhere, brought a small flurry of comments about how typical this was of Apple, then all went quiet until 9to5Mac’s article was picked up by Hacker News on 9 January 2024 and generated 340 comments. Predictably, most either castigated Apple’s behaviour or disappeared down rabbit holes about unrelated topics. Among them, though, was one precious insight: “It prevents the device from applying/draining power from any pin in such a state, mainly to reduce corrosion of the contacts and increase longevity.”

By the middle of January last year, the story had gone cold, and everyone must have gone away with their worst fears confirmed. You couldn’t even get a USB-C port damp in your Mac any more, as Apple would use that as an excuse to void your Mac’s warranty.

Documentation

Apple’s first word on the subject seems to have been in a support note published on 23 November 2024, which passed largely unnoticed. This announced liquid detection as a feature new to macOS Sequoia when running on only the following models:

• MacBook Air M3 and later
• MacBook Pro with M3 Pro or Max
• MacBook Pro with M4 base, Pro or Max

none of which had been released at the time of 9to5Mac’s report, although the second were released four days later, on 7 November 2023.

If there’s liquid in one of their USB-C receptacles (ports) when a USB-C cable is connected to it, this new sensor should detect it and alert the user, advising them to shut the Mac down, disconnect all cables and leave it to dry.

This is in addition to, and separate from, what Apple terms Liquid Contact Indicators (LCI), that have long been fitted to laptop Macs and some Apple wired and wireless keyboards “to help determine if these products have been exposed to liquid,” according to this support note.

Was Apple just making excuses, or was this new liquiddetectiond service intended to benefit the user?

Evidence

I stumbled into this innocently last week when I was looking at Accessory Security, a feature confined to laptop Apple silicon models. By chance, the laptop I was using was a MacBook Pro M3 Pro, one of the few in which liquid detection works. There, on several occasions in its log, after connecting a Thunderbolt cable, its liquid detection system checked that the USB-C port was dry, in a series of log entries like:
0.887 liquiddetectiond Starting LDCM Now
0.887 liquiddetectiond LDCM Discovery is enabled.
0.889 liquiddetectiond LDCM - Matched with V4...
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM - Handling LDCM interrupt event for port 2
0.890 IOAccessoryManager IOPortFeatureLDCMUserClient::_copyData(): Copying LDCM data... (target: Port-USB-C@2/LDCM)
0.890 liquiddetectiond LDCM - Feature Status: 0, Completion Status: 0, Measurement Pin: 0 Mitigations Status: 0, Wet: 0, Wet State Duration: 0
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM: liquidDetected: 0, receptacleEmpty: 0, shouldShow: 0
(Times given in seconds elapsed.)

But on my more recent Mac mini M4 Pro running Sequoia, all I saw was that LDCM is not supported on this device.

Attempts to connect over the network are obvious in the log, and on not one of the occasions that liquid detection was performed did that MacBook Pro try to connect to any remote site. Maybe its reports could have been embedded in other analytics data passed to Apple later, but there was absolutely no evidence that the results of liquiddetectiond went beyond the confines of my Mac.

This demonstrates the importance of testing out hypotheses, and of reading the log. Even without the benefit of Apple’s recent support note, it should have been easy to demonstrate this behaviour, yet no one seems to have attempted to.

Explanation

Claims made of the role of liquid detection in USB-C ports also don’t make sense. As with most laptop manufacturers, Apple already builds Liquid Contact Indicators into components of laptop Macs within their case. These are most frequently affected by spillage of drinks on a laptop’s keyboard, resulting in any of a wide range of water-based liquids from coffee to cognac entering the case. That often results in extensive damage to the logic board and other components, that are expensive to replace.

But a damp USB-C port is quite a different matter. It could occur in a laptop that had been out in the cold and was then brought into a warm and more humid environment, the same sort of conditions that steam up your spectacles. Over time, that could lead to corrosion of the contacts in the USB-C ports, and unreliable connections.

Because each release of macOS is identical across all models of Mac, although only a few of the most recent models feature liquid detection sensors in their USB-C ports, the liquiddetectiond service runs in the background of all Macs running Sequoia. It’s to be found inside /System/Library/CoreServices/liquiddetectiond.app, which isn’t even a bundle, just its Mach-O binary and an image of the warning sign displayed. It’s run through its LaunchDaemon com.apple.liquiddetectiond.plist, which you’ll also find in the SSV of every Mac.

As is so often the case, the truth behind the myth is more prosaic, and doesn’t involve Apple secretly capturing data from your Mac, nor conspiring to dodge warranty repairs. In fact, if you look at the warranty terms of pretty well every other laptop manufacturer, they too exclude damage caused by liquid ingress, as demonstrated by their Liquid Contact Indicators. And some are also starting to fit similar liquid detection sensors in their USB-C ports. But don’t let those get in the way of a good myth.

If you have a laptop Apple silicon Mac, you’ll no doubt have discovered one of its novel features: connect a USB or Thunderbolt peripheral to one of its USB-C ports, and you could be asked whether to allow it to connect, as a result of its Accessory Security. This isn’t available in desktop models, though. This article explores how it works and how it’s associated with liquid detection.

Accessory Security setting

At the foot of the Privacy & Security section of System Settings in capable Macs is an extra control Allow accessories to connect. In macOS Sequoia this has four options:

• Ask Every Time, which prompts you to approve every time you connect a peripheral to a USB-C port.
• Ask for New Accessories, which only prompts you to approve devices that it hasn’t connected previously. However, if your Mac is locked for three days or more, it may ‘forget’ devices that it approved previously, and require you to approve each again.
• Automatically When Unlocked, which connects all devices without prompting, so long as that’s done when that Mac is unlocked.
• Always, which will never prompt you to approve a device.

This novel security mechanism is intended to prevent laptop Macs from being attacked using plug-in USB or Thunderbolt devices intended to breach their security. Apple considers laptop models to be most at risk, but surprisingly still hasn’t offered this as an option in any of its desktop models.

Approval

When you connect a USB or Thunderbolt device to one of your Mac’s USB-C ports, there will be a momentary delay and, if your approval is required, an alert will be displayed.

To approve or refuse that invitation, you’ll first need to unlock your Mac if it’s locked. Peripherals such as hubs and docks that can charge your Mac will still be able to do that even if you don’t allow them to connect, but all other features will be blocked until you click on Allow.

How it works

To examine how Accessory Security works, I connected a Thunderbolt 4 hub to a USB-C port on a MacBook Pro M3 Pro, which supports this feature, and a Mac mini M4 Pro, which doesn’t. The setting for the laptop was to Ask Every Time. I then captured their logs using LogUI and compared the contents of each.

Port activation

This consisted of a long sequence of entries from IOAccessoryManager detailing port activation and initial configuration. Here are some waymarks among those, with elapsed time given in seconds:
0.883 IOAccessoryManager IOPortTransportState::setActive(): [Port-USB-C@2: CC] active: YES (transportType: 1 [CC])
0.883 IOAccessoryManager IOServiceNotificationManager::handleServiceReregistration(): [Port-USB-C@2/CC] Re-registering service...
0.883 IOAccessoryManager IOPortTransportState::initWithTransportType(): Initializing IOPortTransportStateUSB3... (transportType: 3)
0.884 IOAccessoryManager IOPortTransportState::initWithTransportType(): Initializing IOPortTransportStateUSB2... (transportType: 2)
0.884 IOAccessoryManager IOPort::_updateConnectionActive_block_invoke(): [Port-USB-C@2] m_connectionActive: YES, m_connectionCount: 1, m_connectionUUID: F53E1B0B-8347-4528-B77C-FC79E8A657C5
The last entry there records the connection’s UUID.

Is it authorised?

Next, authorisation was assessed:
0.885 IOAccessoryManager IOPort::_updateAuthorizationState(): [Port-USB-C@2] Updating authorization state...
0.885 IOAccessoryManager IOPort::_updateAuthorizationState_block_invoke(): [Port-USB-C@2] authorizationRequired: NO -> YES, authorizationPending: NO -> NO, userAuthorizationPending: NO -> NO, supervisedTransportActive: NO -> NO
Those will still appear in the log of a desktop Mac, but will say NO throughout.

There are repeated updates of the port’s pin configuration:
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setPinConfiguration(): Updating pin configuration...
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setCableActive(): activeCable: NO
0.885 IOAccessoryManager 1605 IOAccessoryManagerUSBC::setCableOptical(): opticalCable: NO
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setDisplayPortPinAssignment(): dpPinAssignment: 0
0.885 IOAccessoryManager IOAccessoryManagerUSBC::setPlugOrientation(): plugOrientation: 2
0.885 IOAccessoryManager IOPortTransportStateUSB::setDataRole(): [@: IOPortTransportStateUSB3] Setting data role... (dataRole: 2 [Host])

Liquid detection

A little while later, in the laptop only, a hardware liquid detection sensor was checked, to see if there was any liquid present in the receptacle (port):
0.887 liquiddetectiond Starting LDCM Now
0.887 liquiddetectiond LDCM Discovery is enabled.
0.889 liquiddetectiond LDCM - Matched with V4...
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM - Handling LDCM interrupt event for port 2
0.890 IOAccessoryManager IOPortFeatureLDCMUserClient::_copyData(): Copying LDCM data... (target: Port-USB-C@2/LDCM)
0.890 liquiddetectiond LDCM - Feature Status: 0, Completion Status: 0, Measurement Pin: 0 Mitigations Status: 0, Wet: 0, Wet State Duration: 0
0.890 liquiddetectiond LDCM - checkIsReceptacleEmpty: 0
0.890 liquiddetectiond LDCM: liquidDetected: 0, receptacleEmpty: 0, shouldShow: 0
On a desktop Mac running Sequoia, you’ll only see LDCM is not supported on this device.

Approval

Preparations are then made to display the approval dialog, and authorisation status is updated:
1.116 IOAccessoryManager IOPort::_updateAuthorizationState_block_invoke(): [Port-USB-C@2] authorizationRequired: YES -> YES, authorizationPending: NO -> YES, userAuthorizationPending: NO -> YES, supervisedTransportActive: NO -> YES

As promised in Apple’s documentation, charging from the peripheral is enabled before approval:
2.639 IOAccessoryManager IOPortFeaturePower::_addPowerSource(): [Port-USB-C@2/Power In] Adding power source (powerSourceName: Brick ID)...
and the power chime may be sounded
2.718 gui/501/com.apple.powerchime xpcproxy spawned with pid 1677

Once approval is given in the dialog, this is recorded and the connection is then established fully:
4.709 IOUIAgent Received notification response! (userNotification: 0x620364480, .responseReceived: 1, .notificationCancelled: 0, .notificationDismissed: 0, userAuthorizationStatus: 2, port: <private>)
4.709 IOAccessoryManager IOPortUserClient::setUserAuthorizationStatus(): Setting user authorization status... (target: Port-USB-C@2, newUserAuthorizationStatus: 2 [Authorized])

Authorisation

Although Accessory Security settings are in Privacy & Security, much of which is concerned with controls implemented by TCC, protection and authorisation is here controlled by IOAccessoryManager. Its list of previously approved devices isn’t exposed to the user, and the only control is its single setting.

Liquid detection

The surprise feature is liquid detection, in the liquiddetectiond service and LDCM. This is a new feature in macOS Sequoia, and the following models:

• MacBook Air M3 and later
• MacBook Pro with M3 Pro or Max
• MacBook Pro with M4 base, Pro or Max.

If there’s liquid in one of their USB-C receptacles (ports) when a USB-C cable is connected to it, a sensor should detect it and alert the user, advising them to shut the Mac down, disconnect all cables and leave it to dry. Full details are given in this support note, dated 23 November 2024.

Previously, reports of this feature claimed that it was intended for use by Apple to determine whether a laptop Mac had been damaged by liquid ingress. Like all laptops, internal components of MacBook Air and Pro models contain several liquid sensors already intended to reveal whether ingress has occurred. Sensors in the USB-C receptacles are clearly different, and are being used to prevent damage by corrosion inside the receptacle, rather than limit warranty or AppleCare+ repairs.

Summary

• Accessory Security is available in all laptop Apple silicon Macs, and intended to prevent attack by malicious devices.
• A single control in Privacy & Security settings determines when approval will be required for devices to be connected to a USB-C port.
• This is controlled by IOAccessoryManager, which manages the initialisation and preparation of USB-C ports. TCC is not involved.
• Some laptop M3 and M4 models have liquid detectors in each USB-C port. These will alert you if liquid is found when connecting to a USB-C port. This is intended to prevent corrosion occurring inside the receptacle, not to detect damage caused by liquid ingress.

Before the introduction of specific protection for privacy, like all Posix-compliant operating systems, macOS had just a standard system of privileges and permissions, augmented by ACLs. Although proven in terms of security, they are too coarse to be used to protect different classes of information within the same level of privilege.

When you run an app, it naturally runs with your full user’s privileges, and has access to everything according to the permissions set on folders and files. Just as you want your privileges to give the Finder and your mail client access to all your emails and their enclosures, all other apps that you run enjoy those same privileges. But would you also want a third-party note-taking or photo-editing app to have that same level of access, even without your knowledge? Similarly, while you want FaceTime to have access to your Mac’s camera and microphone, would you be happy for any other app to access them without your being asked?

Although robust security provides a foundation for the protection of privacy, they are quite different. Your FileVault and user passwords must be protected by good security, but entries in your address book and calendar aren’t the same, and primarily a concern for privacy protection.

Consent and intent

Privacy centres on controlling access to information and devices that provide it, and there are two approaches used to give you that control, your consent and your intent. These are used throughout privacy protection in macOS.

For an app to gain access to images from your Mac’s built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that may seem tedious and even pointless at times, the decision remains yours and not the app’s or that of macOS. If the whole purpose of an app is to provide web conferencing, then its consent dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps do want camera access.

Protected folders are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one, so for that macOS may ask for your consent instead.

Command tools and helpers

Expressing intent and obtaining consent are proven methods that work for apps with a human interface. Code is run in many other ways that don’t present any interface to the user. This applies to command tools, helper apps, and similar. To apply the same principles there relies on another fundamental concept in privacy protection, the attribution chain. Although you won’t normally encounter this in the GUI, if you ever need to understand how protection works, and if you have to resort to looking at logs, you’ll find it essential.

Let’s say I have an app that builds an index of files containing references to keywords, and does so using a command tool keyindexer. For that command tool to access files in my Documents folder, it can’t rely on intent for each one, so must seek consent. As it has no interface, the only way that can be obtained is through its parent app, through the attribution chain. If I were to run that same command from Terminal, then the Terminal app would be its parent, found by macOS using its attribution chain, and that’s why many prefer to give Terminal Full Disk Access.

Universal, not extensible, permanent

One of the more common complaints about privacy protection is that it’s universal. You as a user may not keep anything private in your Documents folder, but there’s no opt-out that lets you remove that from protection. That ensures that all apps are written on the assumption that ~/Documents is a protected folder, and ensures that hostile software can’t remove protection from any folder.

Unlike permissions, you can’t extend privacy protections to other locations or features. Although that could be attractive, privacy protection is complicated enough to negotiate without it being applied to almost anything you might fancy.

Until recently, when you gave consent for an app to have access to protected locations or features, that was set until you changed it. macOS 15 Sequoia has changed that, in that you’re now reminded periodically if you have given screen recording consent for an app. This has proved problematic, with many criticisms and persistent bugs.

Informative texts and entitlements

Depending on the privacy protection, Apple can apply restrictions as to which apps can request the user for consent to access a protected resource. This is implemented in two ways: a requirement for the app to provide in its Info.plist the text to be shown to the user in the consent dialog, and an entitlement to access the protected resource that is baked into the app’s signature.

Those are far from universal across all protections, but can be inspected in the app using Apparency for verification purposes.

Apple’s reference lists

Info.plist keys
Entitlements

Articles in this series

Protected folders and places
Protected devices
Protection of location information
Protection of network devices, automation, and others

Appendix: Protection and lists

For macOS 15.3.1 Sequoia, protected resources are as follows.

Protected locations:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• Third-party cloud storage
• Removable volumes
• Network volumes via local network devices
• Time Machine backups.

Protected data:

• Calendars
• Contacts
• HomeKit
• Media & Apple Music
• Photos
• Reminders
• Focus
• Motion & Fitness.

Protected devices:

• Bluetooth
• Camera
• Input Monitoring, of mouse, trackpad, keyboard
• Local Network devices
• Microphone
• Screen & System Audio Recording
• Speech Recognition.

Protected features:

• Passkeys Access for web browsers
• Accessibility, control over the Mac
• App Management, to update or delete other apps
• Automation, control other apps, giving access to their data and documents
• Developer Tools, to run software that doesn’t meet macOS security rules
• Remote Desktop.

Possible list arguments for tccutil:

• Accessibility
• AddressBook
• All
• AppleEvents
• AudioCapture
• BluetoothAlways
• BluetoothPeripheral
• BluetoothWhileInUse
• Calendar
• Camera
• ContactsFull
• ContactsLimited
• DeveloperTool
• FileProviderDomain
• FileProviderPresence
• FinancialData
• FocusStatus
• KeyboardNetwork
• MediaLibrary
• Microphone
• Motion
• Photos
• PostEvent
• Reminders
• RemoteDesktop
• ScreenCapture
• SpeechRecognition
• SystemPolicyAllFiles
• SystemPolicyAppData
• SystemPolicyDesktopFolder
• SystemPolicyDeveloperFiles
• SystemPolicyDocumentsFolder
• SystemPolicyDownloadsFolder
• SystemPolicyNetworkVolumes
• SystemPolicyRemovableVolumes
• WebBrowserPublicKeyCredential

for use in
tccutil reset [list] [appID]
where [list] is one of the lists above, and the optional [appID] is the identifier of the app whose privacy settings are to be removed.

So far in this series explaining how you can control access to potentially sensitive features and data in macOS, I have covered the following topics:

• Gaining access to privacy-protected folders,
• Managing privacy-protected devices,
• Managing access to location information.

This article rounds those off with a brief survey of other privacy controls, including an account of the newest of them all, over local network devices.

Additional privacy controls

There are several controls over specific classes of data, including

• Calendars
• Contacts
• HomeKit
• Media & Apple Music
• Photos
• Reminders
• Focus
• Motion & Fitness.

These are normally the preserve of specialist apps that are required to seek your explicit consent, and are controlled in their own entries in Privacy & Security settings. General access to their files can be given through Full Disk Access as well, where appropriate.

There’s a final group of controls whose purposes overlap more, and as a result may appear confusing:

• Passkeys Access for Web Browsers, required if you want a third-party browser to use passkeys for authentication.
• Accessibility, allowing control over your Mac, as in Automator and AppleScript. These can be added manually.
• App Management, allowing an app to update or delete other apps, which can be added manually.
• Automation, allowing control over other apps, so giving access to the data and documents within controlled apps, and to perform actions with them, but that doesn’t include Automator itself.
• Developer Tools, required to run software locally that doesn’t meet macOS security rules such as the requirement for notarization. This is primarily for developers, and can be added manually.
• Local Network, allowing access to network devices, as described below.
• Remote Desktop, allowing access to the contents of the screen.

As with other controls, these are all managed by TCC, and their individual lists can be cleared and reset using the command
tccutil reset [list]
where [list] is one of the following:

• Accessibility
• AddressBook (for the Contacts list)
• AppleEvents (for the Automation list)
• Calendar (note the singular, for the Calendars list)
• ContactsFull
• DeveloperTool
• FocusStatus
• MediaLibrary
• Motion
• Photos
• Reminders
• RemoteDesktop
• ScreenCapture

Local network privacy

This is one of the latest, introduced in macOS Sequoia. Although common to macOS, iOS, iPadOS and visionOS, it doesn’t work the same in each. It’s explained in TN3179 of 31 October 2024, and seems likely to evolve in the future.

Many apps access remote locations outside your local network; currently there are no privacy restrictions imposed on those, but code that accesses devices inside your local network, including your router, comes within the scope of this control. Some apps that work with devices on your local network do so using code that’s automatically given local network access because it’s a Launch Daemon or running with root privileges. Together with command line tools run in Terminal or over SSH, those aren’t controlled by TCC.

Regular apps and other code that attempt to access the local network will result in the user being asked to give their consent. While apps are invited to provide the text to be used in this dialog, in an NSLocalNetworkUsageDescription in their Info.plist, at the moment that isn’t enforced as a requirement, nor is there a required entitlement. You’re thus unable to verify whether an app should be expected to request access to local network devices.

This can apply to any app that tries to list other devices on the local network, whether over wired Ethernet or Wi-Fi. Those that also access Bluetooth will additionally request that, in a separate consent dialog.

Those who know Bryan Christianson’s excellent network utility WhatRoute may already have discovered that opening it for the first time in macOS Sequoia results in a privacy consent dialog. This might appear puzzling for an app that’s all about Internet connections, but as it does look at your router and can be used within your local network, macOS includes it within this new privacy category.

For the moment, Apple doesn’t appear to provide a service name that can be used with tccutil to reset its privacy settings, and disabling them in System Settings doesn’t remove them from the list. If you really need to reset that list, you’ll have to use
tccutil reset All [appID]
with the appID of each app that has already been given access.

Finally, because of the problems with network controls in early versions of macOS Sequoia, don’t rely on local network privacy in releases prior to 15.3.

Summary: local network privacy

• Sequoia introduces consent dialogs for access to devices on the local network, including routers, via Ethernet or Wi-Fi.
• This doesn’t apply to connections made to remote locations on the Internet.
• Launch Daemons, code running with root privileges and command tools in Terminal or via SSH aren’t affected.
• Access by other apps may result in a consent dialog, and an entry in Privacy & Security settings.
• Currently tccutil can’t reset all local network privacy settings in a single command.

Over the last nine years, few of my articles here have been about XProtect, other than those announcing its updates. Until September 2024 and the release of macOS 15 Sequoia. This is now the tenth article I have written about the problems brought by XProtect updates in Sequoia over those six months, when there have been just 13 updates. The result of the last, on 4 March, was that for two days afterwards, many Macs running Sequoia were still using its data from 26 February rather than that in the new version 5289.

This not only affects XProtect, but the other front-line tool in macOS to detect and remove malicious software, XProtect Remediator (XPR). Earlier this year, I reported that at least 17 of the 24 scanning modules in XPR now use Yara definitions provided by XProtect’s data. All those Macs still running the superseded version of XProtect would also have had XPR scans run using that old version of the Yara rules.

XPR is a recent addition to these tools, introduced just three years ago, but XProtect goes way back before Yosemite in 2014. Although there have been occasional brief glitches in delivery of its updates, they have almost invariably completed quickly and reliably, leaving very few Macs stuck with an outdated version 24 hours after an update.

I have now come to dread XProtect updates because of the problems we encounter, and the latest update to 5289 was a good example. There’s a flurry of comments and emails from those whose Macs had failed to complete the update, previously a rare exception. For XProtect 5287 on 5 February, for example, there were 33, including my responses. For version 2184 exactly a year earlier there’s not one comment about that XProtect update.

Sole documentation provided about XProtect’s updates in Sequoia is the man file for its command tool, xprotect, which refers only to updates provided via iCloud, and doesn’t explain how those delivered via the traditional mechanism in softwareupdate might be involved. Yet we know there is a relation: the latest update has still not been supplied via iCloud, not even four days later, but relied instead on XProtectUpdateService working with an update obtained via softwareupdate. Previously that could be invoked using the xprotect update command, but that no longer works, leaving users with two versions of XProtect data, of which the copy used by XProtect and XPR is the older.

Late last year, when xprotect update appeared to be working as expected, I decided that my app SilentKnight would need to use that command in order to download and install updates. As that requires elevated privileges, I have been looking at how to implement a privileged helper app to perform that. With the latest update, that approach would have failed until the version in iCloud had been brought up to date. Instead we’re now reduced to restarting our Macs and hoping that, some time in the next day or two, they might update.

There’s a further problem emerging with the updates of 4 March. Many users have noticed subsequent XPR scans being terminated before completion. Although in most cases that fault appears to go away in later scans, in some Macs it prematurely terminates every set of XPR scans, leaving several of its scanning modules unused.

For example, this iMac Pro has failed to scan using ten of its 24 modules. This occurs because XPR apparently runs a timer, and when a round of scans is deemed to be taking too long, that timer fires and brings XPR to an abrupt halt. Indications are this is most likely when there are many Time Machine backups accessible; as those are all immutable snapshots and haven’t changed since they were made months ago, this is strange behaviour, and hadn’t occurred prior to the updates of 4 March.

Six months ago, if anyone had told me that macOS security protection in Sequoia was going to become less reliable, I wouldn’t have believed them. The truth is that, for many, it now has. As things stand in 15.3.1, a Mac is now more likely to be using an out of date version of XProtect’s detection rules, and for XPR scans to detect and remove malware. And there’s nothing you can do about that until Apple returns to using an update mechanism that’s both timely and reliable. Is that really too much to expect of this front-line security protection?

Selected previous articles:

What is happening with XProtect updates?
XProtect tormentor
How XProtect has changed in macOS Sequoia
A simple guide to how XProtect installs and updates in Sequoia
XProtect has changed again in macOS Sequoia 15.2
What happened with XProtect?
What has happened to XProtect in Sequoia?

Macs and almost all devices assemble information about their location from local Wi-Fi networks, GPS systems (not Macs), and other sources. Access to location information in macOS is controlled in Privacy & Security settings, but unlike most of the items listed there it isn’t managed the same using TCC, but by its own service locationd in Location Services.

Tracking

In addition to those, Safari and other browsers include their own controls over tracking and location. In Safari, these are gathered in the Privacy section of its Settings, and the Location item in Websites. If you subscribe to iCloud+, you can access Private Relay in the iCloud+ section in your Apple Account.

Sharing and Find My…

Location Services are unique in that, when enabled, location data are invariably shared in iCloud, a feature you can’t control in iCloud settings. The only way to stop the sharing of locations across your iCloud-connected devices is to turn the whole service off, which is also true for iOS and iPadOS devices. Although it might seem tempting to disable Location Services altogether, that improved privacy comes at the cost of some valuable services: in particular, Find My… and Activation Lock, and many system services and apps also need Location Services to be enabled.

Settings

Location Services is the most complex of all the sections in Privacy & Security settings, and nests many of its controls deeply. This was inherited from the days of System Preferences, and hasn’t yet been redesigned to take advantage of System Settings. Above its last item, System Services, is a list of those apps over which you have direct control of their access to location data, although they can only be enabled or disabled and not removed from the list, neither can you add other apps.

Unusually, the About Location Services & Privacy button opens a window containing a mixture of help and privacy information, which is worth reading to give you better insight into what’s managed and how data is shared. It points out one important message: by giving a third-party app access to your location, that app’s vendor is in control of your location data in accordance with their terms and privacy policies, not those of Apple. If your location data is sensitive, then you shouldn’t give third-party apps access to it unless you’re confident they will protect it appropriately.

Further important controls are revealed in another window when you click on the Details… button for System Services. This lists some of the purposes for which macOS uses location data, giving you fine control over them.

The final layer in this onion is revealed when you click on the Details… button next to Significant Locations: a listing of all those locations that macOS considers to be ‘significant’. On a static Mac with mobile iOS devices, those are largely based on location data gathered from those, and are mirrored in similar lists on each device.

If you’ve never inspected these Significant Locations, you may be surprised at how much detail they contain: exact location, shown on a local street map, with time periods, over the last few months. It might be possible to reconstruct a lot of your life and activities from them. This window allows you to clear its history, in case you don’t want anyone to know where you’ve been.

Internals

Behind these is the system service locationd and its database locked away in /var/db/locationd. The official description of locationd is that it obtains geographic location data and manages access to it. When you’re prompted to give access to location data, that’s the CoreLocationAgent in action on its behalf. Apps that can ask for location data from Location Services should have the com.apple.security.personal-information.location entitlement and provide NSLocationUsageDescription information, something you can check using Apparency.

The /var/db/locationd directory contains one file that’s simple to read and holds important information, clients.plist, and various opaque data files. A sub-directory /Library has a surprising collection of scripts and cached data.

clients.plist is a standard Property List containing a dictionary of all the apps and other software that could access Location Services data. Those that are currently granted access contain the key Authorized set to <true>. In general, these should match apps and other items in the Location Services list in Privacy & Security settings, although that doesn’t apply to public or private frameworks that are included. There’s also a flag available for the key Hide suggesting that some apps or services can be given access to locations but won’t be displayed in Location Services settings.

While other privacy protections can be managed by the tccutil command tool, there’s no equivalent for Location Services. Besides, clearing its database would affect a lot of system services, including Find My… and Activation Lock, with their wider security implications.

Because of the reliance of Location Services on hardware and network features, they don’t function in Virtual Machines running on Apple silicon Macs, even though you can opt to ‘enable’ them.

Summary

• Geographic location data is derived from Wi-Fi networks and other sources, and delivered in Location Services.
• Although controls are included in Privacy & Security settings, they work differently from others, using the locationd service rather than TCC.
• Location Services are required for Find My…, Activation Lock and other macOS apps and services.
• By giving a third-party app access to your location, that app’s vendor is in control of your location data in accordance with their terms and privacy policies, not Apple’s.
• Significant Locations can give a detailed history of your movements.
• There’s no command tool to manage Location Services.

As those running macOS 15 Sequoia are only too painfully aware, the way that XProtect’s data is updated has changed from that still used in older versions of macOS. Instead of accessing that data in XProtect.bundle in the path /Library/Apple/System/Library/CoreServices, in Sequoia the data used is in /private/var/protected/xprotect. While the old location can still be updated using Software Update, SilentKnight and softwareupdate, the only way to update the copy in the new location is using the xprotect command tool, which normally obtains its updates through a connection to iCloud.

Updating in Sequoia

Since Sequoia 15.0, there has been a way to update data in the new location from XProtect.bundle in the old location, using the command
sudo xprotect update
If that finds a newer version of the bundle in the old location, it installs its contents in the new location, so updating XProtect in Sequoia. At least, it did until the release of Sequoia 15.3 or 15.3.1.

When Apple released XProtect version 5288 on 26 February, it did so through both connections, and all versions of macOS were able to update promptly and successfully. That didn’t work with its successor 5289 on 4 March, though. Although the Software Update version was successfully updated in the old location to 5289, no iCloud update was made available, and sudo xprotect update proved unable to update from that to the new location.

This has left those running Sequoia 15.3.1 with version 5289 in the old location, but 5288 stuck in the new location. As Apple doesn’t tell us of these updates, nor of how XProtect is supposed to work in Sequoia or earlier, it’s impossible to tell whether this is intended, or an unintended failure.

Which rules does XProtect now use?

One potential explanation is that XProtect has returned to using its old location for the Yara rules, in /Library/Apple/System/Library/CoreServices/ XProtect.bundle/Contents/Resources/XProtect.yara. That’s fairly easy to check in the log, where it states the location of the rules it’s using to check an app for malware. The answer is
com.apple.xprotect Using XProtect rules location: /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara
that’s the new location for Sequoia, and hasn’t changed since 15.0.

How does macOS now update the correct rules?

By chance, a few minutes after I had started my Mac mini M4 Pro yesterday, I opened SilentKnight and discovered that XProtect had successfully been updated to version 5289, something it wouldn’t do the previous evening following its release. At that time:

• XProtect in its old location had been updated to 5289 the previous evening.
• SilentKnight now reported XProtect in its new location was 5289.
• sudo xprotect check reported the version in iCloud was still 5288.
• sudo xprotect update reported that it was already up to date.
• xprotect version reported that 5289 had just been installed, about 2.5 minutes after starting up.

This was an ideal opportunity to discover how XProtect had updated this time, by looking in the log with LogUI. That showed the update had been dispatched as a background activity by DAS, with ID com.apple.security.syspolicy.xprotect-update. That’s a scheduled background activity run every 24 hours, and in this case appears to have been dispatched because of the recent boot.

That activity connects to XProtectUpdateService, which then runs the check and updates as necessary, connecting to iCloud using CloudKit. On this occasion it ‘found’ the 5289 update, although maybe in its old location rather than in iCloud, and updated XProtect’s data in its new location.

How to keep XProtect up to date

From this experience, bearing in mind that everything might change again in the future, my advice is to:

• Check for updates as usual using SilentKnight, Software Update, or softwareupdate.
• When offered an update by any of those, install it gratefully.
• Run SilentKnight a few minutes later. If that update isn’t reflected in the version shown, restart your Mac and leave it for 10 minutes or so before checking again.
• If it still doesn’t update correctly, check again in about 24 hours, by which time DAS should have dispatched com.apple.security.syspolicy.xprotect-update with any luck.

I suppose that’s progress?

It must be almost two years since I last demonstrated some magic tricks involving available and purgeable disk space. At that time, the amount of space involved was a mere 83.71 GB. Today I’m going to show you how I converted 228.16 GB of purgeable space into used space, recovering a lot of my files in the process.

Prior to my iMac Pro’s forced update to Sequoia 15.3.1, described here yesterday, its internal SSD had around 150-160 GB free, with no purgeable space at all. Immediately before installing that update, SoftwareUpdate reported that there was 160.57 GB available. When I had coaxed it back into life, now running 15.3.1, the foot of each Finder window told me there was now “393.72 GB available”. Imagine my surprise/shock/horror that about 240 GB of what had been on that SSD before it was updated had now vanished.

Recalling my previous experience, I selected Macintosh HD in the Finder, and opened the Get Info dialog. That confirmed the situation, stating

• Available 393.72 GB (228.16 GB purgeable)
• Used: 828,672,419,328 bytes (829.67 GB on disk)

A little arithmetic reveals that of the 393.72 GB “available”, only 165.56 GB was actually free at the time, the rest being “purgeable”. Together the truly free and that used “on disk” amounted to 995.23 GB. Adding the 16.16 GB used by other volumes, my Mac’s internal SSD had grown in capacity to 1.011 TB, which made that slightly traumatic update worthwhile after all.

Sadly, Disk Utility wasn’t so impressed. The figures it gave were very different indeed:

• Available: 165.56 GB (none purgeable)
• Used: 818.52 GB + 16.16 GB on other volumes = 834.68 GB
• One snapshot of 7.16 GB

for a total disk size of exactly 1 TB. The figures my own Mints gave were in accord with those from Disk Utility.

Although I much preferred the Finder’s figure of nearly 400 GB of “available” space, I realised that could only come at the cost of purging all that 228 GB of “purgeable” space. As that seemed to include many of my files, I thought it was time to work this week’s magic trick. I therefore restarted the Mac, and all of a sudden purgeable space had vanished, leaving me with only about 165 GB of free space after all.

To remind you of what I found nearly two years ago, after updating to macOS 13.3.1, the Finder found 83.71 GB “purgeable”, and my SSD had then grown to 1.08 TB in size.

That’s two major versions of macOS and almost two years apart, and the Finder still can’t come up with correct figures.

Last week I attempted to draw distinction between the different systems that control access to files and folders, from permissions to privacy settings. This article continues with a more detailed account of how Privacy & Security works, through the macOS Transparency, Consent and Control (TCC) system. Its settings are probably the most extensive and complicated of all System Settings, and grow worse with each new version of macOS.

Many of the controls in Privacy & Security settings refer not to folders on your Mac, but concern access to private data or sensitive hardware. The list of folders and volumes that have restricted access in macOS Sequoia is extensive:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• third-party cloud storage, if used
• removable volumes
• network volumes
• Time Machine backups.

Consent and intent

Apple’s approach to privacy is founded on two basic user controls: user consent, and user intent. These are fundamentally different, and are used in different types of protection.

For an app to gain access to its built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that dialog may seem tedious and even pointless, the decision is yours and not the app’s or that of macOS. If the app is for web conferencing, then the dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps want camera access. If you simply click through every consent dialog, then you won’t catch rogue or malicious apps.

Protected locations are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder, or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one. So access to protected locations may require user intent or consent.

The result for protected locations generally appears in two settings:

• individual folders are set in Files & Folders,
• system-wide access is set in Full Disk Access.

You can’t add apps directly to Files & Folders, but you can give them Full Disk Access. The difference is in how they work.

Files & Folders

Take an example, my virtualiser Viable, which doesn’t do anything privacy-related, but does provide access to some protected folders. When first installed, it has no entry in Privacy & Security. When I try to run a VM, that accesses some protected folders. As I don’t select them in a file open or save dialog, or by drag-and-drop, I don’t express my intent to access those folders. When Viable tries to do so, I’m prompted to give consent for it to access the Downloads and Desktop folders.

If I agree to those, Files & Folders is changed, adding Viable to its list, with access to those two folders enabled. If I don’t like that, or trash that app, then it’s up to me to delete its settings there. Otherwise, the next time it won’t prompt me, as I’ve already given my consent.

In the case of Files & Folders settings, you don’t have to quit the app and open it again for these changes to take effect.

Full Disk Access

Instead of doing that, you could decide to give the app Full Disk Access, which goes far beyond those two folders. In most cases, you should avoid giving everything Full Disk Access, as you could then be caught out by a rogue app. This works differently in that you have to open Privacy & Security settings, and in the Full Disk Access list, click on the + tool at the bottom left to select the app and add it.

Unlike Files & Folders, if you change its setting while the app is running, you’ll need to quit the app for the change to register and take effect.

Once that’s done, my app is listed in the Full Disk Access section. You could then disable Full Disk Access, even delete the app from here, although in both cases that needs the app to be closed and re-opened for the change to take effect.

Single files

There’s a third possibility we haven’t seen here: what if I want to use an app to edit files in a protected folder like ~/Documents? So long as I show my intent using features like file open and save dialogs, then that should go unchallenged, and you won’t be asked to give consent for the app privacy settings to be changed.

Command tools

This is fine for regular apps, but what about command tools, as they don’t have a GUI interface? Here the rules are applied through an attribution chain, based on which app called the tool to be run. In most cases, that means Terminal’s privacy settings. So if you want tools there to have access to protected folders, you’ll normally need to give consent by adding Terminal to Full Disk Access settings.

Exceptions

Unfortunately, macOS also applies some additional restrictions on locations that can be used for specific actions. For example, you can use the log collect command to save a copy of the Unified log to a logarchive for later analysis, but if you specify a path to an external disk, then the command fails, as it can’t be saved on external storage. You can, however, save the logarchive to internal storage, then move or copy it to external storage.

Summary

Rules for access to protected folders:

• If the user shows explicit intent, access is normally granted.
• If the app performs access without the user showing explicit intent to use a file in a protected folder, and the app doesn’t have Full Disk Access, then the user is prompted and that app added to the Files & Folders list to allow access to that specific folder.
• If the app needs consent for more general access, give it Full Disk Access.
• For command tools, treat Terminal as setting their access.
• Privacy controls work on top of permissions; if you or your app don’t have permissions, then privacy can’t overrule that.

Automatic Time Machine backups are the classic example of background scheduling and dispatch by Duet Activity Scheduler and Centralised Task Scheduling, the DAS-CTS system, and the stimulus for my personal interest, when they went awry in macOS Sierra. Before looking at how these are handled, I’ll start by showing how DAS sets up its budgets and its lists of scheduled activities. Following that I’ll describe how scheduling and dispatching automatic Time Machine backups have changed in macOS Sequoia.

Preparations

Shortly after user login, DAS starts gathering its budgets enabling it to score activities. These include thermal policies, shared memory and energy, for example
Allocating 188 budget on start for com.apple.dasd.systemEnergy
Each is given in notional units that can’t be correlated with anything external to DAS.

Following those, DAS loads saved activities by group. It’s not clear where those are stored, though, and presumably they were in the lists of activities for that user when they last logged out. A background system task helper is created, with a scheduler, listener and publisher, before DAS solicits activities for resubmission. Among the first of those is an activity run as root to clean up software update logs:
DAS Submitted: 0:com.apple.softwareupdated.logs-cleanup:27B9B4 at priority 5 with interval 604800 (Wed Feb 12 20:28:32 2025 - Thu Feb 13 20:28:32 2025)
DAS <private>: Optimal Score 0.5687 at <private> (Valid Until: <private>)

There are also some backup activities, including that to initiate automatic backups:
DAS Submitted: 0:com.apple.backupd-auto:9015F3 at priority 30 with interval 1800 (Wed Feb 12 08:05:28 2025 - Wed Feb 12 08:25:28 2025)
DAS <private>: Optimal Score 0.8535 at <private> (Valid Until: <private>)
DAS 0:com.apple.backupd-auto:9015F3:[
{name: Boot Time Policy, policyWeight: 0.010, response: {33, 0.00, [{[Minimum seconds after boot]: Required:300.00, Observed:22.19},]}}
], Decision: MNP}
As with many other activities, that can’t be considered for running until at least 5 minutes after boot.

Dispatch

Eventually, DAS decides to run backupd-auto to initiate the automatic backup:
DAS Rescoring all 535 activities [<private>]
DAS 0:com.apple.backupd-auto:3F876A:[ ], Decision: CP Score: 0.994671}
DAS '0:com.apple.backupd-auto:3F876A' CurrentScore: 0.994671, ThresholdScore: 0.095313 DecisionToRun:1
DAS REQUESTING START: 0:com.apple.backupd-auto:3F876A

That’s the cue for CTS to initiate the activity and run it. DAS then records
DAS STARTING <_DASActivity: "0:com.apple.backupd-auto:3F876A", Utility, 60s, [27/01/2025, 11:08:52 - 27/01/2025, 11:28:52], Started at 27/01/2025, 11:28:30, Group: com.apple.dasd.default, PID: 568>!
DAS 0:com.apple.backupd-auto:3F876A:[ ], Decision: CP Score: 0.994671}

backupd-auto only runs for a fraction of a second before it completes, and its next run is rescheduled in 30 minutes, not an hour:
CTS Completed: com.apple.backupd-auto (0x61e077ac0)
CTS Rescheduling: com.apple.backupd-auto (0x61e077ac0)
DAS SUBMITTING: 0:com.apple.backupd-auto:59E600
CTS _xpc_activity_set_state_from_cts: com.apple.backupd-auto (0x7ae068320), set activity state to 1
CTS _xpc_activity_end_running: com.apple.backupd-auto (0x7ae068320) seqno: 0.
DAS COMPLETED <_DASActivity: "0:com.apple.backupd-auto:3F876A", Utility, 60s, [27/01/2025, 11:08:52 - 27/01/2025, 11:28:52], Started at 27/01/2025, 11:28:30, Group: com.apple.dasd.default, PID: 568>
DAS NO LONGER RUNNING 0:com.apple.backupd-auto:3F876A ...Tasks running in group [com.apple.dasd.default] are 2!
DAS Submitted: 0:com.apple.backupd-auto:59E600 at priority 30 with interval 1800 (Mon Jan 27 11:43:29 2025 - Mon Jan 27 11:58:53 2025)

The two activities are distinguished by their appended hex IDs: the original and now-completed backupd-auto was 3F876A, and the new one is 59E600. This ensures that the next backup will be run in about 30 minutes, without losing the time taken to perform the backup. Instead, the backup is performed by the backupd process run by backupd-auto.

While Time Machine is estimating the time required to perform the backup, DAS dispatches an analytics activity, and another named com.apple.backupd-auto.dryspell.

Re-scheduling

Once the backup has been completed, Time Machine will normally re-schedule the next backup for an hour later. When it does, it announces in the log
Re-scheduled next backup in 60 minutes (plus or minus 30 minutes)
before submitting another activity with a new ID for backupd-auto. Immediately after that, it cancels the previously scheduled backupd-auto activity for 59E600, so the interval to the next automatic backup is about an hour following completion of the previous one.

New in Sequoia is this twice re-scheduling of the next automatic backup, first for 30 minutes later, then for the full hour. Previously, the first re-scheduling was for 60 minutes and there was no change made when the backup had completed. Presumably this is considered to be more reliable than in Sonoma and earlier.

Summary

This is summarised in the following chart.

Previous articles

Background activities with DAS-CTS
Scheduling XProtect Remediator scans
In-app background tasks

There was a stir of excitement last year when some claimed that Apple’s M4 and the A18 chip inside iPhone 16 models had a new security processor, the Secure Exclave Processor, a sister to the Secure Enclave Processor in all modern Macs. This article considers whether there’s evidence to support that.

Secure Enclave

The first Macs with a secure enclave and its processor, the SEP, were released over eight years ago, in the MacBook Pro 2016 models with a T1 chip. They were quickly succeeded by the iMac Pro at the end of 2017, with the T2 chip that became universal across the last models of Intel Macs. Inside each T2 chip is a 32-bit Arm core running sepOS to store and handle encryption keys and support other security features.

When Apple released the first M1 Macs, they too came with their own SEP, this time integrated into the main chip, but still running sepOS. Apple provides extensive details of each SEP used up to May 2024 in its Platform Security Guide.

During kernel boot of an M4 Pro running macOS Sequoia 15.3.1, the SEP writes a useful commentary of its startup to the Unified log. The SEP’s key store is started about 5 seconds after the initial system boot entry, and before the other CPU cores are started up. SEP boot takes place a little later, and it then starts handling messages. Support for biometric authentication follows, as does key unwrapping for apfs. Although the SEP isn’t loquacious, it is far from silent in the log.

Enclaves, exclaves, conclaves

To the best of my knowledge, the first description of exclaves in Apple’s operating systems was that of Dataflow Forensics on a beta-release of iOS 17 on 8 August 2023. They proposed that exclaves are code domains isolated from the kernel itself, so that, should the kernel become compromised in any way, components in exclaves should remain protected. I followed that with a report of new exclave kernel extensions in macOS 14.4, discussed here, and referenced back to Apple’s XNU source code.

It’s useful to distinguish between these three terms in their normal usage:

• an enclave is a territory entirely surrounded by the territory of another state;
• an exclave is an isolated fragment of a state that exists separately from the main part of that state;
• a conclave is a private meeting or close assembly, more specifically a meeting of the College of Cardinals convened to elect a new Pope.

Based on those and XNU sources, I proposed last August that exclaves provide a static set of resources to the XNU kernel. Examples include conclave managers, services like Apple ID for VMs, named buffers and audio buffers. These resources are named and have a corresponding identifier shared between XNU and the enclave. Those are discovered during the boot process, and made available in a table at two levels: a root table assembles resources by their scope, while secondary tables list actual processes.

For example, a root table entry for the domain com.apple.conclave.a might link to a secondary table listing an audio buffer, an audio service as a conclave manager, and additional buffering. In the case of audio exclaves, they might be used to connect a system extension running with user privileges to privileged access in the kernel and its extensions.

Support in Sequoia

As of Sequoia 15.3.1, there are three kernel extensions supporting exclaves:

• ExclaveKextClient.kext 1.0.0
• ExclaveSEPManagerProxy.kext 1.0
• ExclavesAudioKext.kext 220.24

There are also two private frameworks:

• CoreSpeechExclave.framework 1.0 (3403.7.3)
• libmalloc_exclaves_introspector.framework 1.0 (1)

There’s a group of private entitlements governing access to exclave and conclave functions, whose names start with com.apple.private.exclaves.

There are also multiple references to Tightbeam, which doesn’t appear to have been released in open source. This refers to highly focussed lasers used in communications in The Expanse sci-fi. In macOS, it first appeared as the name of a Private Framework released in macOS 13.0, and supported since then.

Examination of the 15.3.1 kernel boot sequence in the log reveals a single entry relating to exclaves, in which the neural engine (ANE) states that no exclaves are assigned to it, as it boots, far later in the sequence than SEP activity:
ANE0: start: No Exclaves assigned to ANE

XNU source code based on macOS Sequoia 15.0 reveals that code in exclaves is either run in CPU cores, for which there is code to support the management of multiple cores, or in the neural engine (ANE).

Summary

• The Secure Enclave is an isolated processing unit within Apple silicon chips that stores and handles encryption keys and supports other security features. It runs its own operating system, sepOS.
• Exclaves are managed code resources that are run in isolation from the kernel, and are currently used for I/O to support audio and CoreSpeech, sensors, and possibly for Apple ID for VMs. They run in CPU cores and the neural engine, and although they may have privileged access to hardware, they have no processor of their own, in Macs at least.
• Conclaves are close assemblies of exclaves, and should never communicate by fumata.

I’m grateful to Ben for rekindling my interest.

If you have an Apple device, you’ll be familiar with the idea behind Storage Settings in System Settings > General. What you might not be prepared for is what you’ll see there. Like its equivalent in the General section of the Settings app, the bar chart at the top often shows that much of your Mac’s storage is filled with System Data, and it neither breaks that down into anything more meaningful, nor does it offer a tool to do anything about it.

Storage Settings on macOS has a troubled history. It used to be part of About This Mac, and often took so long to complete its bar chart that folk gave up waiting. In some cases, it even crashed in the process. More often than not, the totals it gave for used and free space on the startup disk were substantially different from those reported by the Finder or Disk Utility.

In recent versions of macOS, Storage Settings has improved steadily. It does now complete its analysis in a reasonable period, and in most cases its figures aren’t too different from Disk Utility’s. But System Data remains a puzzle that confuses rather than enlightens.

What is System Data?

From the information given by Apple, it’s most likely that this isn’t really what we’d consider to be data used or required by macOS, but the often substantial difference between how much space is used, and how much can be attributed to other categories, like Books and Music. It’s not a real category, but an etcetera, a ragbag including all sorts of files and other data.

Calculating some of the other categories seems difficult enough. For example, my Music folder contains over 100 GB of individual audio files and my Music library, but Storage Settings recognises less than 50 GB of that in its Music category. The remaining 50 GB has to be accounted for elsewhere, and that’s likely to be buried in System Data. With Photos and TV it’s the other way around, with almost all my libraries stored on an external SSD, but Storage Settings still claims I have 36 GB in TV and doesn’t even mention Photos.

So the categories it does list don’t always match with what we know is on the disk. When it adds all those together and takes that total away from the amount of disk space used, that difference is little more than a guesstimate, and unlikely to contain much data required by macOS. No wonder Storage Settings can’t suggest any way to reduce that size.

Dynamic storage

Unlike more traditional file systems, APFS is dynamic in its use of storage space, and macOS now uses aggressive caching policies. One of those came to light when we thought the Finder had a large memory leak, only to be told that, in the right circumstances, it can retain GB of Quick Look thumbnails in memory, so that scrolling through them can be smooth. When there’s sufficient free disk space, macOS can maintain large caches without using any swap space on disk.

APFS features like snapshots can retain data we presumed had been deleted, but has to be kept until the snapshot referencing it has been deleted up to 24 hours later. That space has to be accounted for somewhere, and in many cases that too goes into the System Data category, although it has actually been created by Time Machine, which oddly doesn’t have its own category.

Although not given in the Storage bar chart, both the Finder and Disk Utility should state the amount of purgeable space in use. This could be freed when necessary, but that’s determined by macOS rather than the user. I have previously looked at how purgeable some features like snapshots are, and in practice you shouldn’t rely on their automatic removal when you think your Mac needs more free space.

What is Storage Settings good for?

Like its equivalent on iPhones and iPads, some of the tools it provides are of great value in housekeeping. Click on the ⓘ Info button for each of them to get further information and for actions you can take. Categories with the more useful tools include:

• Applications, shows apps by size, and which are Intel-only, and duplicates;
• Developer, if you have Xcode installed, can clean up build files and device support;
• Documents, lists by size and type, 32-bit apps;
• Messages, lists larger attachments and lets you delete them;
• Music Creation, helps you remove sound libraries;
• macOS, tells you how much space is used by Apple Intelligence.

Although Music might seem promising, it’s only interested in music video files you can remove.

How to check free space

Don’t trust Storage Settings or the Finder to provide an accurate estimate of free space available on disk. Instead, open Disk Utility (with Show All Devices selected in its view) and in the list at the left in its main window, pick the volume you’re interested in, then go up to its container in the list and select that. Free space shown there is the most accurate estimate of that available to all volumes within that container, as in APFS volumes within the same container all share the same free space.

Select one of those volumes, and you’ll see free space given as a higher value, with a figure for the space that’s purgeable in brackets. That represents the maximum space that could be freed if all purgeable contents were to be deleted.

For example, free space shown here for a container is 619.72 GB, which is the space available without any purging. One volume within that container is given as having 864.5 GB available, with 244.78 GB purgeable:
864.5 = 619.72 + 244.78 GB

Figures given by the Finder are only refreshed periodically, while Disk Utility should recalculate them whenever you select a volume or container, so should always be up to date.

Summary

• System Data in Storage Settings isn’t just files and data for macOS, but everything not listed in another category, and even that is only approximate, a rough estimate.
• Storage Settings has useful tools for managing the contents of your startup disk.
• For an accurate estimate of free space, use Disk Utility, and the free space given there for the volume’s container.
• Don’t expect macOS to free up any purgeable space for you.

Apple has just released a security update to macOS Sequoia to bring it to version 15.3.1, and security updates for 14.7.4 and 13.7.4. There don’t appear to be any associated updates to Safari.

Sequoia 15.3.1 update for Apple silicon is about 1.43 GB in size, and about 640 MB for Intel Macs.

Although these updates are listed on Apple’s security release notes page, they have no published entries, so there’s no information as to what they might address.

Apple silicon Macs have a firmware update, taking iBoot to version 11881.81.4, but there are no changes to firmware in Intel Macs.

The macOS build number is 24D70, and Safari remains at version 18.3 (20620.2.4.11.5). Messages has single minor build increment, but there are no other significant changes in bundled apps or in /System/Library.

Last updated at 1953 GMT 10 February 2025.

There have been many reports of problems with Thunderbolt 5 support in Apple’s latest MacBook Pro and Mac mini models with M4 Pro and Max chips. Among the more concerning have been poor performance when accessing SSDs through TB5 docks and hubs, and the inability to drive more than two 4K displays through those. This article looks at what has changed, and what can currently be achieved when accessing SSDs either directly or via TB5 docks or hubs.

When I last tested these, using a Mac mini M4 Pro and Sequoia 15.2, I found that speeds measured through a TB5 dock were generally at least as good as those through a TB4 hub, with three notable exceptions:

• Write speed from a TB5 port to a TB3 SSD through a TB5 dock fell to 0.42 GB/s, little more than 10% of that of a direct connection and similar to that expected from a SATA SSD operating over USB 3.2 Gen 2.
• Write speed from a TB5 port to a USB4 SSD through a TB5 dock fell to 2.3 GB/s, about 62% of that expected.
• Write speeds to a TB3 SSD through a TB5 dock occur at about half the expected speed, just as those through a TB4 hub.

Methods

Three Macs were used for testing:

• iMac Pro (Intel, T2 chip) with macOS 15.1.1, over a Thunderbolt 3 port without USB4 support.
• MacBook Pro (M3 Pro) with macOS 15.2, over a Thunderbolt 4/USB4 port.
• Mac mini (M4 Pro) with macOS 15.3, over a Thunderbolt 5 port.

The results for the first two are taken from my previous tests, and here used for comparison.

The dock used was the Kensington SD5000T5 Thunderbolt 5 Triple Docking Station, with a total of three downstream TB5 ports. I’m very grateful to Sven who has provided his results from an OWC TB5 hub to support those from the dock.

Other methods are the same as those described previously. The TB5 SSD tested is one of the three currently available or on pre-order from OWC, Sabrent and LaCie (no, I’m not going to tell you which, as I’m still in the process of reviewing it).

Single SSDs

Results obtained from measuring read and write speeds on a single SSD at a time are summarised in the table below. Those that are concerning are set in bold italics.

Performance of the TB5 SSD when connected direct or through the dock was highest of all, and around 150% of the speeds achieved by the next fastest, the USB4 SSD, and around 180-250% those of the TB3 SSD, the slowest. Direct connection of USB4 SSDs to the TB5 port in macOS 15.3 resulted in even faster speeds than a TB4/USB4 connection using 15.2. Thus, a TB5 port with 15.3 delivers best performance over all types of external SSD tested here.

Of the three exceptionally poor results seen previously:

• Write speed from a TB5 port to a TB3 SSD through a TB5 dock improved greatly from 0.42 GB/s to 1.6 GB/s, the same as in other Macs.
• Write speed from a TB5 port to a USB4 SSD through a TB5 dock improved from 2.3 GB/s to 3.8 GB/s, the same as when connected direct.
• Write speeds to a TB3 SSD through a TB5 dock remained at 1.6 GB/s, about half the expected speed, just as those through a TB4 hub.

This anomalous behaviour when writing to a TB3 SSD through a TB5 dock was also found by Sven in his tests on the OWC TB5 hub, and seems common to most if not all TB4 and TB5 docks and hubs. I haven’t seen any explanation as to why it occurs so widely.

Paired SSDs

Encouraged by these substantial improvements with Sequoia 15.3, I measured simultaneous read and write speeds to a pair of USB4 SSDs connected to the Kensington TB5 dock. Stibium has a GUI so can’t perform this in perfect synchrony. However, it reads or writes a total of 160 files in 53 GB during each of these tests, and outlying measurements are discounted using the following robust statistical techniques:

• a 20% trimmed mean, giving the 20th and 80th centiles;
• Theil-Sen regression;
• linear regression through all measured values, returning a rate and latency.

Measured transfer rates in each of the two USB4 SSDs are given in the table below.

The first row of results gives the two write speeds measured simultaneously when both the SSDs were writing, similarly the second gives the two read speeds for simultaneous reading, and the bottom line shows speeds when one SSD was writing and the other reading at the same time.

When both SSDs were transferring their data in the same direction, individual speeds were about 3.1 GB/s, but when the directions of transfer were mixed, with one reading and the other writing, their speeds were similar to a single USB4 SSD. Total transfer speed was thus about 6.2 GB/s when in the same direction, but 7.2 GB/s when in opposite directions.

Multiple displays

Many of those buying into TB5 are doing so early because of its promised support for multiple displays. I haven’t yet seen sufficient evidence to decide whether this has improved with Sequoia 15.3. However, OWC has qualified full display support of its TB5 hub as requiring “native Thunderbolt 5 display or other displays that support USB-C connections and DisplayPort 2.1”. One likely reason for multiple displays not achieving support expected, such as three 4K at 144 Hz, is that they don’t support DisplayPort 2.1.

Which macOS?

As the evidence here suggests, macOS 15.3 or later is required for full TB5 performance, and OWC now includes that in the specifications for its TB5 hub. It also states that TB3 support requires macOS 15, although USB4 should still be supported in macOS 14 Sonoma.

Recommendations

• TB5 SSDs are faster than USB4, which are faster than TB3, in almost every combination. The only exception to this is a USB4 SSD connected direct to a TB3 port, which is likely to be limited to 1.0 GB/s in both directions.
• When pricing allows, prefer purchasing a ready-made TB5 SSD. If it’s to be used with an Intel Mac, confirm that it there supports TB3.
• Self-assembly TB5 enclosures remain expensive at present, and a USB4 enclosure may then prove better value, provided that it won’t be used with an Intel Mac.
• Avoid writing to a TB3 SSD connected to a dock or hub, as its speed is likely to be limited to 1.6 GB/s.
• Ensure Macs with TB5 ports are updated to Sequoia 15.3 or later.
• Ensure Macs to be used with TB5 docks or hubs are updated to Sequoia 15 or later, or they may not fully support TB3.

For many who prefer to wait a little, the x.3 update is a popular time to upgrade to the next major version of macOS. By then, most of the major bugs should have been fixed, and some fine tuning performed on new features. So if you’ve just joined Sequoia from something older, you might now be wondering what on earth is going on with XProtect, which still baffles those of us who have been here since 15.0.

Which XProtect?

First allow me to dispel a common confusion: this article is about the XProtect we know of old, run on demand during Gatekeeper checks before macOS launches code. This isn’t the same as XProtect Remediator (XPR), a suite of scanning modules, that periodically searches your Mac to detect and remove known malware. Unlike XPR, XProtect leaves little trace in the logs, merely that it has checked code for malware and didn’t find any.

XProtect relies on a handful of configuration files in a bundle that doesn’t itself contain any code. Most important among them is a file containing a large and growing set of rules used to detect malicious code, the Yara rules. Every two weeks, Apple’s security engineers assemble the latest set of Yara rules into the bundle named XProtect.bundle and it’s distributed as an update from Apple’s servers.

Whichever earlier version of macOS your Mac has been running, it has downloaded those updates using Software Update, SilentKnight or a similar mechanism, installed that bundle into /Library/Apple/System/Library/CoreServices, and the next time that XProtect is run on demand it uses those updated rules to improve your Mac’s protection against malware.

Changes in Sequoia

In the past, XProtect has been something of a quiet backwater, and its Yara rules changed little and infrequently. That has changed dramatically over the last couple of years, and the rules have grown in number, size and sophistication. They have also become more responsive, to ensure XProtect’s checks keep up with the latest malware and its changes.

For Sequoia, Apple has changed the way that XProtect is updated, and where its Yara rules and other files are kept, to /var/protected/xprotect/XProtect.bundle, although previous versions of macOS continue to receive their updates as before. Updates for Sequoia can be delivered either via a connection to iCloud, or the established method to Apple’s Software Update servers.

Last week’s updates

Last week, the regular fortnightly update to XProtect 5286 was ready for release on 27 January, but macOS Sequoia 15.3, security updates, and updates to all the other OSes were released instead. They put a heavy load on the Software Update servers, so it appears the update to XProtect 5286 was delayed. That was a wise decision: Apple has previously tried releasing security data updates at the same time as OS updates, and it doesn’t work out well for anyone.

In the early hours (GMT) of 29 January, XProtect 5286 was released for download to macOS Sequoia via its iCloud connection. As this doesn’t use the servers responsible for macOS and other OS updates, that took advantage of this new feature in Sequoia. Most of the Macs running 15.0 or later were most probably updated to 5286 by the end of that day.

Twenty-four hours later, in the early hours (GMT) of 30 January, the same updated version of XProtect was released for download from Apple’s Software Update servers, enabling those still running older versions of macOS to install the update, as the load must have been reducing on those servers.

Although that seems clear and straightforward, what users saw often appeared puzzling if not incorrect. If you were running Sequoia, your XProtect data bundle with its Yara rules was probably updated silently during 29 January, but the following day (when your Mac was already enjoying the protection of the update) you were offered the 5286 update by Software Update, softwareupdate or SilentKnight, as if your Mac still had’t been updated. Some of you thought that was the real update, but it wasn’t, as that only updated the bundle stored at the old location, which isn’t used by XProtect in Sequoia.

How it worked

For the great majority of folk who don’t even know what XProtect is or does, this is all irrelevant, as their Macs continue to work as before, just improve their malware detection silently. For those of us who take an interest, or want to know what’s going on, it can appear profoundly confusing. To help clarify, here are two different ways that a Mac running Sequoia could successfully install XProtect 5286.

The preferred way is using the new iCloud connection, which doesn’t require that you have connected to iCloud, as it’s made outside your Apple Account or iCloud Drive. To start with, both copies of the XProtect bundle are version 5285. Then, probably on 29 January, that Mac connects to iCloud and downloads the update direct to its new location (red). Although the copy in the old location remains at version 5285, the copy used by XProtect is now using the updated rules in 5286.

Then, when the Software Update copy is installed the following day, both copies are brought up to 5286.

But Sequoia can still make use of the general release of the new version, as shown in this second diagram. Suppose that Mac running Sequoia didn’t have access to iCloud on 29 January, and the following day isn’t able to update to 5286 via iCloud. However, that update is still delivered from the Software Update servers. Over the next minutes or hours, macOS can then use that copy of the XProtect bundle to update the bundle now used by XProtect in Sequoia, as shown on the bottom line. If that doesn’t work, the user can run
sudo xprotect update
in Terminal, and that will force the local update.

Improvements

The benefits of this new system to the Sequoia user are therefore:

• updating 24 hours earlier, when Software Update servers were still heavily loaded;
• fall back to the traditional method if an iCloud update doesn’t occur, followed by local installation to the new location.

Now we can all return to trying out Genmoji. While they may be trivial by comparison, they bring a lot of fun to Messages, and we could all do with plenty of fun as well as better security.

The macOS 15.3 update introduces Genmoji creation in Messages and other apps on Apple silicon Macs, and improves notification summaries with an updated style and access from the Lock Screen (Apple silicon only). Notification summaries for News & Entertainment have been temporarily disabled while the engineers fix them. Those who don’t wish to use AI should ensure that they turn it off, as 15.3 now enables it by default when it’s supported.

Bugs fixed include improved stability for apps over VPN connections when using the built-in software firewall and content filter extensions, and successful AirPlay connections with the firewall and content filters. Brief release notes are here, and those for Enterprise are here. Security release notes are available here, and list 57 vulnerabilities, one of which is believed to have been actively exploited in iOS.

iBoot firmware on Apple silicon Macs is updated to version 11881.81.2, and T2 firmware to 2069.80.3.0.0 (iBridge: 22.16.13051.0.0,0). The macOS build number is 24D60, with kernel version 24.3.0.

Significant changes in bundled apps include:

• Contacts, build increment
• Freeform to version 3.3
• News to version 10.2.1
• Passwords to version 1.3
• Photos, build increment
• Safari to version 18.3 (20620.2.4.11.5)
• Stocks version 7.1.1
• Tips version 15.3.

Many of the usual public and private frameworks have build increments, particularly those involved in AI. However, this update appears to be more incremental bug-fixes and improvements, rather than anything more extensive or radical. Significant changes seen in /System/Library include:

• In CoreServices, Paired Devices.app to version 6.4.0
• Many AGX kernel extensions to version 324.6
• APFS is updated to version 2317.81.2.

Apple has just released the update to bring macOS Sequoia to version 15.3, together with security updates 14.7.3 and 13.7.3 for those using Sonoma or Ventura, who should also update to Safari 18.3 separately.

In Sequoia, this introduces Genmoji in Messages and other apps (Apple silicon only), and brings improvements in AI on Apple silicon Macs, although notification summaries for News & Entertainment are temporarily unavailable while they’re being sorted out.

Security release notes for Sequoia 15.3 are here, and list some 57 vulnerabilities that have been addressed, of which one is believed to have been actively exploited in iOS. Notes for Sonoma’s 38 fixes are here, and those for Ventura’s 30 are here.

Firmware on Apple silicon Macs (iBoot) is updated to version 11881.81.2, Safari to version 18.3 (20620.2.4.11.5), and the macOS build number is 24D60.

The 15.3 update is around 2.54 GB to download for Apple silicon Macs, and 1.93 GB for Intel models.

There’s also a separate update to XProtect imminent. I’ll post details about that separately.

Updated 1908 GMT on 27 January 2025.