I hope that you enjoyed Saturday’s Mac Riddles, episode 302. Here are my solutions to them.
1: Shortened characters into the most common extension, formerly ASCII.
Click for a solution
txt
Shortened characters (text, shortened) into the most common extension (it is), formerly ASCII (it used to be).
2: Medical practitioner at the end of word files until gaining a cross in 2002.
Click for a solution
doc
Medical practitioner (a doc) at the end of word files (the extension for Word native format) until gaining a cross in 2002 (progressively replaced by the newer docx from 2002 onwards).
3: At the end of real estate inventory, most commonly for Info and preferences.
Click for a solution
plist
At the end (a filename extension) of real estate (property) inventory (list), most commonly for Info (Info.plist in bundles) and preferences (also usually property lists).
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 Hyperdrive 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 Hyperdrive.
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.
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”.
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.
Ivan/Hovhannes Aivazovsky (1817–1900), View of Constantinople and the Bosphorus Вид Константинополя и Босфора (1856), oil on canvas, 124.5 x 195.5 cm, Private collection. Wikimedia Commons.
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.
Evelyn De Morgan (1855–1919), Night and Sleep (1878), oil on canvas, 42 × 62 cm, The De Morgan Centre, Guildford, Surrey, England. Wikimedia Commons.
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.
Disk images, files that contain the contents of a physical storage medium, go back long before the first Mac. Among other tasks, they were originally used to contain representations of floppy disks for replication in manufacture.
Today disk images are at the heart of macOS, and widely used by third-parties. They’re an essential part of macOS installers, home to Recovery mode, and the basis for cryptexes. They’ve been used to burn and replicate optical disks, to archive disk contents, extensively for network backups, and for the distribution of software.
Classic Mac OS
In Classic Mac OS there were two utilities that worked with different formats: Disk Copy used replicas later in DC42 format, after Disk Copy version 4.2, while compressed formats known as DART were handled by the Disk Archive/Retrieval Tool, hence their name.
Mac OS 9 brought Disk Copy 6.0 with added support for the New Disk Image Format (NDIF), which supported resource forks, and ended with its last release version 6.3.3. This also supported read-only Rdxx formats.
By this time, variants of formats had become complex. Here, Disk Copy is configured to create a read-only compressed .img file containing the contents of a standard 1.4 MB floppy disk. In the upper window, it has completed validating the checksum on a self-mounting .smi disk image that’s part of a DiskSet. These could also be signed, using certificates issued not by Apple but by DigiSign.
Here’s Disk Copy saving an image of a hard disk using a similar read-only compressed format, this time to accommodate 1.5 GB.
Mac OS X
The release of Mac OS X 10.1 Puma in 2001 brought Apple’s new Universal Disk Image Format (UDIF), used in DMG disk images, which only had a single fork as its resource fork was embedded in the data fork. Although pre-release versions of Disk Copy 6.4 and 6.5 were available with UDIF support for Mac OS 9, neither was ever released, leaving Classic Mac OS without access to UDIF images. Its support for compression options in Apple Data Compression (ADC) unified the two disk image types, and extended support for images larger than a floppy disk. This new format enabled disk images to represent whole storage devices, complete with a partition map and disk-based drivers.
Tools provided in Mac OS X for working with disk images include Disk Utility and the command tool hdiutil.
On 21 January 2002, the first version of DropDMG, a third-party substitute for creating disk images, was released by C-Command Software. This quickly enabled developers to create disk images with artwork, licences and other features that weren’t accessible from the tools bundled in Mac OS X. DropDMG has flourished over the last 23 years, and remains popular today.
DropDMG’s options for creating a new disk image far exceed those in Disk Utility. Particularly helpful are the compatible version hints shown on various options, to remind you of which file systems are available in different macOS versions, and which types of disk image container are supported. DropDMG will even convert old NDIF disk images last used in Mac OS 9 to more modern formats. It will also change the password of an encrypted disk image from a menu command.
In Mac OS X 10.2 (2002), UDIF and most other supported formats were served from a kernel extension without requiring a helper process. The following year, 10.3 Panther started using a faceless utility DiskImageMounter to mount disk images. Apple then dropped support for embedded resource forks in disk images in Mac OS X 10.4.7, and newly created disk images became less compatible with older Mac OS versions.
Sparse bundles
Until Mac OS X 10.5 Leopard in 2007, all disk images had used single-file formats, although some could be segmented across file sets. Leopard introduced the sparse bundle with its folder of smaller band files containing data. These enabled the image to grow and shrink in size, and became popular means of storing mountable Mac file systems on servers using different file systems.
This is another third-party tool that improved access to disk images from the GUI, DMG Packager, seen in 2009. Unlike DropDMG, this appears to have vanished without trace.
In 2011, with the release of Mac OS X 10.7 Lion, Apple removed more support for old disk image formats. DiskImageMounter no longer opened NDIF .img, .smi self-mounting, .dc42 and .dart compressed formats, although the hdiutil command tool still retained some access to them.
Disk Utility, seen here in 2011, has provided basic access to many disk image formats, but these are only a small selection of options available in the hdiutil command tool, or in DropDMG.
This shows the complex set of options available when creating a new disk image in Disk Utility in OS X 10.10 Yosemite, before the advent of APFS.
Support for compression was enhanced in OS X 10.11 El Capitan with the addition of lzfse in a new ULFO format, and macOS 10.15 Catalina added lzma in ULMO. In both cases, these new formats aren’t accessible in older versions of macOS.
APFS support
The arrival of a pre-release version of the new APFS file system in macOS 10.12 Sierra brought its support in disk images, although only for experimental purposes, and Apple cautioned users to ensure their contents were well backed up.
In addition to adding the more efficient ULMO compressed format, macOS 10.15 Catalina is the last to support many Classic Mac OS disk image formats, including those from DiskCopy42, DART and NDIF from Disk Copy 6.x. Support for AppleSingle and MacBinary encodings, and dual-fork file support, were also removed in macOS 11.0 Big Sur in 2020.
This ‘warning’ alert from 2020 illustrates one of the longstanding issues with disk images. Although integrity checking of disk images using checksums has been valuable, when an error is found there’s no possibility of repair or recovery as the image can’t be ‘attached’, so its file system can’t be mounted.
macOS 12 Monterey in 2021 brought multiple deprecations of older formats, including UDBZ using bzip2 compression, segmented UDIF images, and embedded resources. It’s also thought to be the first version of macOS in which UDIF read/write images (UDRW) have been stored in APFS sparse file format, although Apple has nowhere mentioned that. This has transformed what had previously been space-inefficient disk images that retained empty storage into a format that can prove almost as efficient as sparse bundles. This results from the Trim on mounting HFS+ and APFS file systems within the image freeing unused space, enabling that to be saved in the sparse file format.
Disk images have never been glamorous, but have remained at the heart of every Mac.
UDSB – sparse bundle, grows with content, bundle-backed, Mac OS X 10.5
UFBI – UDIF entire image with MD5 checksum.
Unsupported
DC42 – Disk Copy 4.2 (Classic)
DART – compressed, for Disk Archive/Retrieval Tool (Classic)
Rdxx – read-only Disk Copy 6.0 formats
NDIF – Disk Copy 6.0, including IMG and self-mounting SMI
IDME – ‘Internet enabled’, on downloading post-processed to automatically copy visible contents into a folder, then move the image to the Trash. Now deemed highly insecure.
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.
All good log browsers provide tools to narrow down the log entries they display. Without those, it would be easy to waste all day wandering through tens of thousands of entries. One common tool provided by macOS, directly and in the log command tool, is filtering using predicates. Although LogUI provides easy access to simple predicates, to get the best from them, it’s worth digging a little deeper, as I do here.
Instant predicates
LogUI’s instant predicates filter log entries according to any of four basic predicate types:
subsystem, such as com.apple.sharing, the field shown in yellow in log extracts;
eventMessage, the text message listed in white/black at the end of each entry;
processImagePath, such as mediaanalysisd, shown in blue, the name of the process making that entry;
senderImagePath, such as libxpc.dylib, shown in red, the name of the process sending that entry.
These are quick to enter in the text box to the right of the popup menu in the window’s toolbar, but in many circumstances can prove too broad, and need narrowing down further. In other situations, you want to browse entries from two subsystems, or using a combination of criteria. The best way to do that is to write a short predicate. For single use, you can do that in the one-off predicate editor using the Set button.
When you want to reuse that, you can add it to the predicate popup menu using Settings Predicate (currently a bit kludgy).
Predicates
macOS can use predicates in other situations, most commonly for Spotlight search. If you’re interested in those, see Apple’s Predicate Programming Guide. Here I’ll describe predicates as they’re more commonly used to filter log entries, as they’re usually much simpler.
Each simple predicate consist of three parts:
the name of one of the fields in a log entry, such as subsystem or eventMessage. This sets where the filter looks in each entry;
an operator, which might be == for ‘equals’ exactly, or for text is commonly CONTAINS[c] for case-insensitive contains;
text or a numeric value to look for, such as “error” or 513. Only those entries equalling or containing (or whatever the operator means) this in the specified field will then be returned from the log and displayed.
Here are some basic examples.
eventMessage CONTAINS[c] "error"
entries will only be those with the text error in their message field.
subsystem == "com.apple.duetactivityscheduler"
entries will all have that text, ignoring case, but only that text, as the name of their subsystem.
subsystem CONTAINS[c] "com.apple.xpc"
entries will have any subsystem containing that text, which also includes com.apple.xpc.activity.
Fields
Although you can use any of the fields shown in LogUI (and some that aren’t), the most commonly used are, in order as they are shown in LogUI’s window:
eventType (red) – matches the type of event, such as logEvent (1024), traceEvent (768), activityCreateEvent (513), or activityTransitionEvent (514). Can be given as characters (case-sensitive) without quotation marks, or using the digits given in parentheses. Use these only with the operators == or !=, as they are treated as numbers rather than text.
category (green) – this matches the category, and varies according to subsystem. This is given as text in quotation marks, and is normally lower-case.
messageType (white/black) – matches the type of message for logEvent and traceEvent, and includes default (0), release (0), info (1), debug (2), error (16), and fault (17). Can be given as characters (case-sensitive) without quotation marks, or digits as shown in parentheses. Use these only with the operators == or !=, as they are treated as numbers rather than text.
senderImagePath (red) – this matches the text pattern in the name of the sender, which might be the name of a library, extension, or executable.
processImagePath (blue) – this matches the text pattern in the name of the process that originated the event.
subsystem (yellow) – this matches the subsystem specifier, e.g. com.apple.TimeMachine, given as text in quotation marks. You may find it best to use CONTAINS[c] rather than ==, to allow for differences in case and extended subsystem specifiers.
eventMessage (white/black) – for this, you specify a text pattern, or text, within the message, given as text in quotation marks.
Operators
The following comparisons and other operators are available:
== (two equals signs) for equality
!= or <> for inequality
>= or => for greater than or equal to
<= or =< for less than or equal to
> for greater than
< for less than
AND or && for logical and
OR or || for logical or
NOT or ! for logical not
BEGINSWITH, CONTAINS, ENDSWITH, LIKE, MATCHES for string comparisons, using regex expressions when desired; strings can be compared with case insensitivity and diacritic insensitivity by appending [cd] to the operator, e.g. CONTAINS[c] means case-insensitive comparison
FALSE, TRUE, NULL have their expected literal meanings.
There are others as well, but you’ll seldom use them to filter log entries.
Building complex predicates
To see the scheduling and dispatch of background activities by DAS-CTS, you need to look at log extracts showing both their entries. Use the predicate subsystem == "com.apple.duetactivityscheduler" OR subsystem CONTAINS "com.apple.xpc"
to do that. The first part of it includes those entries from DAS, and the second includes those for XPC and its relatives that run CTS. Using an OR between the two parts combines both sets of entries in the one extract.
To see the reports posted by XProtect Remediator, you need to look at those entries made by its subsystem that have the right category, using the predicate subsystem == "com.apple.XProtectFramework.PluginAPI" AND category == "XPEvent.structured"
Using the AND operator ensures that the only entries shown come from that one subsystem, and they are given just that category.
Time Machine involves a combination of different subsystems and messages. To get a good overview of relevant entries, you can use subsystem == "com.apple.TimeMachine" OR
(subsystem == "com.apple.duetactivityscheduler" AND eventMessage CONTAINS[c] "Rescoring all") OR
(subsystem == "com.apple.xpc.activity" AND eventMessage CONTAINS[c] "com.apple.backupd-auto") OR
eventMessage CONTAINS[c] "backup" OR
eventMessage CONTAINS[c] "Time Machine" OR eventMessage CONTAINS[c] "TimeMachine"
I’ve broken this down into separate lines, but you shouldn’t do that in the predicate. Taking it line by line it becomes simpler to understand. Use parentheses () to group each part of the predicate carefully as shown.
You can see other examples in the Help book for my free utility Mints: the Further Information pages towards the end give each of the predicates that Mints uses for its log extracts.
Quick summary
[field name] [operator] [text or numeric value]
common field names: senderImagePath, processImagePath, subsystem, eventMessage
I’ve long been critical of some of the best-selling utilities for the Mac, that set out to perform deduplication of files by detecting which appear to be identical, and removing ‘spare’ copies. This is because APFS introduced clone files, and in the right circumstances those take up no space in storage, as their data is common and not duplicated at all. As it’s practically difficult to tell whether two files are clones, any utility or command tool that claims to save space by removing duplicates can’t tell you the truth, and in most cases won’t save as much space as it claims.
Claims made by those utilities are often exaggerated. This is because they calculate how much space they think they’ve saved by adding the sizes of the potential duplicates they have deleted. That’s not correct when a clone file is deleted, as that doesn’t actually free any space at all, even though the clone file has exactly the same nominal size as the original.
Benefitting from clone files
I’m delighted to see the eminent John Siracusa turn this on its head and finally make better use of clone files in his app Hyperspace, available from the App Store. Instead of deleting clones, his app can replace duplicate copies with clones, and so achieve real space savings. This comes down to simple arithmetic:
if you have two copies (not clones) of a file in the same APFS volume, the total size they take on disk is twice the size of one of them;
if you have two clones (not copies) of a file in the same APFS volume, the total size they take on disk is only the size of one of them, as its clone takes no additional space at all.
Hyperspace thus checks all the files in a selected folder, identifies which are identical copies, and (where suitable) will replace those copies (except an original) with clones, so saving real storage space.
I also think it has the most user-friendly payment scheme: download Hyperspace free of charge and check your Mac with it. If it doesn’t find sufficient savings, and you decide not to use it to replace any duplicates with clones, then it costs you nothing. If you want to reclaim that space, then you can opt to pay according to the amount of space it saves, by subscription, or with a one-time payment. On that basis, I unhesitatingly recommend everyone to download it from the App Store, and at least check their Home folder to see if it’s worth paying to reclaim space. You have absolutely nothing to lose.
In my case, perhaps because I tend to clone files using the Finder’s Duplicate command, the savings that it offered were of little benefit, but your Home folder could be different and release 100 GB or more.
Sparse files
The other space-saving special file type in APFS is the sparse file. Although it can bring great savings in storage space, that’s largely up to the app(s) that create and maintain the file, rather than the user. Devising an app that could go round converting plain to sparse files is harder, and risks incompatibility with those apps that access those files.
Fitting 285 GB into 16.5 GB
As a demonstration of how effective APFS special files are in saving disk space, I built myself a 100 GB partition (APFS Container) on an SSD and tried to fill it with clone and sparse files until I got bored.
At this stage, the 100 GB partition contains:
One 16.5 GB IPSW image file, with nine clones of it, created using the Duplicate command.
Eleven 10 GB sparse files and one clone, created using my app Sparsity.
Add those file sizes together and they come to 285 GB, yet the 100 GB partition only has 16.5 GB stored on it, and still has over 83 GB free. No compression is involved here, of course.
As the saying goes, there ain’t such as thing as a free lunch, and that free space could vanish quickly depending on what happens to those files. The worst case is for an app not to recognise sparse files, and write one to disk in plain format, so swallowing 10 GB at once. Editing the cloned files would be a more gradual way of their growing in size. Only changed data would then need to be saved, so free disk space would steadily fall as more changes were made to the clone.
Clone and sparse files are by no means unique to APFS, but they can be impressive, and above all they’re effective at reducing excess erase-write cycles that age SSDs, whatever you do with the storage they free.
I’m very grateful to Duncan for drawing my attention to Hyperspace, and to John Siracusa for an outstanding app.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5292. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version removes the macos_toydrop_b rule for MACOS.ADLOAD, and amends the rules for MACOS.ADLOAD.I, MACOS.BUNDLORE.MDPLST and MACOS.ADLOAD.IN.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5292.
Sequoia systems only
This update has now been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5292 but your Mac still reports an older version is installed, you can force the update using sudo xprotect update
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
By anyone’s standards, the macOS log contains a great many entries, and being able to filter out the noise is essential. This is accomplished by applying predicates to determine which entries are extracted and shown in a log browser like LogUI. However, using predicates requires knowledge about the log and its entries, and forms the greatest barrier for most users. This new version of LogUI improves features to help you use predicates to make the log more accessible.
This all happens in the toolbar of its browser window.
The section at the left of the lower row of tools now provides two methods to apply your own predicates: a one-off predicate editor, and an editor for custom entries in its popup menu.
One-off predicates
Click on the Set button to open the one-off predicate editor.
Here you can compose and paste in your own custom predicates that will extract only the log entries that you’re interested in. In this example, only entries whose subsystem is com.apple.duetactivityscheduler, or contains com.apple.xpc, will be gathered and displayed. Those tell you what’s going on with DAS and CTS scheduling and dispatch of background activities.
LogUI keeps that one-off predicate, even after a restart, as it’s automatically written to its preference file.
Once you’ve clicked Save, selecting the [ … ] item in the predicate menu will apply that predicate to each log extract you obtain.
There’s also an additional standard predicate using the senderImagePath.
Custom menu predicates
Predicates listed in that menu below blowhole are custom predicates saved to LogUI’s preferences using its new Predicate tab in its Settings. This editor is very basic at the moment, and its use a little awkward. This is because SwiftUI much prefers menu contents to be static, so adding items to the predicate menu doesn’t go down too well. This editor allows you to add one predicate at a time, in plain text format.
Click on the Append button here and there’ll be a new predicate named XProtect Remediator with the predicate shown. You can only add one new predicate, then need to quit the app before adding another. I’m sorry that’s so laborious, but once you have set up your custom predicates you can return to using LogUI fully.
The Settings General pane now contains a button to Reset Predicates back to their defaults.
Predicates
A basic predicate is composed of a log field name, like subsystem, followed by an operator such as == (equals) or CONTAINS[c] (case-insensitive contains), and a filter term, usually a string like "com.apple.xpc". So the predicate subsystem CONTAINS[c] "com.apple.xpc"
will return all log entries with their subsystem containing the text com.apple.xpc. You can combine those basic elements into a more selective predicate using combinators such as AND and OR, so subsystem == "com.apple.duetactivityscheduler" OR subsystem CONTAINS|c] "com.apple.xpc"
returns entries with a subsystem of preciselycom.apple.duetactivityscheduler together with those whose subsystem contains the text com.apple.xpc.
Some years ago I wrote a primer here, and you’ll find some useful predicates in the Further Information section in the Help book for Mints. I’ll be writing more here to help you get the best out of LogUI.
There are a couple of oddities with predicates. SwiftUI tends to like using typographic double-quotation marks, but the macOS predicate builder doesn’t accept them as a substitute for straight marks. So LogUI changes all styled marks to straight ones automatically for you, to ensure those shouldn’t cause a problem. However, when it encounters errors it can behave erratically; while I’m trying to make this more robust, I apologise in advance if using a broken predicate upsets LogUI. It’s worth being careful to check your predicates before trying to use them.
LogUI version 1.0 build 37 is now available from here: logui137
My next task is to improve editing and saving predicates to its preferences, to make them accessible as menu customisations.
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.
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.
Most modern Macs start up from their internal SSD, and have a single bootable system installed. Although its structure has changed considerably over recent years, and differs between Intel and Apple silicon Macs, they are generally reliable, and knowledge of their structure and function is seldom required.
Those who need to start their Mac up from two or more versions of macOS, or who do so from an external disk, may be able to get by without deeper understanding, but the moment there’s a problem can become confused, and end up having to install macOS from scratch.
Intel T2 and Apple silicon
Both types of Mac are designed to support Secure Boot, but because of the reliance of Intel Macs on UEFI firmware, they can only boot securely from their internal SSD. Enabling an Intel T2 Mac to start up from an external disk thus requires its boot security to be reduced by changing that in Startup Security Utility, in Recovery mode. Booting from an external system is then straightforward, and doesn’t require additional security measures as used in Apple silicon.
Apple silicon Macs have been designed from the outset to support Secure Boot when starting up from both internal and external disks, and don’t require any reduction in their boot security to be able to start up from multiple systems on external SSDs. It’s a common misunderstanding that trying to change Boot Security in Startup Security Utility can help solve Apple silicon boot problems, but if anything it only complicates them. Almost the only good reason for reducing boot security of an Apple silicon bootable system is when third-party kernel extensions are required. Otherwise don’t tamper with Startup Security Utility, as it will only confuse, as we’ll see later.
For an Apple silicon Mac to boot from a macOS system, that must have a LocalPolicy created and saved to the internal SSD. LocalPolicy is normally created during macOS installation, or when intending to start up from a suitably installed system. Problems with LocalPolicy have been common when using external disks, and are covered in these articles:
Another significant difference between Intel and Apple silicon Macs is the architecture of their internal SSDs: Apple silicon has two additional partitions (APFS containers), and lacks the traditional EFI partition. However, there are no such differences in the structure of their bootable external disks, and its relevance here is limited, and mainly affects Big Sur as I explain below.
macOS 10.13-10.15
Bootable disks in versions of macOS between High Sierra and Mojave (above) are based on their single boot volume, supplemented by hidden Preboot, Recovery and VM volumes. macOS 10.15 Catalina (below) divided that boot volume into a Boot Volume Group, consisting of paired System and Data volumes, in addition to the same three hidden volumes.
Basic support for volume roles was introduced in the first release version of APFS in macOS 10.13, and was extended to cover further roles in 10.15. Thus versions of APFS prior to 1412.x.x don’t understand volume roles used by subsequent systems. From Catalina onwards you can use the command diskutil apfs listVolumeGroups
to see paired System and Data volumes, for example +-- Container disk5 5BA1AAC8-3AD4-4594-AF01-7C0AA75CABAD
| |
| +-> Volume Group 68627CBB-D774-444E-97C6-F9511B5030F3
| =================================================
| APFS Volume Disk (Role): disk5s1 (Data)
| Name: Macintosh HD - Data
| Volume UUID: 68627CBB-D774-444E-97C6-F9511B5030F3
| Capacity Consumed: 580769214464 B (580.8 GB)
| -------------------------------------------------
| APFS Volume Disk (Role): disk5s5 (System)
| Name: Macintosh HD
| Volume UUID: 8B9FF440-75C8-4F7F-B09E-9222D44A2276
| Capacity Consumed: 11239186432 B (11.2 GB)
Note that each volume group has its own UUID, which is normally the same as that of the Data volume in the pair. Identification of volumes, containers and other structures in APFS is dependent on these UUIDs, which are an essential part of the GUID Partition Table scheme used to partition disks.
Catalina’s System volume is mounted read-only, but macOS is booted from that volume rather than the Signed System Volume snapshot introduced in Big Sur.
macOS 11
Although the structure of Big Sur internal SSDs in Apple silicon Macs has two additional partitions (APFS containers), Apple_APFS_ISC containing three volumes, and Apple_APFS_Recovery containing two volumes, bootable external disks have the same structure as the internal SSD in Intel Macs.
One important functional difference, which remains relevant to Big Sur boot disks, is that Apple silicon Macs don’t use the paired Recovery volume as their primary Recovery system: booting an Apple silicon Mac running Big Sur into Recovery should instead use the Recovery system installed in their internal SSD, in the Apple_APFS_Recovery partition. In subsequent versions of macOS, that’s used instead for secondary or Fallback Recovery. Thus Big Sur can be a problem when it comes to Recovery, and for this reason is best avoided on Apple silicon Macs. If it’s essential to install a copy of Big Sur, then be prepared for problems with Recovery mode.
macOS 11 also established the architecture for dual-boot partitions, with two or more Boot Volume Groups.
Although the Boot Volume Group has only ever referred to paired System and Data volumes, within each partition/container the group also requires three or four additional volumes, for Preboot, Recovery, VM and (apparently in Big Sur only) Update. How those work with multiple Boot Volume Groups is explained below. Once way to avoid the inevitable complexities is to install each Boot Volume Group into a separate partition/container, which provides each with its own suite of Preboot, Recovery and VM volumes.
As the Signed System Volume (SSV) was introduced in macOS 11, versions of APFS prior to 1677.x.x shouldn’t be expected to understand SSVs.
macOS 12-15
The next significant architectural changes in Apple silicon Macs were the introduction of paired Recovery volumes in macOS 12 Monterey, and of cryptexes in macOS 13 Ventura.
In macOS 11 and 12, Safari, its supporting components, and some other parts of macOS are installed to the Data volume for ease of maintenance. Apple replaced that with separate secure disk images termed cryptexes, loaded from the Preboot volume during the boot process and grafted into the root file system. As a single Preboot volume can be shared by more than one Boot Volume Group, bundled cryptexes must be provided to the correct group, and I suspect that’s accomplished by associating them with their Volume Group UUID. If that becomes confused in any way, cryptexes could be incorrectly associated or missing altogether, something that’s almost certainly fatal to the boot process.
Above is the current layout of a partition/container containing a single bootable system for a Mac running Sequoia. Device names given are illustrative, although their numbering is typical of that seen for external bootable volumes. In this instance, the base name for the Boot Volume Group is External, and the External System volume is unmounted as usual.
Below is a typical partition/container containing two bootable systems named ExternalA and ExternalB. This has two Boot Volume Groups, each consisting of a System volume with its SSV, and a Data volume, to which are added their three common volumes, Preboot, Recovery and VM.
Management
Creation
The most reliable tools for creating and working with Boot Volume Groups and other system components are those in macOS installer apps, and even they can have their moments and bugs. It’s usually possible to ‘clone’ groups using the asr command tool, a feature that’s offered in some third-party utilities including Carbon Copy Cloner and SuperDuper. However, Apple has made it clear that given a choice between supporting asr and addressing boot security, it gives the latter absolute priority. asr has suffered some serious bugs since the SSV was introduced in Big Sur, and shouldn’t be relied on.
asr is careful to ensure that, when cloning Boot Volume Groups, UUIDs are changed so that it doesn’t end up with volumes or groups with the same UUID. That may not be the case when using some other tools such as dd for duplication. If you prefer a simple and stress-free life, it’s better to put your trust in a macOS installer rather than try crafting your own Boot Volume Groups.
Apple’s own tools such as Disk Utility now try to steer the user away from making mistakes, such as deleting just one of a Boot Volume Group, leaving the other orphaned with its firmlinks broken.
Firmware
Firmware is another source of confusion. That installed in the Mac, using its internal storage, should always reflect the firmware that has been included in the most recent version of macOS installed or updated on that Mac, whether that was installed to the internal SSD or to an external disk. The only exception to this is when installing or updating macOS in a Virtual Machine, which can’t affect the host’s firmware.
What may appear more puzzling are the versions reported in System Information: that given as System Firmware should be the iBoot version for the main Mac, and the most recent. The OS Loader, though, varies with the Boot Volume Group, and in older macOS is likely to be earlier than the iBoot version of the main Mac.
Recovery
Recovery system versions are even more complex. When everything works as it should, the version installed in any paired Recovery volume should be the newest of the Boot Volume Groups that it’s paired with, in the same partition/container. If a Mac running 15.3 from its internal SSD has a bootable external disk with a single container with two Boot Volume Groups for 13.7 and 14.7, then the Recovery system for the internal SSD should be 15.3, while that shared by the two systems on the external disk should be 14.7. It’s likely that Fallback Recovery on the internal SSD will be from an earlier version of macOS 15, but that’s less predictable, and there’s no separate Fallback Recovery in external systems.
Switching between systems and their Boot Volume Groups is normally performed using Startup Disk in General settings, or its equivalent in System Preferences. Those record the chosen Boot Volume Group in NVRAM, from where it’s used during the next boot.
That setting is used to determine which Recovery system is used if the next boot is performed with the Power button pressed to enter Recovery mode. That in turn determines what can be performed in Recovery. This is most critical for determining how Startup Security Utility works, as that can only change boot security settings for the chosen Boot Volume Group saved in NVRAM.
For example, in the dual-boot container shown above, selecting ExternalB as the Startup Disk, shutting down, then starting up into Recovery mode should enable Startup Security Utility to control boot security for ExternalB but not ExternalA, nor the system installed on the internal SSD. This can be used to discover which Recovery system is running: open Startup Security Utility and the only boot system that can be changed there is the current default boot system.
APFS
Although APFS should be backward compatible, making it relatively safe to make changes to an older version of APFS from a newer system, forward compatibility is more limited. Using older versions of Disk Utility or tools like fsck on newer versions of APFS risks errors, failure and at worst damage. The Appendix at the end of this article summarises version numbering in APFS and major changes to beware of. Although not easy to discover the version of APFS used to create or modify any given volume, one way is to use fsck_apfs -n -S [device]
giving the volume’s device name. The report should then be prefaced by a statement such as The volume [volume name] was formatted by diskmanagementd (1412.141.1) and last modified by apfs_kext (945.250.134).
telling you that volume was created by macOS 10.15, and was last changed by macOS 10.14.
Troubleshooting
The first and fundamental step in trying to diagnose the cause of problems with multiple Boot Volume Groups or bootable external disks is to examine their container and volume structure using two diskutil commands: diskutil apfs list
lists all APFS volumes by container and gives key information about each, including role and UUID, and diskutil apfs listVolumeGroups
lists all recognised Boot Volume Groups, which you can tally against the first. Pipe these to text files so you can study and refer back to them.
Those should enable you to verify that the structure is as intended, and to establish the relationships between systems and paired Recovery volumes. From there you should be able to focus on the Boot Volume Group that’s misbehaving, ensuring that its Data volume has been backed up. If necessary, that can be used as a migration source if that group needs to be deleted and reinstalled.
Tips & tricks
The host Mac must be capable of running that version of macOS.
macOS installers are the most reliable means of creating and installing Boot Volume Groups.
During macOS installation, an external disk must be connected to a port other than the DFU port, as listed here and in Mactracker.
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 an installer volume through Recovery mode.
When using a laptop Mac, run it from mains power throughout macOS installation.
Apple silicon Macs boot from external disks in Full Security, and reducing that doesn’t solve any problems.
Each container with one or more Boot Volume Groups contains one set of Preboot, Recovery and VM volumes shared between them.
If you’re unsure which Recovery system you’re using, open Startup Security Utility, as the only group it can change settings for is the one it’s booted into.
Big Sur doesn’t support paired Recovery on Apple silicon, and that can cause problems.
The version of Recovery installed in any paired Recovery volume should be that of the newest of the Boot Volume Groups that it’s paired with.
Use fsck_apfs -n -S [device] to discover the APFS version.
Use diskutil apfs list and diskutil apfs listVolumeGroups to discover volume structure.
Try using a Virtual Machine instead, if you don’t need to be able to run software from the App Store.
Appendix: APFS version numbers
APFS major version numbers change with major version of macOS:
macOS 10.12 has APFS version 0.3 or 249.x.x, which shouldn’t be used at all.
10.13 has 748.x.x, which doesn’t support Fusion Drives, but has basic support for volume roles.
10.14 has 945.x.x, the first version to support Fusion Drives.
10.15 has 1412.x.x, the first version to support the multi-volume boot group, and introduces extended support for volume roles, including Data, Backup and Prelogin.
11 has 1677.x.x, the first version to support the SSV, and Apple silicon. On M1 Macs, it doesn’t support the paired Recovery volume.
12 has 1933.x.x until 12.2, thereafter 1934.x.x, which support the paired Recovery volume on Apple silicon.
13 has 2142.x.x, and is probably the first to support trimming of UDRW disk images and their storage as sparse files.
14 has 2235.x.x, until 14.3, thereafter 2236.x.x.
15 has 2313.x.x until 15.2, thereafter 2317.x.x until 15.4, thereafter 2332.x.x.
One of the magic tricks that characterised the Mac was its association between documents and their apps. No longer did a user have to type in both the name of the app and the document they wanted it to edit. All they needed to do was double-click the document, and it magically opened in the right app.
In Classic Mac OS, that was accomplished by hidden Desktop databases and type and creator codes. For example, a text document might have the type TEXT and a creator code of ttxt. When you double-clicked on that, the Finder looked up which app had the creator code ttxt, which turned out to be the SimpleText editor, and opened that document using that app.
Although those ancient type and creator codes still live on today in modern macOS, they no longer fulfil that role. Instead, each file has what used to be a Uniform Type Indicator (UTI), now wrapped into a UTType, such as public.plain-text, normally determined by the extension to its name, .txt or .text. When you double-click on a file, LaunchServices looks up that UTType in its registry, discovers which app is set as the default to open documents of that type, then launches that app with an AppleEvent to open the document you picked.
Recognising that we often want to open a document using a different app rather than the default, the Finder’s contextual menu offers a list of suitable apps in its Open With command. That list is built and maintained by LaunchServices, and has changed in recent versions of macOS. Whereas those lists used to consist of apps installed in the traditional Application folders, LaunchServices now scours every accessible volume and folder using Spotlight’s indexes to build the biggest lists possible. If you happen to have an old copy of an app tucked away in a dusty corner, LaunchServices will find it and proudly display it alongside those in everyday use, like a game dog triumphantly presenting not one dead pheasant but every one from miles around.
For those with lean systems, this gives them the flexibility to open a large text document using BBEdit rather than TextEdit, or to select which image editor to use for a JPEG. But for those of us with lots of apps lurking in storage, the result is absurd and almost unusable. It’s bad enough working through the 33 apps that LaunchServices lists as PNG editors, but being offered 70 text editors is beyond a joke.
Unfortunately, there’s no lasting way to block unwanted apps from being added to the list LaunchServices builds for this Open With feature. You can gain temporary relief by excluding them from Spotlight search, but should you ever open the folder they’re in using the Finder, those are all added back. This also afflicts apps in folders shared with a Virtual Machine, where the list includes App Store apps that can’t even be run from within that VM.
There are, of course, alternatives. I could drag and drop the document from its Finder window towards the top of my 27-inch display to the app’s icon in the Dock at the foot, which is marginally less awkward than negotiating my way through that list of 70 apps.
But there are better solutions: why not empower me to determine which of those 70 apps should be offered in the Open With list? This is such a radical idea that it used to be possible with the lsregister command that has become progressively impotent, as LaunchServices has cast its net further in quest of more apps to flood me with. Or maybe use a little machine learning to include only those text editors I use most frequently to open documents? Apple could even brand that LaunchServices Intelligence, although that’s a little overstated.
I can’t help but think of what those magicians from forty years ago would have done, but I’m certain they wouldn’t have offered me that list of 70 apps to choose from.
Given that it was over three years before Apple first shipped a Mac with an internal hard disk, it’s not surprising that one of its early shareware apps was Harry Chesley’s PackIt III for compressing archives of files, in 1986. At that time, the emphasis was more on working out how to archive both forks of Mac files and how to restore them, and less on achieving efficient compression.
The following year, 16 year-old Raymond Lau, then still a high school student, developed and marketed its replacement, Stuffit, which rapidly established itself as the standard, and probably the most popular shareware utility for the Mac. From 1987 until the release of Mac OS X in 2001, Stuffit had few rivals and its .sit archives were widespread across Macs, but didn’t make it to PCs or Windows until much later.
In 1988, Aladdin Systems was formed to take over development and sales of Stuffit, and in 2004 it changed name to Allume Systems, and was bought by IMSI. The following year, Allume was bought by Smith Micro Software, Inc.
Aladdin continued a shareware version as Stuffit Classic, and launched a commercial version as Stuffit Deluxe. This line-up was later augmented with a freeware decompressor Stuffit Expander that was bundled in Mac OS X until 10.4 Tiger.
Less known today are Stuffit’s self-expanding archive apps, with built-in decompressors and the extension .sea, that enabled the few Macs without a copy of Stuffit to open them with a double-click.
Until more powerful Macs of the mid-1990s, compression was performed in software and painfully slow. One of the more popular add-in cards for expandable Macs like the Macintosh II was Sigma Designs’ DoubleUp NuBus card that compressed in real time using Salient Software’s DiskDoubler.
This is Stuffit Deluxe version 8.0.2 from 2003, the year before Aladdin was renamed Allume.
Stuffit Deluxe included support for conversion to and from BinHex encoding, used for sending binary files via email without the risk of data corruption.
DropStuff was a drag-and-drop tool or droplet for compressing files into Stuffit, Zip or Tar archives, with support for encryption, and segmentation for use where file sizes were limited.
Its Zip option also preserved resource forks.
Archives in a range of formats, including RAR, could be managed in Stuffit Archive Manager, which could even schedule automatic creation of archives.
Although Aladdin launched a Mac OS X version with a new archive format, .sitx, and support for additional compression methods beyond its own proprietary formats, Stuffit entered decline by the time it was acquired by Smith Micro. Compression requirements had changed in Mac OS X, with decreasing use of resource forks, and free availability of bundled cross-platform compression tools such as GNU Gzip.
In 2007, BetterZip supported a standard set of compression formats, including 7-Zip, but never really caught on.
This is cross-platform WinZip seen in 2015, five years after its first release for the Mac. This originated as a graphical interface for PKZIP.
Apple started including compression tools in /System/Library/CoreServices, initially with BOMArchiveHelper in Mac OS X 10.3 Jaguar, which became Archive Utility that lives on today, supporting the Compress command in the Finder’s contextual menu. This uses a modified implementation of the Zip method that preserves extended attributes, successor to the resource forks of Classic Mac OS.
For many years, Mac OS X has had access to compression at a system level, but Apple has unaccountably not opened that up to developers. In modern Macs, compression is extensively used both on disk and in memory. However, in macOS Big Sur in 2020 Apple introduced AppleArchive with its system-level support for LZ4, LZMA, zlib and a proprietary implementation of LZFSE, and those are available in a new command tool aa.
Archive Utility offers a few options, and from 2020 has included support for plain and encrypted AppleArchive format.
The arrival of Apple silicon Macs has expanded options available for compression utilities to make better use of their two core types and energy efficiency. Freeware Keka now gives the user the choice.
Legacy copies of Stuffit are still available from here.
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.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5291. As usual, Apple doesn’t release information about what security issues this update might add or change.
This version amends the Yara rule for MACOS.PIRRIT.OBF.DROPPER, but doesn’t add any new rules.
You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.
A full listing of security data file versions is given by SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5291.
Sequoia systems only
This update has also been released for Sequoia via iCloud. If you want to check that manually, use the Terminal command sudo xprotect check
then enter your admin password. If that returns version 5291 but your Mac still reports an older version is installed, you can force the update using sudo xprotect update
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
In the last couple of weeks I’ve been asked to help recover data lost when files have been accidentally deleted, and an internal SSD has been wiped remotely using Find My Mac. What we perhaps haven’t fully appreciated is how improved security protection in our Macs has made it far harder, if not impossible, to recover such lost data. Allow me to explain in three scenarios.
Lost files on a hard disk
When files are deleted from a hard disk, the file system marks them as no longer being in use, and they’re left in place on the hard disk until they need to be overwritten with fresh data. If the hard disk has ample free space, that could occur days, weeks or even months later. Data recovery software and services can be used to scan each storage block and try to reconstruct the original files. If the file system and its data are encrypted, the encryption key is required to enable the contents to be decrypted.
There’s extensive experience in such data recovery, and provided the disk isn’t physically damaged or malfunctioning, results can be surprisingly good. As services charge according to the amount of data they recover, there are also strong incentives.
This works both ways, of course, in that someone who gets access to that hard disk could also recover files from it if they’re unencrypted. For this reason, when you’re passing on or disposing of a hard disk, you should perform a secure erase to overwrite its entire contents. If it’s going for recycling, once that has been done, you should also render the disk unusable by physically damaging its platters.
Deleted files on an SSD
What happens on an SSD depends on whether there’s already a snapshot of that volume. If there is, and that snapshot includes the deleted files, the file system metadata for them is retained in that snapshot, and the storage containing their data is also retained. The files can then be recovered by mounting that snapshot and either reverting the whole volume to that earlier state, or copying those files to a different volume.
If there’s no prior snapshot containing the files, the file system marks their extents as being free for reuse. At some time after their deletion, that information is sent to the SSD in a Trim command. When the SSD next has a moment to perform its routine housekeeping, the physical storage used will then be erased ready to be written to again.
Although there’s some uncertainty as to when that Trim command will be sent to the SSD, one time that we know that supported SSDs are Trimmed is during mounting, in the case of an internal SSD when that Mac starts up. So if your Mac has started up since the files were deleted, those files are most likely to have been completely erased from its internal SSD. With their erasure, chances of ever recovering those files have gone.
Wiped Data volume
Macs with T2 or Apple silicon chips have an ingenious method of ‘wiping’ the entire contents of the Data volume when it’s encrypted on the internal SSD. This can be triggered using the Erase All Content and Settings (EACAS) feature in the Transfer or Reset item in General settings, or remotely via Find My Mac. Either way, this destroys the ‘effaceable key’ and the ability to decrypt the contents of the Data volume, even if it’s not additionally protected by FileVault. As Apple states: “Erasing the key in this manner renders all files cryptographically inaccessible.”
This is to ensure that if your Mac is stolen, no one can recover the contents of its internal SSD once it has been wiped in this way. Nearly a year ago there were claims that old data could re-appear afterwards, but those turned out to be false.
I’m afraid that the only way to recover the data from a volume wiped using EACAS or Find My Mac is to restore it from a backup.
Backups are more important
For Intel Macs with T2 chips, and Apple silicon Macs, the chances of being able to recover files from their internal SSDs have become diminishingly small. This makes it all the more important that you make and keep good and comprehensive backups of everything in your Mac’s Data volume.
I’m always sad to hear of those who have suffered data loss, and shocked to learn of how many still don’t keep backups.
I hope that you enjoyed Saturday’s Mac Riddles, episode 300. Here are my solutions to them.
1: The first chips with six-packs celebrated Halloween.
Click for a solution
M3
The first chips (Apple silicon SoCs) with six-packs (the M3 family is the first to support six-core clusters) celebrated Halloween (they were announced at Apple’s ‘Scary Fast’ event on 30 October 2023).
2: First with FireWire and almost see-through in its two-tone case.
Click for a solution
Power Macintosh G3 (Blue and White)
First with FireWire (it was the first Mac to come standard with FireWire ports) and almost see-through in its two-tone case (it has a distinctive translucent blue and white case).
3: It brought Exposé, Fast User Switching and Xcode.
Click for a solution
Mac OS X 10.3 Panther
It brought Exposé, Fast User Switching and Xcode (all three were new features in 10.3, released on 24 October 2003).
The common factor
Click for a solution
The number 3; in binary 11, which looks like the number 2 in Roman numerals.
Entitlements are settings baked into an app’s signature that enable it to do things that otherwise wouldn’t be allowed. Many let App Store apps do things their sandbox wouldn’t normally permit. Others give access to features that are controlled by privacy protection, so may be used by apps that aren’t sandboxed. A few enable apps specially approved by Apple to use features in macOS that aren’t generally available, such as working with APFS snapshots.
One way to run third-party apps in relative security is to confine them to a tightly restricted environment, a sandbox. That denies them the ability to access storage or other resources outside those dedicated to it in its sandbox. That’s too restrictive for the great majority of apps, which need to be able to open and save documents to folders such as ~/Documents, so entitlements specify which sandbox restrictions they’re allowed to break. In the case of opening and saving documents outside the sandbox, the entitlement is named com.apple.security.files.user-selected.read-write, and gives that app read and write access to files the user has selected in a standard macOS Open or Save dialog. Apple requires that all apps distributed through its App Store run in their own sandbox, so they all claim entitlements to be able to work beyond that.
Sandboxed apps all have their own entitlement to their sandbox, com.apple.security.app-sandbox, which isn’t used by apps that are notarized but not sandboxed. Whether sandboxed or not, an app might need access to the Mac’s camera, and for that it will need an entitlement named com.apple.security.device.camera.
Thus, entitlements fall into groups:
Those that can be used by any app that wants access to controlled features, depending on whether it’s sandboxed or not.
Those that give access to macOS features that have to be approved by Apple.
Those that are private to Apple’s own apps and can’t be used by third-parties.
Viewing entitlements
The Finder and other macOS utilities don’t reveal whether an app runs in a sandbox, nor list its entitlements. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency.
Apparency’s Entitlements pane lists all those baked into that app’s signature. My own free Taccy also lists entitlements, but for this purpose Apparency is the better tool by far.
Apps that aren’t sandboxed, only hardened and notarized, will only have entitlements if they need to access privacy-protected features, or use restricted features in macOS. In many cases, that means they will have neither entitlements nor a provisioning profile.
com.apple.security
These give an app access to files and features that are restricted, either by the sandbox, or by privacy protection.
Sandbox controls
These are options that extend an app’s abilities beyond the sandbox, starting with the entitlement that sets the sandbox in the first place. They aren’t used by apps provided outside the App Store that are only notarized and not sandboxed. Apple provides fuller details of the sandbox here.
Examples include:
com.apple.security.app-sandbox runs the app in a sandbox, and is standard for all sandboxed apps
com.apple.security.files.user-selected.read-write gives read and write access to files the user has selected in a standard macOS Open or Save dialog
com.apple.security.files.bookmarks.app-scope gives access to security-scoped bookmarks with app scope
com.apple.security.files.bookmarks.document-scope gives access to security-scoped bookmarks with document scope
com.apple.security.network.client allows it to open outgoing network connections
com.apple.security.print allows it to print.
Privacy controls
These give access to information, devices and features that are controlled by the privacy features in macOS, enforced either by Location Services or by TCC. These are used by any third-party app, whether supplied through the App Store or not, and include:
com.apple.security.personal-information.addressbook gives access to the content of the address book
com.apple.security.personal-information.location gives access to location data from Location Services
com.apple.security.device.camera gives access to the camera
com.apple.security.device.microphone gives access to the microphone
com.apple.security.automation.apple-events enables automation using AppleEvents.
These normally have a corresponding list in Privacy & Security settings.
com.apple.developer
These entitlements can only be granted by Apple, and control access to macOS features that aren’t generally available. Among the most common are:
com.apple.developer.endpoint-security.client enables it to monitor system events for potentially malicious activity using Endpoint Security
com.apple.developer.persistent-content-capture is required for a Virtual Network Computing (VNC) app to have persistent access to screen capture
com.apple.developer.driverkit gives an extension permission to run as a user-space driver
com.apple.developer.vfs.snapshot gives access to snapshot features
com.apple.vm.networking allows virtual network interfaces without their having to escalate privileges to the root user, typically in bridged networking.
com.apple.private
These are private to Apple’s own apps, and encompass many other com.apple entitlements that aren’t documented for third-party developers. Examples include:
com.apple.private.applemediaservices
com.apple.private.dmd.policy
com.apple.private.octagon
com.apple.authkit.client.private
com.apple.duet.activityscheduler.allow.
Some appear self-explanatory, others are opaque.
Command tools and standalone executables
Although Mach-O binaries such as command tools and daemons can be hardened and signed, thus can be notarized, they can’t have a provisioning profile embedded, so can’t have entitlements. Apple recommends working around this by wrapping them in an app-like structure, as explained here.
Entitlements for access to features controlled by privacy protection rely instead on the attribution chain to determine whether they’re entitled. Thus a command tool called by an app isn’t expected to have the entitlement, but the app calling that binary is.
Stripping signatures
Because entitlements are baked into the signature, if you were to strip the signature from an app, that would remove all its entitlements. For a sandboxed app, that might not be fatal, but for most other types of entitlement, that could render the app non-functional. Resigning the app with an ad hoc signature wouldn’t help either.
References
Apple’s Entitlements documentation Tech Note 3125 on provisioning profiles for code signatures
If you can’t find an entitlement in any of those lists, try looking in Jonathan Levin’s database of all known entitlements for iOS and macOS, which is as comprehensive as we’re likely to get.
Sometimes Macs behave in ways that you don’t forget. It was nearly six years ago, in 2019 when my iMac Pro was still running macOS Mojave, that it took over half an hour to start up in Safe mode. As became obvious, that was because it checked the integrity of every snapshot, including its long series of Time Machine backups. That behaviour stopped with the release of Catalina later that year, and revisiting the experience last week was interesting, when I examined what Safe mode does now in Sequoia.
Safe mode fsck
Checking disk integrity has long been a feature claimed of Safe mode, although Apple has only recently clarified that its checks are “similar to the more comprehensive check performed by the First Aid feature of Disk Utility,” unlike those in the days of Mojave.
Because these are run when starting up into Safe mode, macOS can’t report them directly to the user. There are only two places for their results to be recorded: in the fsck_apfs log at /var/log/fsck_apfs.log (and its error log at /var/log/fsck_apfs_error.log), and in the Unified log, neither of which are likely to be visited by users. It doesn’t seem possible that checks could be run before entries are made in the Unified log, and if they were their results would be inaccessible, and of no value to the user.
If you do look there, you might be surprised to discover that the checks run by fsck_apfs are ‘quick checks’, described as a “check whether the device is `clean’. If device is an APFS volume, fsck_apfs will quickly check the APFS container and the specified APFS volume. If device is an APFS container, fsck_apfs will quickly check the APFS container and all the APFS volumes in it. By default, no repairs are attempted during a quick check.” Thankfully they also no longer include Time Machine snapshots or backups.
For users, the most important of volumes to be checked is the Data volume in the current boot volume group. Yet careful examination of both log records reveals that such checks fail, returning error 65, because the device is mounted with write access. Although they could be performed using fsck_apfs‘s live verification, no attempt is made to do that. From the active boot volume group, only the Recovery and Update volumes are checked, together with all accessible external volumes.
Normal user fsck
Before you think that’s better than making no checks at all, the sequence of fsck_apfs checks run at the start of Safe mode appears to be identical to those made during startup into normal user mode, and reports the same failures. Thus, in this respect Safe mode is no different from normal, despite Apple listing this as a feature of Safe mode.
It’s worth reading the fsck_apfs man page to see the many options available in this command, which is the basis for all checks and repairs made to APFS volumes and containers. There are two in particular that you may prefer to invoke rather than using Disk Utility’s single option to both check and repair. My favourites that make it worth opening Terminal instead of Disk Utility are -n to prevent it from attempting to make any repairs, and -S to skip snapshots.
Given that fsck_apfs appears unable to repair any errors it finds in snapshots and admits to that in its man page where it states that “no repairs can be made”, it puzzles me that without the -S option it will still check all snapshots it comes across when running its checks. Perhaps it’s time to alter that default behaviour and make checking snapshots the explicit option.
First Aid
Disk Utility’s First Aid is descended from a succession of utilities starting with the Disk First Aid app in Classic Mac OS, which separated disk Verify and Repair features.
Mac OS X merged the two Classic apps Drive Setup and Disk First Aid, but kept them as distinct tools within its new Disk Utility app and retained separate Verify and Repair features.
Those two features were still present in Mountain Lion or Mavericks, shown here, but soon afterwards only Repair was available.
Now that APFS is mature and has proven itself more than a worthy successor to HFS+, the need to both check and repair its containers and volumes should be abating. This would be a good time to return to separate controls, allowing users to check APFS in the expectation that there are no errors to be found. This is more important now because of the absence of any alternatives.
Monopoly
Disk Utility is in a unique position. Apple has chosen to lock third-parties out of developing competing disk repair utilities, in particular those that can be used in Recovery mode. Users can’t opt for apps with more or better features, putting the onus on Apple to provide a comprehensive solution that meets users’ wishes, not its idea of essential requirements.
Conclusions
Apple needs to be explicit about what disk checks are run in Safe mode, and where users can inspect their results.
fsck_apfs is flexible and powerful, but has strange defaults that merit reconsideration.
Disk Utility should offer more options beyond its single ‘check and repair’, in particular to check only and with snapshots excluded. Those are most important in Recovery mode, where there can be no alternative.
Here are this weekend’s Mac riddles to entertain you through family time, shopping and recreation.
1: The first chips with six-packs celebrated Halloween.
2: First with FireWire and almost see-through in its two-tone case.
3: It brought Exposé, Fast User Switching and Xcode.
To help you cross-check your solutions, or confuse you further, there’s a common factor between them. To celebrate this anniversary edition, that’s a number which can be expressed in a way that a Roman might read as being one less than it really is.
I’ll post my solutions first thing on Monday morning.
Please don’t post your solutions as comments here: it spoils it for others.
With Mac OS X came a new tool for installing and updating the system, quite different from what had been used in Classic Mac OS. The Mac OS X Installer app uses packages (.pkg), and metapackages (.mpkg) containing multiple packages to be installed together. Apple thus provided installations and updates as metapackages that could either be downloaded from its update servers using Software Update, or from the update’s web page. The same method was used until Big Sur, when updates changed again.
A system update in Mac OS X 10.1.3 in March 2002 was installed by the Installer app following authentication.
This update required just 148 MB of disk space, and could readily be accommodated by any of these volumes of 11.5 GB capacity.
Most updates were concluded by a period ‘optimising system performance’, as determined by the post-install scripts in the package.
Here, Software Update is delivering Security Update 2004-05-03 to Mac OS X 10.3.3 Panther. Some system components like QuickTime were still supplied and installed separately, but the great majority of Mac OS X was integrated into a whole, and there were no options to install separate components.
Over this period, the system and user data shared a single boot volume, and updating the system mainly involved replacement of updated files. Installer packages contained those replacements together with scripts that were run to update the contents of the boot volume. For much of this, firmware updates were still supplied and installed separately, although later they were integrated into macOS updates.
Until the introduction of System Integrity Protection (SIP) in El Capitan, the only protection provided to system files and folders was in their permissions. Incomplete or incorrect installations and updates were therefore not uncommon, as despite its name, SIP didn’t have any means of verifying the integrity of system files. A procedure was introduced to verify directory structures and permissions against those listed in the Bill of Materials (BoM) for macOS updates, by repairing permissions, but that was still unable to verify the integrity of the files themselves.
Installer metapackages are highly portable, and were commonly downloaded to be installed on multiple Macs. To keep updates as small as possible, they were provided in two forms: a Delta update converted only the previous release, while a Combo update contained everything required to update the last major version and all intermediate minor versions in a single step.
The High Sierra 10.13 upgrade in September 2017 brought greatest change, with its inclusion of Apple’s new file system APFS. Macs that didn’t have a Fusion Drive had their system volume converted to APFS during the upgrade, although it was another year before the same happened to Fusion Drives.
Updates didn’t always work out right for everyone. This was a common problem with High Sierra Supplemental Update of 29 November 2017, for example.
This all changed with the first version of macOS to boot from a signed snapshot, Big Sur, in November 2020, to support the improved Secure Boot of Apple silicon Macs. This abandoned the use of Installer packages, relying instead on an Update Brain integrated into each installer app and downloaded update.
From then onwards, Apple has provided several different presentations of macOS installers and updates:
Updates are only delivered through Software Update or its command tool equivalent softwareupdate, and have to be downloaded from Apple’s servers, or delivered through a local Content Caching Server.
Full macOS installer apps are offered in the App Store then delivered through Software Update.
Full macOS installer packages are available through softwareupdate or direct from Apple’s servers, and are named InstallAssistant. When installed, these create a full installer app.
Full macOS installers are offered in Recovery, from where they’re downloaded from Apple’s servers.
Full IPSW images containing firmware, Recovery and macOS partitions can be installed to restore Apple silicon Macs in DFU mode, using Apple Configurator 2 or later versions of the Finder. Those effectively reset that Mac to factory condition with that version of macOS pre-installed.
There are further complications to this. For instance, an older macOS Installer app can’t be run in a newer major version of macOS. The workaround for that is to create a bootable installer volume, and boot from that to run its older installer.
macOS updates are supplied compressed, and require up to 30 minutes preparation before they can be installed.
There are now no optional installations, as every copy of any given version of macOS is identical within its Signed System Volume (SSV).
The size of these new updates is considerably greater than those of older Installer packages, particularly in Big Sur, as engineering optimisations were being performed.
This chart shows cumulative sizes of updates to macOS on Intel Macs from 10.14 Mojave, with its traditional single boot volume, through to macOS Sonoma 14.6. Each point represents the cumulative sum of all updates to that major version of macOS required to reach that minor version. Thus the point for 14.2 is the total of update sizes for 14.1, 14.1.1, 14.1.2 and 14.2. Sizes used aren’t those reported by Software Update, but those of the download itself, as reported in articles here, indexed on this page. Lines shown are best fits by linear regression.
Update sizes rose markedly from Mojave, with its single boot volume, to Catalina, with its boot volume group, and again to a peak in Big Sur, with the SSV. They fell again as Monterey introduced greater efficiency, and Ventura and Sonoma have been almost identical, and smaller than Mojave.
Apple silicon Macs started with the huge updates of Big Sur, which were even larger than those for Intel models, and benefitted from the improved efficiency of Monterey and Ventura. Unlike Intel Macs, though, Sonoma has seen further reduction in update sizes, although in each update they remain significantly larger than those for Intel models.
macOS Ventura in 2022 experimented with Rapid Security Responses (RSRs), much smaller updates intended to provide urgent security fixes to Safari and some of its supporting components. These take advantage of cryptexes, cryptographically verified disk images stored on the hidden Preboot volume. Updating cryptexes alone is far quicker too, as the SSV is left untouched. Unfortunately, the second RSR resulted in serious problems with Safari so had to be replaced three days later. The last RSR was released on 12 July 2023, and they appear to have been abandoned since.
Upgrading to the first release of the next major version of macOS had required downloading its full installer app from the App Store. Apple broke from this in macOS Ventura in October 2022, when that new macOS was installed as an update instead. Although this reduced its size and installation time required, it caught many users on the hop, as Apple provided no warning of the change. This approach has since become standard with both Sonoma and Sequoia.
Installing and updating the Mac’s operating system has probably changed more over the last 41 years than any other feature.
Safe mode is an undervalued tool for dealing with a broad range of problems in macOS. Although not a universal panacea, it has several valuable uses, and can be helpful before having to resort to more time-consuming diagnostic procedures. This article explains how to engage your Mac into Safe mode, what it does, and when you should use it. This is based primarily on macOS Sequoia 15.3.2 running on Apple silicon Macs, but does cover Intel models, and much should apply to recent versions of macOS.
Entering Safe mode
Consider first whether you should disconnect some or all non-essential peripherals. If you’re only intending to use Safe mode to flush caches, or to install an awkward macOS update, that shouldn’t be necessary. When trying to diagnose potential problems with extensions, though, it could be beneficial.
Apple silicon Mac
The Mac must be shut down to begin with. Press its Power button and keep it held in until you see its Recovery options loading. Then select the startup disk you want your Mac to boot from, and hold the Shift key. The button underneath that disk icon will change to read Continue in Safe Mode. Click on that button, and your Mac will restart.
Normally, you’ll be asked to log in twice, and initially, at the upper right of the display, the words Safe Boot will be shown in red.
Intel Mac
All you need do with an Intel Mac is start up (or restart) with the Shift key held down until you see the login window. If you have set a firmware password, you’ll need to remove that in Recovery before trying to start up in Safe mode.
Checking
Once your Mac is running in Safe mode and you’ve logged in, check that it really is in Safe mode by opening System Information. Click on Software at the left, and the line Boot Mode should say Safe rather than Normal.
If you can’t start your Mac up successfully in Safe mode, Recovery is your only option, where you might consider reinstalling macOS.
Leaving Safe mode
To leave Safe mode and return to normal mode, simply restart the Mac.
“Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren’t required by macOS, and fonts that weren’t installed by macOS.”
“Performs a basic check of your startup disk, similar to the more comprehensive check performed by the First Aid feature of Disk Utility.”
“Clears some system caches, including font caches and the kernel cache. These are automatically created again as needed.”
Apple warns that some macOS features may not work when in Safe mode. Those could affect “video capture, graphics performance, file sharing, Wi-Fi, accessibility, audio devices and devices connected via USB, Thunderbolt or FireWire.” In practice these seem to vary according to Mac and macOS, making it hard to know what to expect. Most USB and Thunderbolt storage should still work normally, and Time Machine backups should continue as usual when running in Safe mode.
Blocking extensions and customisations
Booting in Safe mode blocks the loading of all third-party kernel extensions, and may delay the loading of some of those provided in macOS. Specifically, those in the Auxiliary Kernel Collection (AKC) aren’t loaded, and any devices or features relying on them won’t be available. All kernel extensions in the main Kernel Collection appear to be loaded normally. If you suspect that your Mac’s problems could relate to a third-party kernel extension, this makes Safe mode an excellent diagnostic test without having to alter Startup Security for an Apple silicon Mac.
Apple adds to that login items, system extensions (the modern replacement for kernel extensions), and fonts not installed by macOS. These are other common causes of compatibility problems, adding to the value of Safe mode.
Checking the startup disk
Older versions of macOS performed extensive checks of both disks and snapshots using fsck_apfs. Apple discontinued those some years ago, because they extended Safe boot time to periods sometimes exceeding half an hour. Since then, checks performed by fsck_apfs don’t include snapshots, and are quick checks rather than a full check-and-repair. As they’re performed after the Data volume in the active boot volume group has been mounted, they only cover a limited range of volumes: from the active boot volume group, only the Recovery and Update volumes are checked, together with all accessible external volumes. Results are written to the fsck_apfs logs at /var/log/fsck_apfs.log and /var/log/fsck_apfs_error.log, and in entries in the Unified log.
Those checks in Safe mode currently appear identical to those made during a normal boot. Accordingly, if you want to perform checks on your Mac’s current boot volume group, you should do so using Disk Utility or fsck_apfs in Recovery mode. Safe mode is no longer a useful tool for performing disk checks.
Deleting caches
Discovering exactly which caches are emptied or deleted isn’t straightforward. Beyond Apple’s two instances of font caches and the kernel cache (which only applies to Intel Macs), none of the caches used by Launch Services appear to be affected by this. Neither does this appear to include other notable caches and hidden data stores, such as those for QuickLook or Spotlight.
macOS updates
Although not mentioned by Apple, one longstanding use for Safe mode is to download and install macOS updates. This may have become less used since updating was re-engineered for Big Sur, but is always worth bearing in mind. A short visit to Safe mode, lasting just a couple of minutes before restarting in normal user mode, can also fix problems discovered after updating or upgrading macOS; if a normal restart doesn’t sort them out, try Safe mode before calling Apple Support.
Safe mode in Apple silicon Virtual Machines
Safe mode is available when running lightweight virtualisation of macOS on an Apple silicon Mac, provided that the host operating system is Ventura or later, which provides the option to start the VM in Recovery mode. Enable that option before starting the VM, then use the normal procedure to restart in Safe mode. When you shut down that VM, remember to disable starting in Recovery before running the next VM.
Good reasons for Safe mode
To identify and locate problems with third-party kernel extensions.
To identify and locate problems with third-party system extensions, fonts, login items, and other user customisations, as a quicker alternative to creating a ‘clean’ user account.
To download and install macOS updates, when they don’t work in normal mode.
To fix problems following macOS updates, when a normal restart doesn’t help.
To clear font and other user caches.
When there are problems preventing booting in normal mode, short of going to Recovery mode.
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.
Login
