I wonder whether we’ll look back at 2024 as the year that Apple Intelligence came to our Macs and devices?

While there are plenty of nay-sayers, and those who still accuse Apple of falling behind, there can be few who aren’t aware of what’s available to those who have bought a recent Mac or one of the higher-end iPhones or iPads. Since Apple’s attempt to hijack the established abbreviation AI at WWDC last summer, we have heard little else. There can have been few minor updates that were sold as heavily as the autumn’s x.1 and x.2 releases for their lavishly preannounced new features.

We’ve been beta-testing some of those features for as long as we’re normally allowed for a whole major release of macOS. Over that period, the number of users who have switched to English (US) as their primary language must have been substantial. It’s the first time I have kept one of my Macs running beta-releases long after the annual macOS upgrade, and I only reverted when 15.2 was released with AI support for English (UK).

Although these AI features have their uses, and for many should prove quietly revolutionary, I’m not convinced that they transform our Macs or devices into anything even remotely intelligent, and a far cry from the great thinkers in Raphael’s masterpiece The School of Athens. The central figures here are Plato (left), who carries in his left hand a book titled TIMEO (I am afraid), and Aristotle (right), whose book bears the word ETICA (ethics). Seen further to the left in profile is Socrates, and below him is Pythagoras writing in a book while a boy holds in front of him a small blackboard showing the theory of harmony.

Contrast that hullabaloo about AI with Apple’s complete silence on security, specifically the changes brought in its front-line malware detection feature XProtect in macOS Sequoia, since its release on 16 September. Prior to that, XProtect’s data bundle, including its Yara file of detection signatures for malicious software, had been maintained by the general macOS update service through softwareupdated. The diagram below outlines this long-established process.

When Sequoia 15.0 was released, that changed to what has turned out to be an intermediate invoking both the old mechanism and the new.

For the first couple of weeks of that, XProtect updates were chaotic:

• 13 Sep (approx) Software Update Service stopped providing regular XProtect updates
• 13 Sep (approx) XProtect version 5273 available from Software Update Service for Sequoia only
• 16 Sep macOS 15.0 released, with version 5273 available from Software Update Service for Sequoia only; upgraded Macs updated to 5273 by copying from secondary to primary locations; 5273 not provided from iCloud, where 5272 remained the current version
• 18 Sep Software Update Service resumed delivery of 5272 to Sonoma and earlier
• 18 Sep Software Update Service started delivery of 5274 to Sonoma and earlier; 5273 no longer available for Sequoia, with 5272 still available from iCloud
• 24 Sep Software Update Service delivered 5275 for Sequoia; no change to Sonoma and earlier, and 5272 still available from iCloud.

Then, just as we were getting the hang of it, Sequoia 15.2 excised the old mechanism, as we discovered last week when Apple released the first update to XProtect since 15.2.

Throughout all of this, Apple has remained completely silent. What’s even more surprising is that in the last few days, Apple has updated its definitive guide to security for Macs and all its devices. Although not all localised English translations have yet been synced with its US or Canadian English versions, the account of XProtect now has a published date of 19 December 2024, but doesn’t mention September’s changes.

There are those who insist that none of this is our concern, we should just let Apple do whatever it deems appropriate, and we shouldn’t even know what version of XProtect’s data is installed, as macOS takes care of all that for us. However, the security of my Mac is very much my business. If I were to unwittingly install malware that stole sensitive information, those are my banking details at risk, not Apple’s. Should I suffer financial loss as a result, would Apple provide unlimited compensation?

Hardly. Read sections 8 and 9 of Apple’s licence for macOS Sequoia, and the onus is clearly placed on the user. Just to emphasise this, further down that licence, in the Apple Pay & Wallet Terms and Conditions, is the express statement: “You are solely responsible for maintaining the security of your Mac Computer, Supported Devices, your Apple Account, your Touch ID information, the passcode(s) to your device(s), and any other authentication credentials used in connection with the Services (collectively, your “Credentials”).” The next time someone says that you should leave the security of your Mac to Apple, remind them of that.

Apple also encourages us to take an active part in our Mac’s security protection, and provides us with tools for doing so. The description given in man xprotect is a good example: “xprotect is used to interact with XProtect. It is useful for administrators or users who want to manually invoke XProtect functionality.”

Information about XProtect updates is exposed in the GUI, in System Information, where each update including those delivered by both old and new mechanisms is listed, together with its version number. That in itself is puzzling, as recent entries incomprehensibly duplicate older XProtectPlistConfigData entries with newer XProtectCloudKitUpdates.

So if AI doesn’t bring us the School of Athens, what has macOS Sequoia achieved so far? For this second image I turn to Lovis Corinth’s first major painting after his near-fatal stroke just before Christmas in 1911, an autobiographical portrait expressing his frustrations, in The Blinded Samson from 1912.

Please don’t breathe a word of this over on Apple Support Communities, though, where it seems your Mac’s security should be like mediaeval religion, a matter of blind faith and the suppression of knowledge. It’s high time for a Renaissance, much more Enlightenment, and a modicum of Intelligence.

Apple provides so many services for different parts of macOS that it’s hard to keep track of them. If you want to see a short summary, this article lists all service connections for enterprise network administrators, although it doesn’t detail which services use which servers, for example referring to “macOS updates” in many entries.

Many of you seem surprised to learn that Sequoia’s new XProtect updates come from iCloud, although Apple has been using iCloud for similar purposes for at least the last five years.

One good example that’s used every day on your Mac are the notarization checks sometimes run by Gatekeeper when macOS launches executable code, such as an app. In that case, com.apple.syspolicy processes the app’s notarization ticket
looking up ticket: <private>, 2, 1
by trying to fetch its record from iCloud using CloudKit. That’s followed by log entries indicating the network access required to connect with iCloud and check the ticket. Success is reported by com.apple.syspolicy in
CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
looking up ticket: <private>, 2, 0
and further lookups. I first reported those checks with iCloud back in Catalina, in 2019.

A simple way to illustrate the differences between this and using the general softwareupdated service is to compare what happens in the log when you ask if there are any updates available.

softwareupdate

When SilentKnight does this, it uses the only supported method, the softwareupdate tool, as used to keep XProtect up to date in all versions of macOS prior to Sequoia. That command hands over to the softwareupdated service to run the check. That in turn uses components of com.apple.SoftwareUpdateController to summarise the update state of that Mac, connect to the Software Update Server, check all the current versions and build numbers of macOS and its ancillaries, and arrive at a list of updates required. This is even more complex than it sounds, as com.apple.SoftwareUpdateController has to check key settings such as whether the root volume is sealed or not.

You can trace this through several thousand log entries, and after around 4.4 seconds and multiple network connections, softwareupdate finally informs SilentKnight that there are no updates available.

xprotect

Running the command
sudo xprotect check
in Sequoia is far simpler and quicker, as it checks for just one component’s updates through iCloud. The command connects to XProtectUpdateService in the XprotectFramework private framework in macOS, which in turn fires up CloudKit to connect to iCloud. That fetches a database record and returns the result to XProtectUpdateService, and so back to the xprotect tool as its result. Total time taken is 0.5 second.

As Apple’s intent in changing the management of XProtect and its data appears to be to facilitate more frequent and macOS-specific updates, iCloud is an ideal platform to host this on.

Pinniped with tusks

There is, though, one last thing: what is the walrus? As that might seem an odd question, read these two log entries encountered when browsing what happened with the xprotect check command:

12:08:00.919841 com.apple.cdp XPC Error while fetching walrus status: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process." UserInfo={NSDebugDescription=The connection to service named com.apple.cdp.daemon was invalidated: failed at lookup with error 3 - No such process.}
12:08:00.919845 com.apple.cloudkit CoreCDP reports that walrus is undetermined for the logged in account. Error: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=<private>}

The prospect of an undetermined walrus that can’t be fetched from inside my Mac might seem worrying

The macOS 15.2 update includes the second phase of AI support for Apple silicon Macs, introducing the Image Playground app, and integrated ChatGPT support in both Siri and Writing Tools. AI now extends support to several of the non-US variants of English, including English (UK), although non-English languages won’t gain support until next year.

Apple’s release notes are a real joy to read and contain more detailed information at last, including the following:

• Photos enhancements,
• Safari supports background images for its Start Page, tries to use HTTPS on all sites, and more,
• Sharing item locations in Find My,
• Sudoku for News+,
• Presenter preview for AirPlay,
• Pre-market quotes in Stocks.

Among the more significant bugs fixed is that Apple silicon virtualisation on M4 Macs can now open all VMs, including macOS guests before 13.4. For those running Ruby with YJIT enabled, this update should fix kernel panics with M4 chips. Further fixes are detailed in the developer release notes, and enterprise release notes are here.

Security release notes are available here, and list 42 entries including 4 in the kernel, none of which Apple reports may already have been exploited.

iBoot firmware on Apple silicon Macs is updated to version 11881.61.3, and T2 firmware to 2069.40.2.0.0 (iBridge: 22.16.12093.0.0,0). The macOS build number is 24C101, with kernel version 24.2.0.

Version changes in bundled apps include:

• Books, version 7.2
• Freeform, version 3.2
• iPhone Mirroring, version 1.2
• Music, version 1.5.2
• News, version 10.2
• Passwords, version 1.2
• Safari, version 18.2 (20620.1.16.11.8)
• Screen Sharing, version 5.2
• Stocks, version 7.1
• TV, version 1..5.2
• Tips, version 15.2
• VoiceMemos, version 3.1.

Inevitably, there are many build increments in components related to Apple Intelligence, and a great many across private frameworks. Other significant changes to /System/Library include:

• Screen Time, build increment
• Siri, version increment
• VoiceOver, build increment
• Kernel extensions including AGX… kexts, AOP Audio kexts, AppleEmbeddedAudio, AppleUSBAudio, and several virtualisation kexts
• One new kernel extension, AppleDisplayManager
• APFS to version 2317.61.2
• Most of the Core frameworks have build increments
• FileProvider framework, build increment
• Virtualisation framework, build increment
• PrivateCloudCompute framework, new version
• Spotlight frameworks, build increments
• New private frameworks include Anvil, AppSystemSettings (and its UI relative), AskToDaemon, many Generative… frameworks involved with AI, OSEligibility, TrustKit, WalletBlastDoorSupport
• Several qlgenerators have build increments.

After that lot, the next scheduled update to macOS Sequoia is in the New Year.

As eagerly anticipated, Apple has released the update to macOS 15.2 Sequoia, together with security updates to bring Sonoma to version 14.7.2, and Ventura to 13.7.2. There should also be Safari updates to accompany the latter two.

For Intel Macs, the Sequoia update is 2.72 GB in size, and for Apple silicon models it’s 3.45 GB.

Security release notes for Sequoia list 42 vulnerabilities fixed in the 15.2 update, including four in the kernel, although none are noted as being currently exploited. Release notes for Sonoma list 25, and those for Ventura list just 22.

iBoot is updated to version 11881.61.3 on Apple silicon Macs, and Intel Macs with T2 chips have their firmware updated to 2069.40.2.0.0, iBridge 22.16.12093.0.0,0. Sequoia 15.2 brings Safari version 18.2 (20620.1.16.11.8).

Later tonight I hope to post a summary of changes in 15.2, in a separate article as usual.

[Updated 1938 GMT 11 December 2024.]

Among those things that never change in the Finder is a prominent bug that has affected its column view for at least the last 11 years, back to OS X Mavericks if not before. During beta-testing macOS Sequoia last summer, I thought for a while that Apple had fixed it, but when I looked for the bug in the release version of macOS 15.0 it hadn’t even gone into hiding, and it’s still there today in 15.1.1.

I must have written about it here for the first time back in 2015, and for a while checking for it became an annual event, but over the last few years there seemed little point in whingeing about it any more. No one seemed bothered that the Finder couldn’t handle its column views properly, as Apple silicon Macs are so much more exciting. Every so often it comes back to bite me, and I’m reminded how annoying it is, so please bear with my catharsis.

Like many of the most persistent and annoying bugs, the Finder column width bug might seem tricky to reproduce, but when you normally work in column views it will return to haunt you.

It’s straightforward to demonstrate. Open a new window in the Finder, and ensure it’s set to Column View. Select your Documents folder in the sidebar, then select another folder containing more files and folders in the first column, within Documents. It helps if some of those have long names, so they’re truncated using an ellipsis … in the name.

Now click on your Applications folder in the sidebar to switch to that. Select an app, ideally one with a long name that has also been truncated with an ellipsis.

Then click on the Back button to switch back to your previous view of the folder within Documents. More often than not, you’ll now see the second column fill the remaining width of the window, and browsing any deeper into those folders is almost impossible, as the column width settings have gone haywire.

The simple way to recover is to select a different folder in the first column, which should restore orderly column widths.

While this might appear to be obscure, and unlikely to trouble anyone in normal use, there’s one situation that causes it to occur frequently, when you like to park your Finder windows in column view, with two columns shown in the view, as in the first screenshot above. Because of this I have changed my behaviour over the last few years, and now leave Finder windows with just the first column filled, a solution I worked out over four years ago. But any lapse in concentration allowing me to park a window in the wrong configuration makes it likely the bug will return and bite back.

Over those 11 years, governments have come and gone, my grandchildren have grown up and one is now at university, we survived Covid, lost QuickTime and 32-bit code, and now use Apple silicon Macs. But one thing has remained unchanged through all of that, the Finder column width bug.

Over the last couple of weeks, I have looked at several aspects of Spotlight in macOS Sequoia. This article draws those together in a summary that I hope will prove a useful reference.

Spotlight and apps like HoudahSpot that work with it aren’t the only way to search for files and their contents. There are third-party alternatives, some of which can use Spotlight for some searches, while most can also search independently. These range from the free EasyFind, through FindAnyFile, to high-end FoxTrot Professional Search. If you want to know more about those, please consult their documentation.

How Spotlight works

At its heart, Spotlight consists of several components:

• A file indexing system reliant on mdimporter modules supplied with macOS and third-party products, that enable mdworker processes to extract data from each file to be added to the index.
• A hidden folder of indexes in .Spotlight-V100 at the top level of each volume that it indexes. These are compiled using the data extracted by mdworker processes during indexing, and maintained by processes including mds and mds_stores.
• A search interface, including the Spotlight item in the menu bar, and the Finder’s Find command for its windows. Interfaces are also built into many apps.

There was a time when there was just one Spotlight, and searching in the Finder could reach almost any file on each indexed volume. Confusingly, different flavours of Spotlight have access to different sections of its indexes. One prime example is the search feature in Mail, which is the only way that you can search messages in that app, other than the Spotlight item in the menu bar. This is known as Core Spotlight, and prevents message contents from being found in the Finder, or in third-party apps like HoudahSpot. This operates independently of TCC privacy controls, and those can’t be used to give access to Core Spotlight indexes.

Recent versions of macOS can extract additional information from certain types of files such as images and PDFs. This may include text recognised within images using Live Text, and object recognition and classification, performed in the background by other services such as photoanalysisd. Those are slower and take significantly more processing, are normally run after traditional mdimporter extraction, and in some cases may take many days to complete. As some of that search content is only accessible to Core Spotlight, this is almost impossible to troubleshoot.

This is summarised, with pointers to common failures, in the diagram below.

Importing to the indexes

To confirm that a file is being indexed correctly, there are three useful command tools:

• mdimport -L lists known Spotlight mdimporter plugins.
• mdimport -t -d3 [filepath] reports the mdimporter used for a file, and data extracted from that file.
• mddiagnose -f [path] runs full Spotlight diagnostics.

My free Mints can also be used to investigate most Spotlight problems.

Exclusions from indexing

There have been three methods of excluding folders from indexing and search by naming, although only two of them still work reliably:

• appending the extension .noindex to the folder name (this previously worked using .no_index instead);
• making the folder invisible to the Finder by prefixing a dot ‘.’ to its name;
• putting an empty file named .metadata_never_index inside the folder; that no longer works in recent macOS.

System Settings offers Spotlight Privacy settings in two sections. Items listed under Search results won’t normally prevent their indexing, but will block them from appearing in search results. Spotlight’s indexing exclusion list is accessed from the Search Privacy… button, where listed items won’t be indexed at all.

Re-indexing

In general use, the only way to force Spotlight to update or correct its indexes is to force them to be rebuilt. The only good indication for rebuilding Spotlight indexes on a volume is when they are known to be damaged or corrupted, in which case rebuilding offers the best chance of restoring normal search function to that volume.

To force a volume to be re-indexed, open Spotlight (or Siri & Spotlight) in System Settings and click the Search Privacy… or Spotlight Privacy… button at the bottom. Click the + button at the foot, select the volume and add it to the list, then click Done. Pause thirty seconds or so, click the Search Privacy… button again, select that volume in the list, and click the – button to remove it from the list. You don’t normally need to close System Settings or restart between adding and removing the volume.

If you prefer, you can instead use the mdutil command in Terminal. The command
mdutil -E /
erases the indexes on the Data volume and forces them to be rebuilt, and you can use the same option on other volumes given the correct path. Provided that you use the -E option, there’s no need to turn off indexing, or to turn it back on again, nor is it necessary to delete that volume’s hidden .Spotlight-V100 folder.

As Spotlight indexes are maintained and stored on each volume for its contents, you’ll need to include each volume on which you want to be able to search files by their contents. Unless you have been able to identify which volume’s indexes merit rebuilding, you may have to rebuild indexes on every mounted volume, which can take many hours or days to complete.

The simplest way to check that re-indexing is taking place is to open Activity Monitor, and in its CPU view check that processes with names starting with md are taking plenty of CPU. These should include mds_stores, mdworker (often multiple copies) and mds itself. On Apple silicon, those processes run almost exclusively on E cores, and are usually obvious in Activity Monitor’s CPU History window.

Although the Spotlight Search item opened from the menu bar may show indexing progress, that doesn’t cover all indexing, and isn’t a reliable indication of whether indexing or re-indexing is complete.

Indexing takes excessive time

This isn’t uncommon after mounting an external volume, or following a macOS upgrade. On Apple silicon Macs, it can result in prolonged and apparently intensive activity on the E cores. On all Macs, it may prevent a volume from being unmounted for many hours. Although some claim that forcing re-indexing can address this, that could instead take even longer to complete.

If an external disk needs to be disconnected, try the force-eject action offered by the Finder, then restart the Mac to ensure any further indexing activity is terminated. It may prove simpler to shut the Mac down, disconnect the external disk, and start it up again.

Failure to find

If a Spotlight search is unable subsequently to find known contents of a file, then one of the following has occurred:

• The contents of that file weren’t correctly indexed, most commonly because that file is in a location excluded from indexing.
• Although indexes for that volume contain data correct for the file, Spotlight is withholding information about it from search results.

When a file is in a folder that should be within the scope of a regular global Spotlight search, not just app-specific Core Spotlight, but can’t be found, try relocating the file to a path such as ~/Documents that should be in scope and repeat the search. This can be done using the test files provided by Mints, for example, although Mints’ Spotlight search only encompasses the active Data volume. To test other volumes including those on external disks, use the Finder’s Find.

When a file is moved within the same volume, Spotlight normally doesn’t re-index it, but records its new path. One useful technique is to place the files in a folder that is known to be indexed, then move them to another location. Spotlight in Sequoia (at least) withholds the results of searches in Library folders and their contents, except for those in /Library/Application Support.

iCloud Drive and network shares

The whole contents of iCloud Drive should be fully accessible to local Spotlight provided that files are downloaded locally at the time of the search. All files that have been evicted from local storage, and have been made dataless as a result, become inaccessible to Spotlight until they have been downloaded again. If you want to ensure that any file in iCloud Drive remains searchable, set it to be kept downloaded or pinned using the contextual menu’s Keep Downloaded command.

Shared volumes and folders using SMB are unlikely to be accessible to local Spotlight search. Although some have claimed to be able to see items on such shares, most can’t, and there seems to be no reliable way of enabling this in Sequoia.

You probably don’t use Spotlight to search files likely to be in one of your Mac’s Library folders, but if you do you may have noticed that it hardly ever finds anything there. I’m grateful to Scott for pointing out that some folders inside those Library folders, like Preferences, can’t be searched at all. This article attempts to discover what’s going on.

How Spotlight finds

When files are created or changed, provided they’re in a location that it indexes, Spotlight’s mdworker processes index data about those files, including metadata about each file itself, such as its name, and about its contents, enabling you to search for terms found in the file’s data. If a Spotlight search is unable subsequently to find known contents of a file, then one of the following has occurred:

• The contents of that file weren’t correctly indexed, most commonly because that file is in a location excluded from indexing, as set in Search Privacy… in Spotlight settings.
• Although indexes for that volume contain data correct for the file, Spotlight is withholding information about it from search results, most commonly because that category of file (or folder) shouldn’t provide search results, according to Search results settings in Spotlight settings.

I’ll refer to these two causes as unindexed and withheld respectively.

Does Spotlight reindex files that have been moved?

Before trying to establish which folders Spotlight won’t return search results for, I needed to be able to distinguish between those two causes. One way to achieve that might be to ensure that test files were first indexed at a location that is reliably indexed, for which no search results are withheld, then move the test files to a different location. That relies on Spotlight retaining indexed data when files are moved, rather than reindexing them.

I therefore assembled a folder of test files, based on those created and used by Mints, with the addition of a property list containing the search term syzygy999. These were first placed at the top of the user’s Home folder, time allowed for Spotlight to add them to the volume’s indexes, and that was confirmed by performing Mints’ test search, which found them all. That folder was then moved to ~/Documents, with Mints given Full Disk Access to ensure search wouldn’t be blocked by TCC.

Inspection of the log for 30 seconds following the change of location demonstrated that no reindexing occurred, although Spotlight was informed of the changed paths for the files. Thus, any search failures are expected to result from results being withheld, rather than the files being unindexed.

Which folders don’t return expected search results?

I then moved the test folder from ~/Documents to other folders and repeated Mints’ test search for each. Results were:

• ~/Library and /Library – search only found the term in a plain text file, where it was attached as an extended attribute and not in the text data.
• ~/Library/Trial – only found in plain text file with the search term in xattr.
• ~/Library/Preferences – no searches returned successfully.
• ~/Library/Application Support – all test files were found successfully, including the property list.

Is this specific to the active boot volume group?

All those test were performed on the active Data volume. To test whether this extends to other (inactive) boot volume groups, I connected an external bootable SSD with Sonoma installed and repeated the tests. As Mints only searches the current Data volume, I used the Find feature in the Finder. Results were exactly the same for that Data volume’s single user.

Where is this behaviour controlled?

Within each volume’s Spotlight index folder is VolumeConfiguration.plist, whose name suggests it might contain Spotlight configuration for that volume. Comparison of that file from a regular APFS volume with that from the Data volume of a boot volume group failed to suggest any value that might be responsible for this behaviour, though.

That indicates it’s determined in another property list, or coded into Spotlight.

If you have purchased the Spotlight master tool HoudahSpot, which I strongly recommend, then this may seem familiar, as it’s mentioned in its Help file, suggesting that it’s not new to Sequoia.

Conclusions

• Spotlight in Sequoia (at least) withholds the results of searches in Library folders and their contents, except for those in /Library/Application Support.
• There’s no way apparent to change that behaviour.

Postscript on dealing with prolonged indexing

At the end of my testing, I tried to unmount the external SSD containing the bootable Sonoma installation, only to be told that it was still in use. This was the inevitable reindexing that has caused similar problems to many others. Rather than forcing ejection in the Finder, I left this to run, in the hope that it would complete reasonably swiftly on a Mac mini M4 Pro. I gave up after over three hours, forced the external Data volume to be unmounted, and disconnected the SSD.

Intensive reindexing activity continued to occupy all the E cores, as if the volume was still present. This was occurring in the /var directory rather than in any volume indexes, and was only terminated by restarting the Mac. At no time did Spotlight indicate that indexing was in progress, nor provide any indication of progress to completion. If this isn’t a bug in Sequoia, then it’s a serious flaw in Spotlight that needs to be addressed. I will see if I can repeat this, and then file a bug report if I can.

How do you get good advice? The fact that you’re reading this makes it likely that you’ve come here in the past, but where else do you go?

When I’m researching for articles here, my first visits are to Apple’s support pages for users and those for developers, but I’m only too well aware of their limitations. A month ago I wrote about the Tips app that Apple has thrust to the fore in Sequoia, and wondered whether it’s destined for greater things. Last week, I thought it might be informative to check how AI is doing, so turned to one of the most wanted features coming in Sequoia 15.2 next month, ChatGPT.

To assess how reliable ChatGPT might be as a source of troubleshooting guidance, I asked it half a dozen questions I have recently asked, and answered myself, in the pages I contribute to MacFormat’s Genius Tips, and its sister publication MacLife. If you want to read my answers in full, you’ll find them in MacFormat issue 409, although most have been the subject of articles here.

How to back up all the files in my iCloud Drive?

ChatGPT detailed how to copy the entire contents of iCloud Drive to local storage, explaining that “by saving a copy locally or to an external drive, you have created a manual backup of your iCloud Drive files.” It failed to point out that Time Machine and other backup utilities will back up files that haven’t been evicted from iCloud Drive, and some third-party apps can accomplish that automatically.

That answer is spectacularly wrong, and merely creates a local copy of files, most of which are probably already downloaded to that Mac and being backed up.

How to exclude files from iCloud Drive?

ChatGPT here misunderstood the question and instructed me how to stop apps from syncing their documents and data with iCloud, in the Apps syncing to iCloud Drive setting for iCloud Drive. It also came up with the crazy tip: “Additionally, you can move files you want to exclude from iCloud Drive to another location on your Mac that is not part of the iCloud Drive directory.” Thankfully, I know of a much better way that does answer that question.

How to make bootable backups of my Mac running Sonoma?

Although ChatGPT opened with promise, responding that “macOS’s built-in Time Machine backup feature does not create bootable backups on its own,” it quickly got into trouble, and at no time advised me not to attempt this. Neither did it direct me to support information that explains the details, such as this page for Carbon Copy Cloner, where it states: “we do not support nor recommend making bootable copies of the system as part of a backup strategy.”

ChatGPT then instructed me to prepare an external drive formatted as “Mac OS Extended (Journalled)” on which to create that bootable backup. At the end, it signed off reassuringly: “by following these steps, you will create a bootable backup of your Mac running macOS Sonoma, providing peace of mind in case of system failures or data loss.”

The advice given here is again spectacularly wrong.

How to reset the NVRAM in my M2 Mac?

ChatGPT’s response opened with waffle only relevant to Intel Macs, about how resetting the NVRAM “can help resolve issues with startup, audio volume, display resolution, time zone settings, and more.”

It next proceeded to describe how to start up an Apple silicon Mac in Recovery mode, then to open Terminal and enter the command nvram -c, that it confidently asserted “will clear the NVRAM.” Not only is that known to be ineffective and normally to return an error, but as Apple explains “steps to reset NVRAM don’t apply to Mac computers with Apple silicon, and aren’t needed on those computers.”

It seems strange that ChatGPT is so unaware of Apple’s own support notes.

How to stop kernel_task taking so much CPU?

This is a well-known cardinal sign of a Mac that’s getting too hot and needs to cool down. Nevertheless, ChatGPT’s first suggestion was to “check for Resource-Heavy Applications: Open Activity Monitor and close any applications or processes that might be using excessive resources.” As it didn’t make it clear that I shouldn’t try killing kernel_task itself, that’s dangerous advice.

Only then did it mention that I should ensure my Mac has “sufficient ventilation”, as “if your Mac overheats, kernel_task may run to throttle the CPU speed to prevent damage.”

ChatGPT then moved on to recommend that I “update macOS” “as updates can fix bugs that cause inefficiencies.” A little further down, it even recommended that I should “check for Flash Content”, forgetting that Flash died four years ago.

How can I get notifications delivered reliably on both my iPhone and Apple Watch?

With this last question, ChatGPT once again failed to understand its implications, and walked through a long series of checks through settings. Only towards the end did it bother to mention the obvious issue alluded to in the question, that they’re delivered to the device you’re using and not to both at the same time. Well, in theory, at least.

My conclusion therefore has to be:

Only ask ChatGPT if you already know the correct answer

otherwise you’re likely to be sent on a wild goose chase, misunderstood, or fed stuff and nonsense. Perhaps it’s best left to writing short stories for children who will believe every word.

Apple has just released an update to macOS Sequoia, bringing it to version 15.1.1, build 24B91 (all Macs other than M4) or 24B2091 (M4 Macs only). This brings two important security fixes, to JavaScriptCore and WebKit, both of which Apple believes may already have been exploited. The update should be less than 800 MB to download.

Safari is updated to version 18.1.1 (20619.2.8.11.12). There are also matching updates to Safari available for Sonoma and Ventura, addressing the same vulnerabilities.

Security release notes are here.

(Last updated at 1722 GMT 20 November 2024.)

macOS Sequoia has had its fair share of problems, particularly with networking, and by all accounts its bundled firewall still doesn’t play nice with third-party software firewalls. But most worrying are those whose Macs find Sequoia overwhelming, recent models that should take the upgrade in their stride, but apparently don’t.

Typically, from moments after logging in, these Macs remain incessantly busy with what we expect to be brief background tasks. Several hours later, Activity Monitor still shows long periods of frenetic activity on Apple silicon Efficiency (E) cores. These appear to keep building endless Spotlight indexes and rummaging through images with photoanalysisd. Surely something must be seriously amiss in Sequoia.

When you start up an Apple silicon Mac in Sequoia 15.1, it might well appear so. There’s a long procession working through background services such as Spotlight index maintainers (mdsync, mds, mds_stores, mdwrite and lots of mdworker_ processes), Time Machine (backupd), security (XProtectRemediator, lsd, syspolicyd), and others like CGPDFService, spotlightknowledged and photoanalysisd that might look vaguely familiar.

If this procession does come to an end before the user’s patience, CPU time for some of those is amazing. Here mdwrite ran for almost ten minutes, mds for nearly five, and that’s after a normal startup, long after the last update to 15.1. How can this be right? To understand why there’s probably nothing wrong, we should consider what Activity Monitor isn’t telling us, what those E cores are up to, and why this can be normal behaviour.

E cores and % CPU

In an Apple silicon Mac, its E cores are intended to run background threads as efficiently as possible, and that often means at low clock speeds (frequencies). In an M1 Mac, that could be as slow as 600 MHz, and even in an M4 at a mere 1,020 MHz. Those are less than a quarter of the maximum frequency of the P cores, and sip power at just a few milliwatts. Unfortunately, as I’ve explained in detail, % CPU and the CPU History window in Activity Monitor take no account of core frequency. What they portray as 100% could be anywhere between the minimum and maximum, making for a huge spread of core throughput.

Frequency of both E and P cores varies greatly as they’re running different threads, as controlled by macOS. In an M4 chip, P cores have 19 set frequency steps, and even E cores have seven. What might appear in the CPU History chart to be a steady 100% load on all four E cores is probably varying widely with core frequency, with much of it running slowly to eke out power.

There’s a little irony here, in that Apple silicon Macs working their E cores with background tasks may have greater visual impact than in an Intel Mac, where they will be spread more evenly across all the cores, and appear far less despite their real impact being greater.

What is being analysed and indexed?

Over the last couple of years, macOS has gained new abilities to analyse the content of images, including those embedded in PDF documents. It all started with the introduction of Live Text back in Monterey, and has blossomed since to include other types of analysis including categorising objects discovered within images.

Consider a PDF consisting of pages scanned from a book with diagrams and illustrations. macOS can now run Live Text on each page, and within each of its pictures, then add its text and graphics content to its Spotlight indexes. You may already have noticed that searching for words that commonly appear in certain types of image like screenshots returns many hits where that text is embedded in a menu or dialog within that screenshot. Performing text recognition and image analysis on those thousands of pages takes time, particularly when it’s mostly being run efficiently, in the background on E cores.

Other background features have also changed their behaviour. For example, XProtect Remediator scans have become less leisurely and prone to omission unless your Mac is left running but inactive for significant periods. It’s now common for scans to be run shortly after the first Time Machine backup is made, five or ten minutes after starting up, rather than waiting a few hours for an appropriate moment. These now take the opportunity to get their work done sooner, running in the background on the E cores, which is, after all, what they are designed to do.

Efficient workers

Apple’s M-series chips don’t come cheap. We pay for the P cores that run our apps fast and keep them responsive so we don’t have to wait as we so often did in the past. We also pay for the E cores that beaver away in the background to ensure that when we search for photos of Aunt Sue we don’t have to sort through duds of Uncle Dave. Like all the best workers, those E cores get on with their jobs unobtrusively, work anti-social hours without complaint, and don’t crave power. So please don’t kill them, as their efficiency keeps your Mac healthy and productive.

Irreverent Background Note

Health & Efficiency plays on the name of a magazine now known as H&E naturist that was popular among young adolescent males, as for many decades from the 1920s it was one of very few newsstand publications in the UK that featured photos of naked women and men. For curious schoolboys who were too short to reach its usual lofty position on the shelves, tall friends were a great asset. I also suspect that the title is itself a play on the term self-sufficiency, which has surprisingly early origins in sixteenth century English.

Between now and the end of the year, many will be taking on a new Mac, either a brand new M4 model or an older Mac sold or passed on. Before you even think about setting it up, you need to work out how you’re going to move your existing apps, Home folder and media libraries to it. Are you going to trust that to Migration Assistant in macOS? If so, should you do that when first personalising and configuring the Mac, or leave it until later? This article is intended to help you plan that.

What do you want to migrate?

The first important question is what you want to migrate from your old Mac to the new one. If you intend taking across much of what’s on the old one, including all your current user settings, then the best time to do that is when you’re first configuring the Mac, shortly after powering it up. Instead of going through all the steps to create a new user account, migrating at this stage will set that account up for you.

If you’re currently running an older version of macOS, or don’t want to transfer settings from your current user account, then you might do better to delay any migration until later, when you’ve already created yourself a new account and set it up as you want.

If you want to start from scratch, and only move the files and folders you want, then you may prefer to give Migration Assistant a miss, and perform the migration by hand. This is much harder, and even if you think you know what to do, you may well be surprised with the tasks that prove difficult, and those that don’t work at all. Modern macOS is exceedingly complicated and largely undocumented, so it’s easy to omit something important, and waste time trying to move it by hand.

When should you migrate?

Migration Assistant isn’t perfect, and the version of macOS pre-installed on a new Mac inevitably needs to be updated as soon as you can. As a result, in the past I’ve recommended that you delay performing migration until you’ve set up the primary admin account and brought the Mac fully up to date with macOS.

With new M4 Macs, I now recommend that, if you do want to migrate much or all from your old Mac, you do so during initial configuration, rather than later. The first batches of M4 Macs come with the regular edition of macOS Sequoia 15.1, and need to be updated to a newer build number, taking them from 24B83 to 24B2083, which is only for M4 models and VMs. Unlike some previous Macs, the version of 15.1 they ship with is still robust, and its Migration Assistant works well, so migrating early should be robust, if you want to move much of what’s on your old Mac.

If you remain undecided, then don’t forget that you can always migrate later.

What to migrate from

If you’re going to migrate much, you want your new Mac to be connected to the source it’s going to use by the quickest means possible. In practice, that means by Thunderbolt 3/4 if you can, rather than over a regular network. Either connect the two Macs back-to-back with a good Thunderbolt 4 cable, or migrate from a backup on a Thunderbolt 3 SSD, if you can.

Migration from a backup should work correctly whether that backup was created by Time Machine, Carbon Copy Cloner, SuperDuper, or any other good utility. All you need to do is ensure that it was made recently.

iCloud

Just as when migrating iOS and iPadOS devices, sharing using iCloud often proves a major advantage, indeed it may be the only way to fully synchronise the Data Protection keychain that’s shared when you share Keychain in iCloud. Although that’s backed up by Time Machine, restoring or copying it from a backup may not work.

If you don’t normally share your Keychain in iCloud, or other databases such as Contacts and Calendar, consider turning those on and letting them sync fully before migration, as that could save you trouble. Once migration is complete and your new Mac has synced fully, you can always disable their sharing again. If you’re selling or passing your old Mac on, you’ll be disconnecting it from your iCloud account and using Erase All Content and Settings (EACAS) anyway.

Anticipate problems

Migration Assistant, whether used during initial configuration or later, works best when:

• both Macs are running the same version of macOS (and Migration Assistant);
• it’s migrating the primary admin user account from your old Mac to the primary admin account of your new Mac;
• there are no disk errors, damaged folders or files in either source or destination storage;
• the old user account is entire and doesn’t use any ‘tricks’ in its Home folder.

You do get a choice as to what you migrate, but if you’re going to have to work through that in detail, picking some items and not others, you might find a painstaking manual migration better. If the versions of macOS on the two Macs (or backup) are far apart, then you may find yourself having to work through the new Mac correcting any misunderstandings that arise between the two versions.

If you migrate later, you’ll be given the option of merging from the old account into the current one on your new Mac. If you include settings in that migration, then your new settings will be overwritten by the old ones, and may need further attention once that migration has completed.

Post-migration checks

Once migration has finished, check through all your key settings to ensure they’re just as you want for your new Mac. As far as security is concerned, a quick check with SilentKnight covers key items like FileVault and security data updates. One important setting that I noticed hadn’t been enabled on my new M4 Mac mini was Find My, which takes a bit of searching in System Settings to get right. You should also set aside some time and patience to attend to all the details in Privacy & Security, to ensure nothing is amiss there.

The current version of Migration Assistant does try to migrate the contents of well-known hidden folders including /usr/local, and should copy across any command tools and other files you have installed there. It may not cope so well with more extensive customisation in those hidden folders, though, and you should check those locations carefully following migration.

Migration mess

Very occasionally, Migration Assistant is like a bull in a china shop, and creates havoc, or fails to complete. Allow time so that you can work out how best to resolve that. If the worst comes to the worst, don’t be afraid to start from scratch with a clean install of macOS and an empty Data volume.

Pulling tricks

Old methods of instant migration using volume clones only work with old versions of macOS, prior to Big Sur or even Catalina. While you might get away with using them now, they often cause fundamental problems. Bite the bullet and take the easy way by migrating properly, so your new Mac gets off to the right start.

I wish you fair winds and success!

See also

Migrating to a new Mac, and claiming Time Machine backups
Apple Support

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

Relative to the last version released for all supported versions of macOS (5279), this version renames several existing rules, as MACOS.DUBROBBER.A to MACOS.DUBROBBER.E, and adds new rules for MACOS.DUBROBBER.F, MACOS.DUBROBBER.G and MACOS.DUBROBBER.H. It also adds a new rule for MACOS.TAILGATOR.

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-5282.

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

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

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

Over the last few years, Migration Manager in macOS has improved considerably, and when used wisely it can save you a great deal of time getting you new Mac up and running. This article explains how you can use it in Sequoia, and how that works with Time Machine and the backups from your old Mac.

There are two occasions when you can transfer your apps, settings and documents using the process of migration: during the initial personalisation and configuration of macOS, or using Migration Assistant at any time later. I always used to postpone that until macOS was set up and brought up to date, but lately I’ve preferred to get this over with first.

This time I faced a more difficult problem: I was replacing my old Mac Studio M1 Max with my new Mac mini M4 Pro, both of which are intended to use my single Studio display. While I could have run one of them headless (without a display connected), Migration Assistant expects both Macs to be used interactively, which would have required some cunning juggling. Instead of opting to connect them back-to-back, I therefore chose to migrate during initial setup from the Studio’s last Time Machine backup. As the backup storage for my Studio was a Thunderbolt 3 external SSD, this proved surprisingly quick.

Migration during setup

Before unboxing your new or previously owned Mac, prepare the source for migration, and any cable required to connect that Mac with the source. Migrating from a backup is here one of the simplest and fastest options, as all you need do is move your old Mac’s external backup storage over to the new Mac.

In the past, migration used the fastest connection available between two Macs that were connected back-to-back, but Apple’s current support note now states that Wi-Fi will be used. In my case, given that both Macs have 10 GbE, that could have been a disappointment if they were already connected by Ethernet cable.

Another important step is ensuring that your new Mac has a keyboard and mouse/trackpad. As I was moving those from my Studio, I connected both to the new Mac mini by their charging leads to ensure they’d work and pair correctly.

Unbox your Mac, connect it up to your migration source, its new keyboard and mouse/trackpad, then start it up. When the setup sequence reaches the Migration Assistant screen, select the migration source.

If you’re migrating directly from your old Mac, at this point you’ll need to open Migration Assistant on that Mac and set it to migrate to another Mac. Follow the prompts to continue the process.

Migration after setup

Initiate this by running Migration Assistant in /Applications/Utilities, and follow its prompts to select and connect to the source as above.

Time Machine backups

Assuming that your old Mac made Time Machine backups, and you want your new Mac to continue doing so, now’s the time to connect that backup storage, if it wasn’t already used as the migration source. When you do, you’ll be offered two options, to claim the existing backups for the new Mac, or to leave them for the old one.

You should see this dialog if:

• you have migrated settings from an old Mac to this one,
• you have migrated settings from a Time Machine backup of another Mac to this one,
• you cloned the boot volume group used to start up your Mac,
• your Mac’s logic board has been replaced.

If you claim the existing backups for your new Mac, then they’ll be used as part of its backup history, but you won’t be able to use them with the old Mac. You may prefer to leave those old backups as they are, and gradually delete them to free up space. Provided that you create the new backup volume for your Mac in the same container, old and new backups will share the same free space on your backup storage.

This apparently replaces the old tmutil inheritbackup command, which no longer appears to work with backups to APFS.

Postscript

I am very grateful to Csaba Fitzl for two useful pieces of information:

• In macOS Sequoia 15.1 at least, tmutil inheritbackup does work again, when entered with the path to the backup volume, e.g. /Volumes/[TMDISK].
• Claiming old backups is only offered when migration has taken place. If you set up your new Mac without migrating, it doesn’t appear to be offered, although you should then be able to use tmutil inheritbackup instead.

As Nicolai points out in the comments below, Apple’s support note is incorrect about migration only using Wi-Fi connections to another Mac. This should work as it always has, and select the fastest connection between them, which could include back-to-back Thunderbolt.

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

periodic has been removed

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

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

Sequoia VMs: AI

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

Sequoia VMs: macOS builds

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

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

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

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

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

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

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

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

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

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

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

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

qlmanage

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

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

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

QuickLook app extensions

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

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

Mints and QuickLook

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

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

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

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

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

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

Checking UTIs

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

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

How to identify QuickLook extensions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Significant changes seen in bundled apps include:

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

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

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

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

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

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

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

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

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

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

I will post details of changes found later tonight.

[Updated 1820 GMT 28 October 2024.]

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

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

Summary

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

Key points

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

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

I don’t think I could better that.

List

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

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

Table

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

On device and on target

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

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

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

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

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

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

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

All supported Macs

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

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

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

Apple silicon Macs

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

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

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

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

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

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

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

Future Sequoia updates

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

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

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

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

M4 Macs

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

Summary

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

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

Internal SSD partitions

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

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

The boot volume group is composed of:

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

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

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

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

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

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

Inside the boot volume group

macOS now consists of three components:

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

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

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

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

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

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

Firmlinks

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

Directory layout

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

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

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

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

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

Band size

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

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

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

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

Compaction

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

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

Space efficiency in use

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

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

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

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

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

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

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

Conclusions

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

Previous articles

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

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

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

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

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

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

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

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

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

The most distinguishing feature of Doctor Who’s TARDIS is that it’s much smaller on the outside, only capable of accommodating a couple of people at a squeeze, but huge on the inside. Allow me to introduce you to a sparse bundle that’s similar, in that its bundle size is only 14 MB, but the size of its internal band files comes to a total of over 90 GB. Here’s how to make yourself one.

Method

To do this, you need an Intel or Apple silicon Mac running Sequoia 15.0 or 15.0.1, and an external SSD. A hard disk might do, but I haven’t tried it.

Connect and format the external SSD in APFS, using Disk Utility. Then create an empty sparse file with the following specifications:

• Size: 10 GB or more
• Format: APFS
• Encryption: none
• Partitions: Single partition – GUID Partition Map
• Image Format: sparse bundle disk image.

Save that to the external SSD at its top (root) level. As Disk Utility leaves your new sparse bundle mounted, unmount it, wait a few seconds, then double-click it to mount it again. Copy one or more large files to the mounted sparse bundle. With a bundle size of 10 GB, something around 5-6 GB should be ideal, but the sky’s the limit if you created a large sparse bundle to begin with.

Once that’s complete, unmount the sparse bundle, then select it on your external SSD and press Command-I to see the Get Info dialog.

Although the size will vary slightly, in my case, with a nearly full 125 GB sparse bundle, the Finder reports its size as 13.8 MB, or 14.8 MB on disk.

So where did all that file vanish to? Has APFS somehow made it into a sparse file? Sadly not: view the contents of the sparse bundle, select its band folder containing all the band files with your data, and its size will be much bigger than that of the bundle. In my case, that’s 92.7 GB in more than 10,000 band files.

There’s your TARDIS: a 13.8 MB sparse bundle containing over 90 GB of band files.

Breaking the illusion

Once you’ve created your TARDIS sparse bundle, you can see its magic still works when you connect that external SSD to another Mac. But there’s one thing that will break the magic spell: create a folder in the same volume, and move the sparse bundle inside that. If you then mount it and add a file, you’ll see it suddenly expand to its full bundle size. Similarly, if you repeat the whole trick, but this time save the sparse bundle inside a folder, then it won’t work. This is why you can only do this on an external SSD, as you can’t write anything to the top level of your boot disk.

I don’t know whether this works with other bundles, such as VMs for Apple silicon Mac virtualisation, but it might be interesting to try it.

Act now, don’t wait

While this remarkable bug is present in macOS Sequoia 15.0 and 15.0.1, I’m afraid its days are numbered. If you want to experience the TARDIS sparse bundle, you’ve only got another week or two, as it appears to be fixed in the current beta of 15.1. For once, I’ll be a little sad to see a bug fixed, although when I discovered it, it couldn’t have been more infuriating.

Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 147. The previous version was 145.

Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.

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 has not 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 XProtectPayloads_10_15-147.

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

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

Over the last few years, the performance of disk images has been keenly debated. In some cases, writing to a disk image proceeds at a snail’s pace, but this has appeared unpredictable. Over two years ago, I reported sometimes dismal write performance to disk images, summarised in the table below.

This article presents new results from tests performed using macOS 15.0.1 Sequoia, which should give a clearer picture of what performance to expect now.

Methods

Previous work highlighted discrepancies depending on how tests were performed, whether on freshly made disk images, or on those that had already been mounted and written to. The following protocol was used throughout these new tests:

1. A 100 GB APFS disk image was created using Disk Utility, which automatically mounts the disk image on completion.
2. A single folder was created on the mounted disk image, then it was unmounted.
3. After a few seconds, the disk image was mounted again by double-clicking it in the Finder, and was left mounted for at least 10 seconds before performing any tests. That should ensure read-write disk images are converted into sparse file format, and allows time for Trimming.
4. My utility Stibium then wrote 160 test files ranging in size from 2 MB to 2 GB in randomised order, a total of just over 53 GB, to the test folder.
5. Stibium then read those files back, in the same randomised order.
6. The disk image was then unmounted, its size checked, and it was trashed.

All tests were performed on a Mac Studio M1 Max, using its 2 TB internal SSD, and an external Samsung 980 Pro 2 TB SSD in an OWC Express 1M2 enclosure running in USB4 mode.

Results

These are summarised in the table below.

Read speeds for sparse bundles and read-write disk images were high, whether the container was encrypted or not. On the internal SSD, encryption resulted in read speeds about 1 GB/s lower than those for unencrypted tests, but differences for the external SSD were small and not consistent.

Write speeds were only high for sparse bundles, where they showed similar effects with encryption. Read-write disk images showed write speeds consistently about 1 GB/s, whether on the internal or external SSD, and regardless of encryption.

When unencrypted, read and write speeds for sparse (disk) images were also slower. Although faster than read-write disk images when writing to the internal SSD, read speed was around 2.2 GB/s for both. Results for encrypted sparse images were by far the worst of all the tests performed, and ranged between 0.08 to 0.5 GB/s.

Surprisingly good results were obtained from a new-style virtual machine with FileVault enabled in its disk image. Although previous tests had found read and write speeds of 4.4 and 0.7 GB/s respectively, the Sequoia VM achieved 5.9 and 4.5 GB/s.

Which disk image?

On grounds of performance only, the fastest and most consistent type of disk image is a sparse bundle (UDSB). Although on fast internal SSDs there is a reduction in read and write speeds of about 1 GB/s when encrypted using 256-bit AES, no such reduction should be seen on fast external SSDs.

On read speed alone, a read-write disk image is slightly faster than a sparse bundle, but its write speed is limited to 1 GB/s. For disk images that are more frequently read from than written to, read-write disk images should be almost as performant as sparse bundles.

However, sparse (disk) images delivered weakest performance, being particularly slow when encrypted. Compared with previous results from 2022, unencrypted write performance has improved, from 0.9 to 2.0 GB/s, but their use still can’t be recommended.

Performance range

It’s hard to explain how three different types of disk image can differ so widely in their performance. Using the same container encryption, write speeds ranged from 0.08 to 3.2 GB/s, for a sparse image and sparse bundle, on an external SSD with a native write speed of 3.2 GB/s. It’s almost as if sparse images are being deprecated by neglect.

Currently, excellent performance is also delivered by FileVault images used by Apple’s lightweight virtualisation on Apple silicon. The contrast is great between its 4.5 GB/s write speed and that of an encrypted sparse image at 0.1 GB/s, a factor of 45 when running on identical hardware.

Recommendations

• For general use, sparse bundles (UDSB) are to be preferred for their consistently good read and write performance, whether encrypted or unencrypted.
• When good write speed is less important, read-write disk images (UDRW) can be used, although their write performance is comparable to that of USB 3.2 Gen 2 at 10 Gb/s and no faster.
• Sparse (disk) images (UDSP) are to be avoided, particularly when encrypted, as they’re likely to give disappointing performance.
• Encrypting UDSB or UDRW disk images adds little if any performance overhead, and should be used whenever needed.

Previous articles

Introduction
Tools
How read-write disk images have gone sparse

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

Relative to the last version released for all supported versions of macOS (5277), this version adds three new definitions for MACOS.ADLOAD.I, MACOS.SOMA.G and MACOS.SOMA.H.

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-5278.

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

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

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