The Achilles heel of T2 Macs is booting from external storage. Although it’s simple to create a bootable external disk for a T2 Mac, to boot from it you have to allow the Mac to boot from any external disk, removing much of its boot security. Apple silicon Macs were designed to boot almost as securely from external disks as they do from the internal SSD, and that makes setting up a bootable external disk more complicated. This article explains how you can do that for macOS 26 Tahoe.

In this respect, Apple silicon Macs have two central principles:

• They always start the boot process from their internal SSD. If that’s not functioning correctly, then they can’t boot at all.
• They will only transfer the boot process to an external system when the user has access to a private key making them an Owner of that system, through the Mac’s LocalPolicy system. That’s the part that can cause problems.

Planning

There are alternatives to booting from external storage. If there’s sufficient space, you can install multiple versions of macOS on the internal SSD, or you can run macOS as a guest operating system in a virtual machine (VM). VMs are limited in some important respects, though, as they can’t run most apps from the App Store or use AI, although they can now access iCloud and iCloud Drive.

Like any other Mac, Apple silicon models can only boot from versions of macOS they’re compatible with. You can check which your Mac can run using Mactracker. A VM is the only solution for running older and incompatible versions of macOS, and it gets messy installing versions that are compatible but older than the currently installed major version of macOS. This is because its installer may be blocked by the more recent macOS, for which you’ll need to create a bootable installer disk and run the installation from that. Apple describes how to do that in this support article. For the remainder of this article, I assume that you’re installing a second or subsequent copy of the current version of macOS to an external disk.

Connect and prepare the external disk

First catch your disk, and connect it to one of the non-DFU ports on your Mac. For example, on my Mac mini M4, that’s either the left or right Thunderbolt port, as the middle one is its DFU port. On all other Apple silicon Mac minis, that’s either the centre or right port as you look from the rear, as their DFU port is the one on the left. If you try to install macOS to a drive connected to an Apple silicon Mac’s DFU port, then it’s doomed to fail, and that’s the most common cause of failure. More information on the DFU port is here.

Reformat that disk as you want to use it, with at least one APFS container containing a single APFS volume in regular APFS format, not encrypted.

Download and run the installer

Next catch your installer. Oddly, Apple seems to have stopped providing the current release of macOS through the App Store, so the simplest way to download it in the GUI is from the links provided by Mr. Macintosh, and there are many alternatives. You want a regular installer, not an IPSW image file that you might use to create virtual machines.

Run the installer app from your main Applications folder.

When it asks you whether you want to install macOS on your current system, click on Show All Disks…

Select your external disk from the list and click Continue. If your disk isn’t recognised or listed there, reformat it and start again.

Ownership

This is the important part of the installation; if it fails, the external disk won’t be bootable.

For the macOS system on your external disk to be bootable, it needs a LocalPolicy created for it on your Mac’s internal SSD. To ensure that only fully authorised users can configure and change LocalPolicy, those Image4 files are signed, and an Owner Identity Certificate (OIC) is attached to them. Creating and maintaining LocalPolicies requires a user to have access to the private Owner Identity Key (OIK) in the Secure Enclave, making that user an Owner.

Any user with access to the Volume Encryption Key for the internal storage also has access to the OIK, and has Ownership. By default, that includes all users added after FileVault encryption is enabled on a Data volume, for example. To be able to boot from that second OS, it requires a LocalPolicy with an OIC attached, and Ownership has to be handed off to an Install User created when that OS is installed.

Handing off Ownership to the Install User is more of a problem, as users are only created when the installation is complete. To accommodate that, macOS offers to copy a user from the current boot system as the Install User, and the primary admin user, on the second OS. Provided that you agree to that, the Install User created is actually a Key Encryption Key (KEK) for your password and hardware keys, which is then used to encrypt the OIK as it’s handed over to the new copy of macOS on the external disk. Thus, the installer requests that user’s password to gain access to the OIK for the new macOS in the Secure Enclave.

Following these steps should ensure that works correctly.

When prompted to select the user to be owner of the new boot volume group, pick the current admin user, and tick to copy their account settings.

You’ll then be prompted to enter that user’s password to authenticate as the owner.

Completing installation

Installation follows, and is (as ever) highly non-linear, and may even appear to stall. Persevere, and it will then close apps and restart to complete.

When you’re eventually prompted to Create a Computer Account, it’s simplest to create a local admin account for the owner. The new copy of macOS will then take you through personalising your new system, and, if you’ve added support for your Apple Account, it will do the 2FA dance for iCloud and Apple Account, and so on.

Once configured, you can share that external disk between Macs, but each time you boot from it on a different Mac, you can expect to repeat the 2FA dance for iCloud and Apple Account.

Updates

Once installed, you’ll almost certainly want to keep that external system up to date. To do that, start up from that disk, and use Software Update as normal. Although you could download that latest macOS installer and run that, that’s a much larger download and there’s always the risk it might run a clean install, forcing you to restore from your latest backup. Apple no longer provides downloadable updaters for macOS.

When you update macOS on that Mac, the firmware in it will be updated by the most recent version of macOS you have installed or updated it to, whether that’s on the internal or external disk. To update firmware, you have to install the appropriate macOS update on that Mac. If you update your external disk using another Mac, then that won’t update the firmware in your Mac. That can only be done by performing that update on that Mac.

Key steps

• Consider alternatives, including an additional system on the internal SSD, or using a VM instead.
• Connect the external storage to a non-DFU port and format it in APFS, not encrypted.
• Download and run the appropriate full macOS installer. macOS Tahoe isn’t currently available from the App Store, though.
• Select the external disk as the installation target.
• Select the current admin user to be Owner of the new system, copy their account settings, and authenticate with that user’s password.
• Create a local admin account for that user, if possible.
• Complete 2FA to connect to the Apple Account, as necessary.
• Update the external system when booted from it, using Software Update.

Earlier this week, when I considered how best to save websites using Safari, I pointed out that the PDFs it saves aren’t intended to be in archival format, using one of the PDF/A standards. As some of you pointed out, Preview has an option to export PDFs in “PDF/A” format. This article examines whether those are suitable for archiving.

PDF/A

PDF is a generic document type and includes a multiplicity of different standards. Standard PDF generated by the Quartz 2D engine should comply with PDF version 1.4, from 2001, although the first open ISO standard of 2008 was based on version 1.7, and the current ISO standard is version 2.0. There are also five specialised subsets of PDF, among them PDF/A intended for archival purposes, each with their own families of ISO standards.

PDF/A was originally based on PDF version 1.4, but more recently has adopted 1.7. Its standards impose additional restrictions on core features, such as requiring all fonts to be embedded, and forbidding the use of encryption and LZW compression. Its standards are based on three levels of conformance: basic (B), accessible (A), and full Unicode text (U). The two standards and levels in most common use are PDF/A-2A (accessible) and PDF/A-2B (basic). A more detailed account is given in Wikipedia’s article.

Although Preview claims to export PDF documents in PDF/A format, I’ve been unable to discover which standard or level those are intended to comply with. However, each of the test documents is reported by Adobe Acrobat CC (Pro) as claiming compliance with PDF/A-2B in ISO 19005-2.

Conformance

Three test PDF documents were used, two saved from Safari 26.1 (macOS 26.1) as detailed previously, and the Help book for LogUI, written by Nisus Writer Pro. All three were opened in Preview 11.0 (1113.2.5) and Exported As PDF/A, with just the Create PDF/A option ticked in the File Save dialog.

All three exported PDFs were then opened in Adobe Acrobat ‘Pro’ version 2025.001.20841. That reported that each claimed “compliance with the PDF/A standard”, so opened them read-only to ensure they couldn’t be modified. When each was verified against PDF/A-2B, that failed.

Details of the compliance failures were then obtained using Acrobat’s Preflight feature. In each there were multiple errors, such as those shown below.

To assess what changes were required to make the LogUI help book compliant with the standard, Acrobat then performed the conversion. Corrections it made are shown below.

Although those were quick and simple, without them the file exported from Preview wasn’t considered by Acrobat to comply with the standard.

When do you need to use PDF/A?

Although I’m confident that PDF documents created using the engine in Quartz 2D in macOS Tahoe will remain fully accessible for at least the next 20 years or more, looking 50 or 100 years ahead the use of a major open standard intended and widely used for archives becomes more important. Whether the imperfect PDF/A exported by Preview would make any difference to that is unclear.

If you intend any PDF documents created on Macs to be true archives that should stand the test of long times, then you should convert them into PDF/A-2B or another appropriate standard before committing them to archival storage. Otherwise, it’s moot whether Preview’s conversion is a good investment of your time.

Summary

• According to Adobe Acrobat, the ‘PDF/A’ format exported by Preview doesn’t comply with its claimed standard of PDF/A-2B. Thus the answer to the question posed by the title is no, not quite.
• If a PDF is intended to be accessible for decades into the future, it should be converted to a recognised PDF/A standard such as PDF/A-2B using Adobe Acrobat or an equivalent.
• Other PDFs may as well be left in their original format, which should ensure their accessibility for at least the next 20 years or more.

Support in macOS for file systems has continued to change over the last couple of years. This article summarises support available for local file systems, in attached rather than network or cloud storage, in macOS 26.1 Tahoe.

APFS

This is the default file system for Macs and Apple’s devices, although macOS has standardised on its case-insensitive variant for general use, while iOS and other OSes use case-sensitive. The one common exception is with Time Machine backup storage, which requires case-sensitivity. The only situation in which HFS+ is still expected is for bootable macOS installers.

The most significant feature of HFS+ that is missing in APFS is directory hard links, a key feature of Time Machine backups made to HFS+ storage.

Multiple APFS volumes can share the same APFS partition (container), in contrast to other file systems supported by macOS, in which each partition is also a volume.

As universal as APFS is on modern Macs, it’s very rarely available on other computer systems, and the only support for other platforms is from Paragon for Windows or for Linux.

HFS+

The Macintosh Extended file system HFS+ is the predecessor to APFS and is still fully supported in macOS. It comes from an era of hard disks rather than SSDs and may still be preferred for use on hard disks. Early versions were prone to cumulative errors, particularly when crashes or kernel panics occurred. Those risks were mitigated with the introduction of journalling, and HFS+ should only be used with journalling enabled. Currently supported versions of macOS no longer support its HFS predecessor, though, as that was dropped in 2019.

The only remaining situation in which HFS+ is still required is for bootable macOS installers, as detailed here.

HFS+ lacks many of the modern features of APFS, including snapshots, sparse files, clone files, and firmlinks used to join System and Data volumes. Because support for encryption was implemented late, in Core Storage logical volume management, recent macOS doesn’t support encrypted HFS+. However, like APFS, HFS+ is capable of supporting Trim on SSDs. Each HFS+ volume is a partition, thus has fixed size, in contrast to APFS partitions (containers) which can contain multiple volumes.

ExFAT, FAT32

These are two of a family of file systems introduced for MS-DOS and Windows. Although the older FAT formats are now antiquated, ExFAT remains the most commonly encountered format for USB flash drives (thumb drives, memory sticks) and SD cards, where it’s the default format for SDXC and SDUC cards larger than 32 GB. Unlike FAT32, ExFAT supports massive volumes and file sizes, and was optimised for use in flash memory. However, its implementation in macOS doesn’t support Trim.

These formats have relatively basic features, and lack encryption. Used from a Mac, they don’t have support for document versions, and may encounter indexing problems with Spotlight. They do, though, support extended attributes by using AppleDouble file format, in which those are saved in shadow files with names starting with ._ (dot – underscore). While those shadow files preserve extended attributes for use with macOS, they can confuse Windows users, for whom they can be deleted, for example using Ross Tulloch’s BlueHarvest.

In recent versions of macOS, these file systems are implemented in user-space using FSKit.

NTFS

Although you won’t find any mention of it in Disk Utility, macOS includes read-only support for NTFS, enabling the one-way transfer of files from Windows. There are third-party products to extend that with write support, including an implementation from Paragon. NTFS is significant for its support of extended attributes as Alternate Data Streams (ADS).

Available formats

Disk Utility version 22.7 in macOS 26.1 Tahoe can format the following file systems using a GUID Partition Map:

• APFS, unencrypted case-insensitive
• APFS, encrypted case-insensitive
• APFS, unencrypted case-sensitive
• APFS, encrypted case-sensitive
• HFS+ journalled case-insensitive (JHFS+)
• HFS+ journalled case-sensitive
• ExFAT
• MS-DOS (FAT32).

The command tool diskutil additionally offers FAT, FAT12, FAT16, and HFS+ without journalling.

ZFS

The only other major file system that can be supported by Macs is ZFS, available as OpenZFS on OS X. That isn’t a trivial undertaking, and is dependent on a kernel extension.

Linux file systems

There doesn’t appear to be native support for Btrfs, which is best accessed through Linux virtualisation when needed. While you can use a VM for ext4 and its predecessors, Paragon also offers support for them that is claimed to be compatible with macOS Tahoe.

MacFUSE

Traditionally, native file systems are implemented in kernel-space, requiring a kernel extension for macOS. This remains the case for those used by the operating system and for performance-critical tasks. In other cases, it’s possible to implement a file system in user-space without the need for a kernel extension. This has been the goal of the FUSE project, and with the introduction of FSKit support for user-space file systems in macOS, the MacFUSE implementation now runs without any kext. It’s hoped that will open up access to more file systems in the future.

I’m very grateful to Robert for pointing out Paragon’s support for Linux Ext file systems.

Websites come and go, and although the Internet Archive’s Wayback Machine provides a unique service by preserving so many, saving your own copies of pages remains important to many of us. This article looks at how you can do that using Safari 26, the current release for supported versions of macOS. If you want to explore the pages saved in the Wayback Machine, then its Safari extension is available free in the App Store.

Safari now offers the following five options for saving a page:

• File/Save As…/Page Source to save it as an HTML source file (169 KB).
• File/Save As…/Web Archive to save it as a Webarchive file (2.7 MB).
• File/Save As…/PNG to save it as a PNG image (43.5 MB).
• File/Export As PDF… to save it as a PDF file, in display format (31.6 MB).
• File/Print…/Save as PDF to save it as a PDF file, in print format (28.1 MB).

Sizes given are those for a test page with plenty of images from here.

Page source

This is the smallest and least complete version of the five, as it contains just the HTML source of the page, omitting all linked and similar generated content. For relatively plain pages containing text exclusively, this can be useful. The saved file can be opened in Safari or another browser, and so long as none of the linked content is missing or changed, you should see the original content reconstituted, but in a flattened layout without columns or styling. This is unlikely to be suitable as a lasting record, although it’s by far the most compact at 169 KB for the test page.

Web Archive

This saves to a single opaque webarchive file containing the entire contents of the page, including embedded images and other content, but not linked downloadable files. Although this format is peculiar to Safari, it has had limited support by some other apps, but I can’t find any other current software that can give access to its contents.

A webarchive file is a (binary) property list written as a serialisation of the web page content in Safari, in a series of WebResource objects. For example, a JPEG image would consist of:

• WebResourceData in Base-64 containing the image data;
• WebResourceMIMEType of image/jpeg;
• WebResourceResponse in Base-64 data;
• WebResourceURL containing the URL to the file.

Although in theory it should be possible to recover some of its contents separately, in practice that isn’t available at present. In the past access has been supported by the macOS API, but all those calls to work with Webarchive files are now marked as being deprecated by Apple. Current API support is limited to writing but not reading them from WKWebView from macOS 11 onwards, and there’s no sign of that being extended.

Webarchive format has changed over time, and compatibility with different versions of Safari is unpredictable. When testing in virtual machines, Safari 18.6 proved incapable of opening any webarchive test file, including its own, while Safari 26.0 and 26.1 loaded webarchives written by Safari 18.6, 26.0 and 26.1. There has also been a long history of problems reported with webarchive files. Recent versions of macOS can display QuickLook thumbnails and previews of webarchives, although thumbnails aren’t particularly faithful to their contents.

Although webarchives should contain embedded images shown in the original page, those appear to be saved at the resolution they’re displayed in. This helps limit the size of files; in the case of the test page used here, that required 2.7 MB, around 10% of the size of a PDF, making them the most efficient option apart from plain HTML.

When they work, Safari Web Archives can provide excellent snapshots of web pages, but longer-term compatibility concerns make them unsuitable for archival use.

PNG

Saving the page to a PNG graphics file is a relatively new option in Safari. For the example page, that generates a 2,622 x 32,364 pixel image of 43.5 MB size, making it the largest of all.

The PNG image is a faithful replica of the page as viewed, although it can be affected by lazy loading (see below). Disappointingly, its text contents don’t appear to be accessible to Live Text, limiting its usefulness.

PDF

Safari provides two routes for turning a webpage into a PDF document: directly using the Export As PDF… menu command, and indirectly via the Print… command then saving as PDF from the Print dialog. The results are different.

Exporting as PDF creates a document in which the entire web page is on a single PDF page, although it can spill over to one or two additional pages. The advantage of this is that the PDF is one continuous page without any breaks, and is a faithful representation of what you see in your browser, complete with its original layout and frames. The disadvantage is that this won’t print at all well, imposing page breaks in the most awkward of places. Very long pages can also prove ungainly, and difficult to manipulate in PDF utilities. The example page was 31.6 MB in size.

Printing to PDF breaks up the web page into printable pages, and splits up frames. What you end up with isn’t what you see online, but could at a push be reassembled into something close to the original. That isn’t too bad when the placement of frames isn’t important to their reading, but if two adjacent columns need to appear next to one another, this layout is likely to disappoint. It is the best, though, for printing, with headers and footers and page numbering as well. The example page was slightly smaller than the single-page version, at 28.1 MB.

While PDF is one of the preferred formats for archiving laid-out documents, it’s worth bearing in mind that standard macOS PDF isn’t compliant with any of the PDF/A standards for archival documents. You’d need a high-end PDF editor such as Adobe’s Acrobat (Pro) CC to prepare and save to any of those.

Despite being ancient and inefficient, PDF normally does a good job of preserving the original format and layout. Text content is preserved, if laid out erratically, making it ideal for content search. Thus, either of the PDF options is best-suited for archiving web pages from Safari.

Lazy loading

Recent versions of Safari appear to load pages lazily, only inserting some images and other included content when scrolled. If you save that page to PNG or PDF without scrolling to the end of the page, the resulting file may skip those images that haven’t yet been loaded. Check the file when it has been saved to ensure that all enclosures have been captured successfully.

Conclusions

• Save As…/Page Source is of limited use, mainly for text-only pages without embedded content.
• Save As…/Web Archive can be excellent for day-to-day use, being complete and faithful, but isn’t an open standard and can prove fragile. It’s therefore not recommended for critical or archival use.
• Save As…/PNG is of limited use, as its images are largest and their content least accessible.
• Export As PDF… is excellent for day-to-day use, complete and faithful, but for serious archival use needs to be converted to comply with an archival standard in the PDF/A series.
• Print…/Save as PDF is an alternative more suitable if you want to print the document out.
• Before saving to PDF or PNG ensure you scroll through the whole page, then afterwards check the saved document contains everything it should.

In the early years of this blog, I used to keep track of some of the more serious bugs in macOS. As that developed into what would have occupied me full-time, I’ve cut back to try to cover some of the most significant. What has surprised me with macOS 26.1 is the sudden rush of new bugs in an update that’s normally expected to fix more than it creates. To consider what might have gone wrong, here’s an overview of those I’ve been investigating so far.

macOS virtualisation (new in 26.1)

A macOS 26.1 guest assigns itself a serial number of zero for the VM, whether the VM has been installed from the 26.1 IPSW image file, or updated from a previous version of macOS. This results in features that rely on the VM’s serial number to fail, the most important being access to iCloud.

Further details.

Virtualisation is exceedingly complicated, and has suffered some previous accidents, such as the inability of M4 hosts running macOS 15.1 to virtualise guests with macOS earlier than 13.4. Although it’s easy to claim that better testing should detect these problems, the number of combinations of host Mac and macOS, and guest macOS increases their risk. Perhaps Apple should actively encourage third-party beta-testing in VMs.

Accessibility (new in 26.1)

macOS 26.1 introduces a new Appearance setting for Liquid Glass, but Apple hasn’t mentioned any change to the existing Reduce Transparency setting in Accessibility. However, that setting in 26.1 no longer disables Liquid Glass effects in sidebars and toolbars as it does in 26.0. User documentation for 26.1 is identical to that in macOS 15:
Make transparent items solid
Some windows and areas of the desktop, such as the Dock and menu bar, appear transparent by default. You can turn these transparent areas a solid grey to make it easier to distinguish them from the background.

This can be seen in the following screenshots.

This is 26.0 without Reduce Transparency.

This is 26.0 with Reduce Transparency turned on. Both the navigation sidebar and the window toolbar are completely opaque, and their contents are fully readable as a result.

This is 26.1 with Reduce Transparency turned on. Although the tools themselves are on opaque backgrounds, other areas remain partially transparent, and the toolbar in particular is visually cluttered and impairs accessibility.

Although this could be claimed to be intentional on Apple’s part, one visual feature that now appears when Reduce Transparency is turned on is the unreadable mess at the top of the System Settings window, where its search box overlays scrolling content in that sidebar.

If that’s intentional on Apple’s part, then macOS 26.1 is unsuitable for users with most forms of visual impairment, and many without.

Finder (new in 26.1)

In some Finder views, such as Column View, selecting an item at the left displays that item’s thumbnail and associated metadata. Below those are a selection of tools offering Finder services, such as Rotate Left, Markup, and more. Those are non-functional in 26.1, and if you want to use any of those services, you’ll have to use an alternative method, such as the contextual menu.

Further details.

This is a strange bug, as it doesn’t occur in macOS VMs, suggesting there’s something more complicated going on. However, it’s also obvious, easy to test, and should never have survived into a release version of macOS.

Clock (macOS 15 and 26)

In macOS 15 and 26, including 26.1, the Clock app offers Timers that are implemented using the mobiletimerd service. The latter appears to hoard every past timer in its property list until that grows too large for the service to run, following which the feature fails to function.

Further details.

According to Apple Support, an earlier bug in the mobiletimerd property list was fixed in macOS Sequoia. However, Apple is apparently unaware of the current problem. The current behaviour of mobiletimerd appears to be the result of poor design: if a service keeps adding more items to its property list, that will grow unconstrained, and sooner or later will cause this problem. It’s possible that fixing the previous bug may have resulted in the introduction of a new bug. Either way, this should have been detected long before it was released to the public.

Spotlight indexing (macOS 10.14 and later)

Since macOS Mojave, plain text files starting with certain characters don’t have their content indexed. Those files are correctly assigned to have their contents indexed by the macOS RichText mdimporter, according to their UTI. However, at the start of content indexing the text is checked for its ‘magic’ content. Those files that aren’t indexed because their opening bytes are recognised as being those of other types, and indexing is abandoned because of an error in the mdimporter. Examples of opening UTF-8 characters that can trigger this include the uncommon LG and HPA, and more common Draw.

Further details.

This is the strangest bug among these, as the Rich Text mdimporter is supposed to index content according to the UTI of the file being indexed, which is being recognised correctly. There should be no need to perform another less reliable method of file type recognition using the ‘magic’ rules that is then causing content indexing to fail. That appears to have been introduced over seven years ago, but never tested adequately against a suitable search corpus.

The same mdimporter had suffered another bug that failed to index the content of any Rich Text file that was also undetected for over six months in 2020-21. Without thorough testing of mdimporters, further bugs are likely to occur in release code and remain undetected for long periods.

Conclusions

• Of these five serious bugs in macOS 26.1, three are new to 26.1, one inherited from macOS 15, and one dates back seven years to macOS 10.14.
• At least two of the five appear to have been introduced when trying to fix earlier bugs.
• All five should have become obvious during testing, and none should have remained in any public release of macOS.
• Both of the bugs that were inherited from macOS 15 appear to reflect flawed design.
• Only one of the bugs, that in virtualisation, is noted in Apple’s developer release notes for 26.1, and that wasn’t carried forward to its release notes for users.

Acknowledgements

I’m very grateful to Rich Trouton, Michele, Paul, Jürgen, Drew, aldous and others who have provided invaluable information about these bugs.

Sometimes known as Diogenes or Havisham Syndrome, pathological hoarding is not uncommon. Where you wouldn’t expect to see it is in the Clock app bundled in macOS, where it can block its features from working. This article describes this bug that can affect macOS Sequoia and Tahoe. I’m very grateful for the persistent work of Michele, who has contributed much of this information.

Timer failure

Michele uses the Timers feature in the bundled Clock app frequently. Recently it has become temperamental, and now won’t display the contents of that view. He has spent a lot of time working with Apple Support, and trying various fixes, but the only way he has found to restore normal function is to use timers from a different user account.

He sent me two long log extracts collected from the moment he launched the Clock app, one with over 6,000 entries, and the other with more than 25,000. Despite Claude’s imaginary problems, I had been unable to discover anything wrong in either of them. Comparing them against a normal log extract there were no obvious differences or abnormalities.

Then someone suggested that he looked at com.apple.mobiletimerd.plist in ~/Library/Preferences, and removed the whole file. That immediately restored normal timer function, and now his Clock app is working perfectly again.

Service crash

Fortunately, one of the two log extracts he sent me contains the explanation. It transpires the Timers feature in the Clock app relies on mobiletimerd, and just over three seconds into that log record, the Clock app tried to fire up mobiletimerd to help it do its job.

mobiletimerd is a background process that relies on Mach IPC, so was launched by launchd to handle the user’s timers:
03.008036 gui/501/com.apple.mobiletimerd [19118] Successfully spawned mobiletimerd[19118] because ipc (mach)
03.062723 com.apple.mobiletimer.logging mobiletimerd starting...

About 0.03 seconds later, mobiletimerd had exceeded its 15 MB memory allowance. It was therefore terminated, leaving that service inactive, and the Timers view empty:
03.099138 kernel process mobiletimerd [19118] crossed memory high watermark (15 MB); EXC_RESOURCE
03.099148 kernel memorystatus: mobiletimerd [19118] exceeded mem limit: InactiveHard 15 MB (fatal)
03.100180 kernel mobiletimerd[19118] Corpse allowed 1 of 5
03.100567 kernel 54578.846 memorystatus: killing_specific_process pid 19118 [mobiletimerd] (per-process-limit 0 0s rf:- type:daemon) 15360KB - memorystatus_available_pages: 1327431
03.100665 com.apple.opendirectoryd PID: 19118, Client: 'mobiletimerd', exited with 0 session(s), 0 node(s) and 0 active request(s)
03.100679 gui/501/com.apple.mobiletimerd [19118] exited with exit reason (namespace: 1 code: 0x7) - JETSAM_REASON_MEMORY_PERPROCESSLIMIT, ran for 110ms
03.100708 gui/501 [100015] service inactive: com.apple.mobiletimerd

A later attempt to get mobiletimerd running again was delayed for 10 seconds, so occurred after the end of that log extract.

Hoarding

Michele had already discovered the cause of this excessive memory use, as its com.apple.mobiletimerd.plist file was nearly 7 MB. By the time that had been expanded into XML text, that could easily have accounted for 15 MB of memory. At first it looked as if this might have been damage or corruption of that property list, but it turns out that the file is fine, just far too big. So how could its preference settings become so large?

Each time you create and run a timer in the Clock app, mobiletimerd seems to append its details to the com.apple.mobiletimerd.plist file. In addition to arrays of MTAlarms and MTStopwatches, it collects MTTimers for every timer you create and run, but never seems to remove any. Thus the MTTimers list continues growing until mobiletimerd exceeds its memory limit and can no longer be run.

It’s not clear why this property list should store all these MTTimers. They’re not accessible to the user, who is only able to run the tiny subset still displayed in the window. Although none of the information in the property list is particularly sensitive, it does provide a full record of the times that each timer has been run, at least until the file occupies too much memory for the timer to function. It’s possible that mobiletimerd also hoards old MTAlarms and MTStopwatches that could result in similar problems.

Solution

The only workaround for those who use timers often is to periodically remove ~/Library/Preferences/com.apple.mobiletimerd.plist and so restore normal timer function. Although some of the solutions recommended to Michele would unintentionally have achieved that, they would also have involved a lot of wasted effort, and none can bring a permanent solution, so would have to be repeated every time that property list had grown too large.

Thus the only way to address this problem is for Apple to fix the bug. Michele has been told that Apple did fix a bug with that property list in Sequoia, although by the observations above it might have introduced a different bug.

Conclusion

If any part of the Clock app becomes dysfunctional, delete ~/Library/Preferences/com.apple.mobiletimerd.plist to see if that fixes it.

When you’ve tried all the logical solutions, restarted, had a go in Safe mode, and still can’t solve a problem, you may need to bring the big guns to bear on it. These are radical fixes that carry a risk of going further than you want, but are all you’ve got left. You might have been recommended them by someone who seems to know best, or, as we saw last week, by an AI. This article looks at the state of those big guns in Tahoe 26.1, and which you should consider seriously.

Reset NVRAM and SMC

Although quick and simple to use, resetting the NVRAM and SMC are well known for fixing all sorts of problems. They’re still valuable in Intel Macs, but you can forget them in Apple silicon, as the SMC resets with each startup, and the NVRAM is protected from user access. The only way you could reset an Apple silicon Mac’s NVRAM is by Restoring it in DFU mode, which almost certainly isn’t something you want to do at this stage.

Reset TCC

TCC is the subsystem responsible for implementing privacy protection, and is notorious for its mystifying misbehaviour. Before convincing yourself that doing anything with TCC is going to help a problem, you should really look for a pattern of misbehaviour that points to one of the resources that it controls access to. If possible, tie this to a single app and use
sudo tccutil reset All com.apple.clock
for example to reset just that one app’s privacy settings.

TCC is also a popular recommendation in solutions that lack a firm logical basis, where there’s no attempt to target one app, but go for the lot with
sudo tccutil reset All
The effect of that is to empty every section (apart from Location Services) in Privacy & Security settings. That’s certain to stop many apps from working properly, and you’ll end up adding them back one by one over the following days or weeks. In some cases, even that doesn’t prove sufficient, and deleting TCC’s database seems the only way forward. That and other issues are discussed here.

tccutil doesn’t appear to have changed in any significant way in Tahoe.

Delete LaunchServices’ database

LaunchServices handles many features including opening apps, populating their Open Recent menu commands, and handling much of the integration of apps with their documents. To achieve that, it maintains an extensive database of apps and other executable components.

Access to LaunchServices’ database and control over it is provided in the lsregister command, buried deep in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support, although there’s a public lsappinfo tool that provides different features and is seldom used. Earlier this year I gave an account of its use in Sequoia, but its most popular option to kill the LaunchServices database has been removed from Tahoe “because it was dangerous and no longer useful”, a fair assessment.

Repair permissions

I have recently reexamined the various forms of repairing permissions. If anyone or anything recommends you run
sudo /usr/libexec/repair_packages --verify --standard-pkgs
you shouldn’t listen to another word they say, as that form went out with El Capitan, and isn’t even possible with a modern version of macOS.

The more modern replacement, initiated by the command repairHomePermissions in Recovery mode, may once have had a purpose, but is now grossly disruptive, as it locks the user out of most of the contents of their Home folder by removing them as their owner.

It would take you hours to restore your Mac to a usable state after performing that ‘repair’. If anyone recommends that you try it, ask them when they last used it successfully.

Clean install

Tahoe does provide convenient methods for clean installing macOS, as described here. One of the simplest is to Erase All Content and Settings using the EACAS option in Transfer or Reset, in General settings. That renders all your data inaccessible by securely erasing its encryption key, then you can migrate from your latest backup when setting up your currently installed version of macOS afresh.

If you want to go back to fresh firmware and macOS as well, then the simplest way is to Restore in DFU mode, as explained here. That also gives you the choice of using any compatible IPSW, making it possible to perform a full downgrade to an earlier version of macOS if you wish. Remember that Apple silicon Macs can’t run a version of macOS that was released before that model shipped. If in doubt, consult Mactracker’s database for the original version shipped with that model.

Summary for Apple silicon Macs:

• Resetting SMC and NVRAM is not possible (still available for Intel).
• Resetting TCC is still available.
• Killing the LaunchServices database is no longer available (but still in Sequoia).
• Repairing permissions is grossly disruptive and should be avoided.
• Clean install can be confined to the Data volume, or include firmware and macOS.

Whatever you choose, I wish you success.

macOS gives you the choice of upgrading to the latest version, but each year makes it easier to upgrade by mistake. For those wanting to stick with macOS 15 Sequoia this has become even harder to get right. This article shows how you can install security updates without risking the upgrade, using my free utility SilentKnight. If you prefer you can do essentially the same thing from the command line.

Check for updates

Run the latest version of SilentKnight (2.12) and it will show you all the updates waiting for your Mac, including the Tahoe upgrade. Don’t, whatever you do, click on the Install all updates button at this stage, or try installing individual updates. Quit SilentKnight and open Software Update in System Settings to install the security update to Sequoia first.

Update macOS

Although you can download and install macOS updates using SilentKnight, it’s far better if you use Software Update to do that. Open that in System Settings and read what it offers very carefully.

Although you know you don’t want to click on Upgrade Now, you should also avoid clicking on Update Now in the expectation that it will update Sequoia to 15.7.2. Instead, click on the ⓘ button next to it to ensure that you only update what you intend.

In this window, uncheck the Tahoe upgrade, and tick macOS Sequoia 15.7.2 and Safari, then click on Update Now. Make a mental note of the large size of the Tahoe upgrade, and when the download starts, check that isn’t being downloaded. If it is, cancel it if you can, quit all other open apps, and shut your Mac down. Leave it a few seconds before starting it up and trying again.

Once the Sequoia security update has been installed and your Mac restarts into 15.7.2, open SilentKnight and let it check for updates again.

Install remaining security updates

In most cases, almost all the outstanding security updates such as XPR should now be installed as part of that macOS update. However, the one you’re likely to have to install manually is XProtect, and you also want to change SilentKnight so it doesn’t put you at risk of inadvertently upgrading to Tahoe.

Open SilentKnight’s Settings and uncheck Allow Install All Updates. That removes the button from its main window that you could click accidentally and initiate an upgrade.

Now open Terminal to install the outstanding XProtect update. Type the following command
sudo xprotect update
press Return and enter your admin password. That update should then be installed from iCloud. Check that by opening SilentKnight one last time.

SilentKnight confirms that all your security updates have been installed successfully. Although the Tahoe upgrade is still waiting there to catch you unawares, there’s now no Install all updates button. When you want to install individual updates such as XProtect, use the Install Named Update… command in the File menu. Paste in the Label of the update, such as XProtectPlistConfigData_10_15-5323, check that it isn’t the Tahoe upgrade, and click the Install Named Update button for each security update you want to install.

There’s one final trick you need to remember. When macOS keeps notifying you of the Tahoe upgrade, click on that notification away from its buttons to open Software Update, then close that window. That should ensure that macOS doesn’t try upgrading your Mac on the sly. If it does start downloading the Tahoe upgrade, quit all open apps and shut down. After a few seconds start up again and that upgrade should be forgotten. For a while, at least.

You may have heard my deep sigh of disappointment last week when I looked through macOS Tahoe 26.1. Despite its bumper crop of 90 fixes for security vulnerabilities, as a scheduled update it has two major flaws. It is at once an opportunity ignored, and a failure to learn from history.

Liquid Glass

Ever since the first beta-release of Tahoe reached developers in June, its human interface has been lambasted like no other. Apple has had a torrent of objections to several of its new features, including the gross rounding of corners of windows and controls, its bland and indistinguishable icons, interference between overlaid content, and its uniform bleached-out tone. In those five months, there has been no shortage of suggestions as to what needs to be improved.

Apple’s response is a Liquid Glass control in Appearance settings that purports to provide a “tinted” variant that “increases opacity and adds more contrast”. As I demonstrated early last week, it does neither, and in Light mode in the great majority of Apple’s own apps, this “tinted” variant doesn’t make a blind difference.

Above is Light mode, Liquid Glass set Clear, without Accessibility. Below is the same, but with Liquid Glass set to Tinted.

After many attempts to find some difference between Clear and Tinted in the bundled apps I use most often, I’ve decided that they are visually identical. And where the Liquid Glass effect results in optical interference between layers, Tinted doesn’t alter opacity to eliminate that interference.

This is illustrated in the defaced search box at the top left of System Settings, where the blurred contents of the navigation sidebar at the left remain visible underneath the window’s search box. I can’t understand how any designer could see that released to the public, and providing the new Liquid Glass setting is farting into a hurricane.

Background Security Improvements

Although Apple went out of its way not to let us know, I’m actually glad to see the return of Rapid Security Responses (RSR), even if they’ve been given this sanitised name. What disappoints me deeply is that the BSI shows no sign that Apple has learned from its past mistakes with RSRs just over two years ago.

RSRs, which have never been officially declared dead, were downloaded through Software Update, and gave the user the choice of installing them automatically, downloading and installing them when they chose to, or ignoring them and waiting for the next macOS update. Not only that, but once installed, they could be removed and macOS reverted to its previous state.

What Apple never did get right is how to number the macOS version once an RSR had been installed. Rather than extend version numbers consistently with a fourth digit, Apple decided to append a letter in parentheses, making 13.4.1 become 13.4.1 (a) when its first RSR had been installed. When the first RSR was released on 1 May 2023, Safari’s build number was changed, but not its version number. But with the second RSR on 10 July, someone mistakenly changed Safari’s version number from 16.5.1 to 16.5.2 (a), and that was therefore given as its User Agent, and promptly broke many major websites including Facebook.

Because that RSR could be removed by the user, there was an immediate solution, and Apple delivered a revised RSR a couple of days later.

From this, we learned that:

• RSRs undergo very little testing before release, as they’re supposed to be issued quickly.
• Because they undergo such little testing, their chances of significant incompatibilities are greater.
• Giving the user the option to delay installing an RSR saves many from being caught out by flawed RSRs.
• Giving the user the option to uninstall an RSR is essential in the event that one proves to be flawed.
• Knowing when an RSR is being installed is essential if users are going to be able to identify the cause of problems arising from them.
• Numbering of macOS versions needs to be restructured to accommodate RSRs.

Now, over two years later, it seems Apple has forgotten those lessons. It won’t even describe these as security updates, but “improvements”, won’t include them in the release notes for 26.1, hides their single control at the very bottom of a long list in Privacy & Security settings, rather than in Software Update, provides no manual option, and no means to uninstall them.

I wonder how long it will be before we all regret those decisions, and have to repeat past mistakes before we can learn from them.

If you have updated your Mac to Tahoe 26.1, you may be blissfully unaware that it will now automatically download and install some security updates, regardless of its Software Update settings. Open Privacy & Security settings, scroll down to the end and you’ll see a new item, Background Security Improvements, that Apple has kindly turned on for you. There are matching new settings in iOS and iPadOS 26.1 that are also enabled by default.

Apple seemingly forgot to mention these when listing the changes in 26.1, and its documentation of these Background Security Improvements (BSI) is sketchy to say the least. However, the description there as “lightweight security releases for components such as the Safari browser, WebKit framework stack and other system libraries” is so similar to that for RSRs as “improvements to the Safari web browser, the WebKit framework stack, and other critical system libraries” that we can only conclude the BSI is a rebranded RSR.

What is an RSR/BSI?

Although almost all of macOS is contained in the System volume, turned into a snapshot that’s protected by a tree of hashes with a signature, then mounted as the Signed System Volume, there are additional components that are delivered in separate cryptex files. These are also heavily protected with signatures to verify their contents, and are mounted well after the kernel has booted. APFS then grafts them into the root file system so their contents appear in the correct places. There are currently two main cryptexes common to all Macs, one containing Safari and its WebKit components, the other with dyld caches supporting frameworks. Apple silicon Macs additionally have many smaller cryptexes to support AI and related features.

Because those cryptexes are separate from the SSV, they can be unloaded, replaced with updated versions, and reloaded without necessarily having to reboot the kernel, or go through any of the complex procedures to update macOS itself. Apple first tested this new type of update, a Rapid Security Response (RSR), in beta-releases of macOS 13 Ventura, and the first was publicly released for Ventura 13.3.1 on 1 May 2023.

How do RSRs work?

RSRs have been released using the regular Software Update mechanism, controlled in its settings, and can be uninstalled manually even if you have opted for them to be installed automatically.

To remove an RSR, you open System Settings > General > About, and look down for the macOS version. At the right of that line is an ⓘ button: click on it to see the dialog above, allowing you to uninstall it.

Why don’t we get RSRs now?

Apple proudly announced RSRs at WWDC in June 2022, and they were listed among the new features in Ventura: “Get important security improvements to your devices even faster. This isn’t a standard software update. These improvements can be applied automatically between normal updates — without a restart.”

Although the first in May 2023 seemed to go well, the next on 10 July was an embarrassing disaster. RSR 13.4.1 (a) fixed one WebKit vulnerability, but unfortunately it also changed the version number of Safari to 16.5.2 (a), which was reflected in its User Agent, so broke access to many popular websites including Facebook. That had to be rectified in RSR 13.4.1 (c) released three days later. And all three of these RSRs required the kernel to be rebooted after their installation.

Since then, as far as I’m aware, Apple hasn’t released any further RSRs, although they’ve still been referred to throughout its documentation.

Their greatest limitation is that they can only fix vulnerabilities that are confined to Safari, WebKit and other components that are delivered in cryptexes. More commonly, urgent security patches also require changes to software in the SSV, for which the only solution is a full update. For example, during the year that macOS Sequoia was current, it received six patch updates in between those scheduled. Of those, only two might have been suitable as RSR/BSI updates, as all the others required changes to the SSV.

How do BSIs work?

If Apple’s current account of BSIs is complete, the only control we have over them is whether they’re downloaded and installed automatically. If you opt for that, as Apple has set as the default, then you won’t be given any warning, or even informed when the BSI has been installed on your Mac. The only way you’ll be able to learn that is by trawling through the list of software installations in System Information, although Apple will post information about the BSI in its security release notes, following its release.

If there’s a problem with a BSI, such as that in the second RSR in July 2023, then there’s no option to uninstall the BSI and revert to a previous version of that cryptex, as there was with RSRs. However, Apple might decide to remove the BSI from your Mac.

Given the short and unfortunate history of RSRs, that might appear surprising.

When Apple released macOS 26 Tahoe I published an article exploring how you can configure its redesigned interface, using its additional variations to appearance modes and its new Liquid Glass effects. When Tahoe 26.1 was released a couple of days ago, it changed those by adding a new control for those Liquid Glass visual effects. This article shows how that might change your options.

There are now four sets of controls:

• Appearance mode, Light or Dark, in Appearance settings;
• Liquid Glass setting, Clear or Tinted, in Appearance settings;
• Display variations to Reduce transparency or Increase contrast, in Accessibility settings;
• Icon & widget style, in Appearance settings.

Apple’s descriptions of the two states for Liquid Glass read:

• “Clear is more transparent, revealing the content beneath.”
• “Tinted increases opacity and adds more contrast.”

Those terms indicate an overlap with Accessibility settings. However, if either of the Accessibility settings is enabled, then the Liquid Glass setting is unavailable. I also presume that the word tinted here refers to the faint colouration that might be seen in what would otherwise be a transparent view, rather than any more generalised addition of colour.

Light mode

There are four overall variations of light mode, depending on Liquid Glass and Accessibility settings.

The starting point and default is in light mode, Liquid Glass clear, without Accessibility, and icon & widget style set to Default. Note the effects of transparency on the menu bar, widgets, the Liquid Glass effect in the left side of the Dock, and the upper row of icons in the Finder window. If you like those, you don’t have to change any settings.

This is the same, but with Liquid Glass set to Tinted. I’m unable to see any difference between those settings in this example.

This is light mode with Reduce transparency enabled in Accessibility settings. This disables all Liquid Glass effects and restores the traditional menu bar and Dock. The effect on Desktop widgets is perhaps less beneficial.

In light mode with Increase contrast (automatically coupled with Reduce transparency) enabled, the predominant effect is the outlining of controls within each window, rather than any change in contrast. Colours used by the system, such as the traffic light controls at the top left of each window, and those in themes, are darker, but those elsewhere, as in icons, aren’t changed. The effect here is to make controls clearer rather than actually changing contrast.

Dark mode

Without changing Accessibility and leaving Icon & widget style set to Default, and Liquid Glass set to Clear, dark mode shows transparency and Liquid Glass effects as you expect. These are again most visible in the menu bar, Dock, and the upper row of icons in the Finder window.

This is the same, but with Liquid Glass set to Tinted. Two most obvious differences are seen in the back-forward controls by the title of the Appearance settings, which oddly appears white, and the widgets, which are much darker. There are some inconsistent differences in the toolbar of the Finder and Tips windows, but they are more subtle.

With Reduce transparency enabled in Accessibility settings those transparency and Liquid Glass effects are removed.

Enabling Increase contrast outlines controls clearly, but any changes in system colours are more variable than in light mode.

Icon & widget style

This is new to Tahoe and only affects the rendering of icons and widgets. Liquid Glass settings don’t appear to have any effect on these.

Using light mode without any Accessibility changes, the Default setting for Icon & widget style is the baseline, showing icons in their ‘normal’ state.

Dark icon settings in light mode contrasts more but their readability may suffer.

When Icon & widget style is set to Clear, most are decolourised, making them significantly harder to read, and impossible to distinguish in the sidebar of System Settings.

The final option is for Icon & widget style to be Tinted (no relation to the Liquid Glass setting Tinted), where they’re rendered in monochrome using a colour of your choice, selected from the popup menu below. On iPhones and other devices that are available in several case colours, some have decided to set tinting to match the case, something you might like to try with an Apple silicon iMac, for example.

However, be careful in both Clear and Tinted styles, as it’s easy to end up making many icons unreadable and almost indistinguishable, here by setting the last of those to Graphite colour. This is one of the obvious drawbacks in Tahoe’s flexibility, in that many combinations of appearance mode, Accessibility settings and icon and widget style degrade its human interface rather than enhancing it. At least you now know what not to try, and how to return it to its defaults.

Summary of controls

• Appearance mode, Light or Dark, in Appearance settings;
• Liquid Glass, Clear or Tinted, in Appearance settings;
• Display variations to Reduce transparency or Increase contrast, in Accessibility settings, but those automatically override Liquid Glass settings;
• Icon & widget styles, in Appearance settings, with Icon, widget & folder colour when appropriate.

Here are two reports on bugs affecting macOS Tahoe 26.1 that might make you wait before updating.

macOS VMs can’t access iCloud

If you update a macOS virtual machine to 26.1, or create a new VM in 26.1, it loses its Serial number, which is apparently set as 0. Although most things you might do with a VM aren’t affected by that, it will prevent that VM from being able to access iCloud (if that has been enabled for the VM) and related features.

There’s no workaround for this, as serial numbers are created when the VM is first made, and the user can’t add or change them after that. If your VM needs access to iCloud, keep it running 26.0.1 instead.

I’m very grateful to Rich Trouton of Der Flounder for this information, which is also given in Apple’s developer release notes.

Finder Services

In some Finder views, such as Column View, selecting an item at the left displays the item’s thumbnail and associated metadata. Below those are a selection of tools offering Finder services, such as Rotate Left, Markup, and more. Those are non-functional in 26.1, and if you want to use any of those services, you’ll have to use an alternative method, such as the contextual menu.

I’m very grateful to Michele for letting me know of this.

If you know of any serious bug that is new to 26.1, please let me know and I’ll add it to this list after confirmation.

The update bringing macOS 26 Tahoe to version 26.1 is substantial, and has a great many increases in build numbers, so this overview of its changes concentrates on those substantial enough to merit an increment in version number. The update itself varies widely in size, ranging between about 3-14 GB, which is unusual and hard to explain.

Apple’s security release notes report that it addresses a total of 90 vulnerabilities, none of which have been reported as being exploited in the wild.

General release notes are extremely brief, and include:

• a new tinted appearance option for Liquid Glass,
• AutoMix support for Apple Music over AirPlay,
• better FaceTime audio over low bandwidth connections,
• Communication Safety and Web content filters are enabled by default for existing child accounts.

The only other release notes available are those for enterprise.

There are firmware updates to bring Intel T2 Macs to 2094.40.1.0.0 (iBridge 23.16.11072.0.0,0), and Apple silicon Macs to iBoot version 13822.41.1. The build number for macOS 26.1 is 25B78.

Version changes seen in bundled apps include:

• Audio MIDI Setup to 3.7
• Books to 8.1
• ColorSync Utility to 12.2.0
• Freeform to 4.1
• iPhone Mirroring to 1.5
• Music to 1.6.1
• News to 11.1
• Passwords to 2.1
• Safari to 26.1 (21622.2.11.11.9)
• Screen Sharing to 6.1
• Stocks to 8.1
• Tips to 26.1 (routine for this update)
• TV to 1.6.1.

Notable changes seen in /System/Library include:

• several PDF Automator actions have build increments
• Archive Utility has changed, with removal of a pref pane
• SystemIntents is a new app added to CoreServices at version 1.0
• two new driver extensions (dext) have been added, for AppleSunriseBluetooth and AppleSunriseWLAN
• kernel extensions updated include many for AGX, as well as AppleDiskImages2 and AppleEmbeddedAudio
• new kernel extensions include AppleSPINORFlasherDriver at version 1.0, and a family of AppleT8142 kexts to support the M5
• APFS is updated to version 2632.40.15
• added to DiagnosticExtensions are new items ScreenTimeDiagnosticExtension and ToolKitDiagnosticExtension
• added to PrivateFrameworks are new SpotlightDiagnostics and ThumbnailsBlastDoorSupport frameworks
• the RichText mdimporter is unchanged, remaining at version 6.9 (350).

As expected, the Spotlight bug described here recently remains unchanged in macOS 26.1.

Apple has just released macOS 26.1 Tahoe, together with security updates for Sequoia to bring it to 15.7.2, and for Sonoma to 14.8.2. There are also separate updates for Safari in 15.7.2 and 14.8.2.

The Tahoe update has at last appeared here in Europe, and is a hefty 4.7 GB for Apple silicon Macs.

Security release notes for 26.1 report around 90 vulnerabilities have been fixed, none of which have been reported as being exploited in the wild. Listings for Sequoia give about 54, and for Sonoma about 46.

The only other release notes available so far are for enterprise here.

Details provided by Apple beyond the general ‘bug fixes and updates’ include a new tinted option for Liquid Glass, that has already been widely discussed among beta-testers, Apple Music AutoMix support over AirPlay, better FaceTime audio in low bandwidth connections, and Communication Safety and Web content filters enabled by default for existing child accounts. That seems surprisingly little to squeeze into a mere 4.7 GB, and I suspect there will have been more extensive changes.

The build number for macOS 26.1 is 25B78. Firmware in Apple silicon Macs is updated to iBoot version 13822.41.1, and Safari is version 26.1 (21622.2.11.11.9).

I will post a detailed analysis of changes tomorrow, 4 November.

Important note for those intending to update to 15.7.2 or 14.8.2 rather than Tahoe:
To be certain the correct updates will be installed, in the Also Available section of Software Update, click on the ⓘ button to the right of the Update Now button for Other Updates and select the appropriate macOS update and Safari, deselecting the Tahoe update there. That should ensure you don’t inadvertently upgrade to Tahoe.

[Last updated 06:42 4 November 2025]

There’s a bug in Spotlight that can prevent it from indexing any of the contents of susceptible text files. This has been present since macOS 13 Ventura if not before, and is still present in Tahoe 26.0.1. I didn’t discover this myself, though: it was reported to me by Jürgen, to whom full credit is due. It’s also one of the strangest bugs I’ve come across, and all depends on two letters.

Demonstration

To demonstrate this bug, all you need is a single UTF-8 plain text file, created by TextEdit or any other app capable of saving plain text. Start the text with the two characters L and G, both in capitals. Then add one or more distinctive words, such as
LG syzygy

Save that file to a folder that you know is indexed and searched by Spotlight, then a few seconds later try searching for the word syzygy in its contents. Extend this as much as you want, maybe appending the whole of one of Charles Dickens’ novels, but no matter how you search for its contents, that file will never be found. If you want to get more serious, use that text file in my Spotlight test app SpotTest, and it will also be unable to find that file.

This only works with plain text files, not Rich Text, PDF or HTML. It’s also sensitive to those two letters. Set one of them in lowercase, preface them with a space, or substitute a different letter, and the contents of that file will then be indexed correctly and searchable as normal.

Affected macOS

I have tested this in virtual machines going back as far as macOS 13 Ventura, and it’s present in them all. If you have access to an earlier version of macOS, I’d be interested to know whether it affects that as well.

Cause

The two UTF-8 characters concerned, 4c 47, don’t appear to be anything special that could be misinterpreted.

Although it’s not easy to distinguish failure to index from search errors, saving a test file does result in repeated reports of an error that could cause Spotlight to fail when trying to index the file, for example the log entries
30.946740 mdwrite Decoding error: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=[private]} for [private]
30.951004 mds Decoding error: Error Domain=NSCocoaErrorDomain Code=4864 UserInfo={NSDebugDescription=[private]} for [private]

Error code 4864 is NSCoderReadCorruptError, implying that the presence of those two characters at the start of a text file may be triggering a bug in RichText.mdimporter, the importer module shipped in macOS that’s responsible for indexing plain text files.

My current hypothesis is therefore that text files starting with the characters LG are failing to have their contents indexed correctly because of a bug in RichText.mdimporter.

History

This isn’t the first bug in the RichText.mdimporter. In macOS Catalina 10.15.6, the same mdimporter (then build 319.60.100) introduced a bug that broke indexing of Rich Text (RTF) files. That was perpetuated through early releases of Big Sur until it was finally fixed in RichText.mdimporter build 326.11 in Big Sur 11.3.

Because text files starting with the characters LG are exceedingly unusual, this bug appears to have been left in RichText.mdimporter for a great deal longer.

I will be reporting this to Apple in Feedback later this month. Please feel free to file your own Feedback if you can spare the time.

Summary

• In macOS 13 to 26, plain text files starting with the characters LG cannot be searched for their contents.
• This appears to be the result of a longstanding bug in RichText.mdimporter in macOS.
• If those characters are altered, or prefixed by a space, indexing and search behave normally.

I’m very grateful to Jürgen for drawing this to my attention.

One of the longstanding oddities in macOS security has been scanning of a notarized app by XProtect before it can be launched. When apps are submitted to Apple for notarization, they’re scanned for malicious content using methods at least as effective as XProtect, and should any notarized software subsequently be identified as malicious, its notarization and signature are revoked immediately. That should make it impossible for any app with a valid notarization ticket to contain malware known to Apple.

One of the improvements believed to be incorporated into macOS 26 Tahoe is that validly notarized apps are no longer scanned by XProtect. When I examined this recently, I confirmed that was correct, although in practice this did little if anything to improve the launch times of apps. This article extends those observations to include app first run, when detection of malware is most critical.

When an app is run for the first time in a recent version of macOS, there are three options:

• apps that aren’t quarantined, including those signed by Apple and almost all of those supplied through the App Store, normally don’t undergo additional checks;
• quarantined apps that have been installed correctly undergo full first run checks, that have previously included XProtect scans;
• quarantined apps being run from the immediate location they arrived in not only undergo full first run checks, but are additionally moved to be run from a random path in what’s commonly known as app translocation, or Gatekeeper Path Randomisation (GPR).

This article considers the second and third of those.

Quarantined first run, no translocation

In Sequoia 15.7 these apps undergo a “direct malware and dylib scan” using the XProtect data stored in its new location, in /var/protected/xprotect/XProtect.bundle. Because this is the first run, once Gatekeeper assessment is complete and confirms the app is safe to run, the user is presented with a dialog asking for their consent. Because of the inevitable delay in responding to that, two times can provide meaningful estimates of performance:

• the time between the log entry reporting that Gatekeeper is performing a scan (“GK performScan”), and declaring the Gatekeeper scan complete (“GK scan complete”), in this case 5.35 seconds;
• the time between the start of the XProtect scan (“Xprotect is performing a direct malware and dylib scan”) and the declaration of scan results (“GK Xprotect results”), here 5.33 seconds.

In Tahoe 26.0 no XProtect scan was attempted, as com.apple.xprotect entered in the log “Xprotect is skipping executable assessment”, and com.apple.syspolicy.exec confirmed “Skipping XProtect scan on seen software”. Despite that, the first of those times was nearly twice that required in Sequoia, at 10.29 seconds. The reason for this is unknown, but over that period the log contained about 13,000 entries reporting “SecKeyVerifySignature”.

As a result, a smaller and simpler app was used to test app translocation and its effects.

Quarantined first run, with app translocation

Instead of using Calibre as my test app here, I chose my own app Podofyllin, with its 442 KB executable and no dylibs or other complications. This was downloaded from here, unarchived automatically in the ~/Downloads folder and there run from the folder it came in, to ensure that it would be translocated.

Early in the launch sequence, com.apple.securityd writes a log entry indicating it has created the translocation directory “SecTranslocateCreateSecureDirectoryForURL”, following which diskarbitrationd replicates the app bundle to what appears as a different volume in the translocation path. Then a first run Gatekeeper assessment is performed, including an XProtect scan, checking the notarization ticket using CloudKit, a user approval dialogue, and setting up the app’s provenance tracking.

In Sequoia 15.7, the XProtect scan took 0.15 seconds, and the total period required for the Gatekeeper scan was 0.19 seconds.

In Tahoe 26.0, com.apple.syspolicy.exec logged “Skipping up front XProtect scan” and com.apple.syspolicy went straight on to perform the CloudKit lookup. This was confirmed later by com.apple.syspolicy.exec in “Skipping XProtect scan on seen software” just before reporting the Gatekeeper scan was complete. With no time required for the XProtect scan, the total used for the Gatekeeper scan was 0.16 seconds, 88% of that for Sequoia.

Stuck in translocation

Over the last couple of years it has become clear that some apps, even though they have been moved from their original download location, continue to undergo translocation whenever they’re run, and that can cause ongoing problems.

An app will be translocated if all the following apply:

1. the app has a com.apple.quarantine extended attribute attached;
2. the app must be opened by Launch Services (normally the Finder) rather than a command shell;
3. the app hasn’t been individually moved in the Finder from the folder it was unarchived or downloaded to, wherever that was.

Tests in recent macOS show that apps won’t be translocated if:

• they have no com.apple.quarantine extended attribute, or it has been removed;
• they have been moved individually in the Finder so they’re now enclosed in a different folder.

The following will normally result in the app being run in translocation:

• opening the app in the folder that it first arrived in, even if that folder has been moved elsewhere, such as into an Applications folder;
• moving the app at the same time as other apps, even if they’re all put into an Applications folder. Group or simultaneous moves in the Finder aren’t counted as a move that will stop future translocation;
• running the app again without moving it from a location from which it has already been translocated. Until the app is moved from that location, it’s likely to be repeatedly translocated every time that it’s run.

You can readily check whether an app is being run in translocation by starting the app and either:

• inspecting that app in Activity Monitor, by selecting it in the CPU view and clicking on the ⓘ tool,
• running ps xw | grep AppName in Terminal.

If the path shown for the app is something absurdly long like /private/var/folders/x4/[random chars]/T/AppTranslocation/[UUID]/d/, then it has been translocated.

If an app that appears to have been correctly installed is still being translocated, move it individually (one app at a time) from the folder it’s currently in to a different folder, run it from there, close the app, and move it back to where you want to keep it.

Conclusions

• macOS 26.0 Tahoe skips reported XProtect malware scans when a notarized app is run for the first time in quarantine, even when it has been translocated.
• Despite that, first run checks in Tahoe can still take significantly longer than in subsequent runs, although the reason for that isn’t clear from the log.
• If an app doesn’t appear to run properly, check whether it’s stuck in translocation. If so, free it as explained above.

Among the foundations of visual design are two essential insights, into understanding human vision, and the experience gained from our long history of visual communication. Common to both is the importance of tone (brightness, lightness, etc.) and its contrasts. Not only do around one in twenty males struggle to distinguish some or most colours, but all of us rely on tone to interpret what we see in the absence of information from colours.

This has been illustrated throughout the history of visual art, where those who have excelled in visual communication have placed particular emphasis on tone. Consider Lucas Cranach the Elder (1472–1553) as an example of proven classical methods.

We know a lot about the tonal modelling that Cranach used in his Martyrdom of Saint Catherine painted in 1504-5, through the infra-red reflectogram below, which effectively looks through the paint layer at the underdrawing beneath.

Cranach’s assistants first laid a thin layer of light reddish imprimatura on the white ground of this panel. Once that had dried thoroughly, Cranach himself would have laid down the underdrawing using a pointed brush with carbon black ink. This extended to the tonal modelling shown clearly in the reflectogram.

Following that came undermodelling using grey tones of carbon black and lead white. Some of the darker garments were preceded by a local underpainting of black, a technique popular at the time for dark red fabrics in particular. Much of this seems to have been completed quickly, probably within a single day.

A common practice among masters discards colour altogether and builds the image using tone alone, known as grisaille.

Three centuries after Cranach, the great French illustrator and painter Gustave Doré (1832–1883) painted a group of three works about the Franco-Prussian War entirely in grisaille. Best known among those is The Enigma (souvenirs de 1870), from 1871.

Even a few minutes exposure to a screenful of macOS Tahoe’s windows demonstrates how its new design goes out of its way to ignore those essential insights, and present us with controls that are either bleached- or blacked-out depending on our choice of appearance mode.

In light mode, with default transparency, tool icons and text are clearly distinguished tonally, as are some controls including buttons and checkboxes. However, text entry fields are indistinguishable from the background, and there’s a general lack of demarcation, particularly between the controls and the list view below.

Oddly, dark mode outlines some controls better than light mode, but text entry fields and the list view below still lack demarcation.

One popular mitigation to this lack of tonal contrast is to resort to an Accessibility control that purports to reduce transparency rather than increasing contrast, although in fact its main advantage in Tahoe is to improve tonal contrast, at least in the toolbar.

This still has no effect on controls below the toolbar, and fails to demarcate text entry fields or the list view below.

The elephant in macOS Tahoe is its ignorance of human vision and our long experience of visual communication. It’s an elephant that comes in two appearance modes, bleached-out white or blacked-out black. It has little if any impact on the interface of Apple’s other OS 26es, but it makes macOS a pain to look at and harder to use. I feel sure that Lucas Cranach the Elder, Gustave Doré and every other self-respecting visual artist would be equally offended.

Before macOS Tahoe, the biggest sticking point in virtualising macOS on Apple silicon Macs has been their lack of support for the App Store. From the outset this has been an ironic limitation. Here’s some of Apple’s most advanced technology running on its latest hardware, and it can’t even run the apps that Apple sells, only those supplied direct by their developers.

VMs can now have iCloud and iCloud Drive support, Messages, FaceTime, FileVault, and plentiful shared folders, but the one thing they have lacked that renders them useless for many users and many purposes is that can’t sign into Apple services, particularly the App Store. Some apps, including those in Apple’s iWork suite, will run in a VM despite it being unable to sign into your account, but you can only window-shop in the App Store, and most of its apps will simply refuse to run, even free ones.

I’ve long suspected that this is an example of Apple Commercial constraining Apple Engineering. To be useful, macOS VMs would have to be exempted limits on the number of Macs authorised to access services, and that could open up the possibility of third-parties bypassing FairPlay and the digital rights controls embedded in macOS. It must be deeply frustrating to those working on virtualisation, knowing that it could be done but won’t be.

So the only substantial new feature for macOS virtualisation in Tahoe is the introduction of ASIF disk images. For the time being, I’m not sure they’re going to change much for most of us who host our VMs on local APFS storage. As they still don’t enjoy proper API support, I don’t see any compelling reason to rush into their use, unless you want to host your VMs in the cloud.

Upgrading to Tahoe has, though, drawn attention to problems lurking for those who created VMs of 50 GB or smaller, who now want to enlarge them for this purpose.

Resizing VMs

Don’t skimp when creating a new VM. Give it a useful size, as its Disk.img is stored as a sparse file, so won’t take all that disk space unless you fill it to capacity. I now make my default VMs 100 GB to ensure there’s ample free for updates and anything else that might arise.

If you do have a treasured VM that’s too small, you may well be able to increase its size, either using Disk Utility or the hdiutil resize command tool if you prefer. To do this, start by duplicating your VM in the Finder. That creates a clone, and lets you fall back to the unaltered original if the resizing goes horribly wrong.

To resize the disk image using Disk Utility, you first have to move it out from inside its VM bundle, easily done in the Finder. Then in Disk Utility’s Images menu use the Resize… command, select that Disk.img and enter its new size. Add a little, around 8%, to allow for overheads, and let Disk Utility get on with the work.

Here’s Disk Utility inside this Tahoe VM, showing its 50 GB virtual disk.

I then resized it to just over 100 GB.

Here it is afterwards, now showing a full 100 GB.

I gather from others that resizing doesn’t always work. If you can’t get it to, then the only way forward is to create a new VM with the larger capacity and copy across the contents of your old VM. One obvious way to make that simpler and more thorough would be to use Migration, either during configuration of the new VM, or shortly afterwards.

I’m very grateful to Michael for telling us of his success in migrating from a small to a larger VM in Tahoe. I’m also more than a little jealous, as I’ve so far been unable to get it to work for me.

I’m also mystified as to how two macOS VMs running concurrently on the same Mac could establish a connection to support the file transfers required in migration. Neither can expose its virtual folders as shared folders for the other, and in any case shared folders are strictly circumscribed. Sharing them over AFP runs into a quirk of their bridged networking, that both of the VMs will default to using the same network IP address. In my failed tests, the destination Migration Assistant was able to recognise the source, but failed to connect to it successfully.

For the moment macOS virtualisation hasn’t made any substantial improvements in Tahoe. It still can’t sign into Apple services, and AI remains unavailable. Let’s hope the next year brings more and better, and realises more of its potential.

Browsing through the /System/Library folder in macOS Tahoe you’ll no doubt be surprised to see a new folder, between LaunchAgents and LaunchDaemons, named LaunchAngels. This article takes a preliminary look at what’s in there, and what these new additions to Apple’s bestiary do.

Launch Agents and Launch Daemons

These have been used in macOS for a great many years, probably since the introduction of launchd in Mac OS X 10.4 Tiger in 2005. These folders contain property lists for:

• Launch Daemons are standalone background processes managed by launchd, running as root before the user logs in, and communicating indirectly with user processes, normally by XPC. They’re not allowed to connect to WindowServer.
• Launch Agents are also managed by launchd, but normally run on the user’s behalf, communicating with other processes and daemons. Although they can have GUI interfaces, they’re normally minimal.

Before you have logged in, launchd runs services and other components specified in property list files in the LaunchAgents and LaunchDaemons folders in /System/Library, and in /Library. Those in /System/Library are all part of macOS, owned by Apple, and locked away on the SSV, but those in /Library can include those installed by third party products, although these days more are being enclosed in app bundles. As they’re run before the user logs in, those work for all users, so are global services.

These property list files contain keyed settings to determine what launchd does with what. Although they can contain many other key-value pairs, two most important ones are ProgramArguments (or Program), which tells launchd what to run, and RunAtLoad, which determines whether launchd should run the service or app whenever your Mac starts up and it loads those agents and services. Other keys determine whether the agent/service should be kept running at all times; if that is set, if it crashes or is otherwise terminated, launchd will automatically start it up again. That’s important for background services that apps rely on to function.

Launch Angels

As of macOS 26.0.1 there are three Launch Angels, each with a property list in /System/Library/LaunchAngels. Those relate to three apps now in /System/Library/CoreServices,

• AccessibilityUIServer,
• GameOverlayUI,
• PosterBoard.

AccessibilityUIServer is an addition to the Accessibility process group, and is listed in the processes in Activity Monitor as Accessibility. It thus runs in the background, supporting Accessibility features in Tahoe. These might perhaps extend the Accessibility enhancements for UIKit provided in UIAccessibility to macOS.

The other two apps aren’t run at load, so must be run on demand. GameOverlayUI appears to be responsible for providing the new Game Overlay features, and I suspect that PosterBoard is responsible for Lock Screen customisation. A key set for each of these in their property list is _ExperimentalNonLaunching, suggesting that these are still in test.

Apple describes Game Overlay as allowing “players to stay in the game when it matters most. Players can easily adjust settings, connect with friends, and check out the latest In-App Events and supported Game Center features, all without leaving their game.”

RunningBoard

What’s most unusual, and may be new with Tahoe, is that all three property lists include settings for RunningBoard and its life cycle management. These are the keys

• Managed, to require life cycle management by RunningBoard, set to true for all three;
• Reported, presumably to set RunningBoard to report its use of system resources, again set to true for all three.

I’m not aware of any similar RunningBoard settings for property lists in the LaunchAgents or LaunchDaemons folders, though.

Conclusions

• Launch Angels are currently three new services for macOS 26 Tahoe, run through launchd using property lists in /System/Library/LaunchAngels.
• Those extend Accessibility, provide Game Overlay, and probably support Lock Screen customisation.
• They are unusual in having RunningBoard settings in their property lists.
• At least for the moment, Apple doesn’t intend anyone else trying to use Launch Angels of their own.
• As the LaunchAngels folder is on the SSV, it isn’t exploitable. Whether a LaunchAngels folder might work in the main Library folder is a different question, though.

If you bought an M1 Mac with just a 256 GB internal SSD and have kept up with macOS upgrades and updates, should you be worried that it’s running out of space by the time it makes it to Tahoe? Dare you look at Storage settings to see how much of the SSD is now swallowed up by System Data? This article explains why macOS 26 shouldn’t devour the last of your SSD, and how you can ensure that it doesn’t.

What’s on your Mac’s internal SSD?

Internal boot disk layout is most complex in Apple silicon Macs, as theirs is divided into three partitions (or APFS containers). Two are hidden and contain pre-boot and other low-level support files, and amount to around 6 GB. The Macintosh HD partition then takes the lion’s share, the whole of the remainder. Even on a 256 GB SSD, that’s about 250 GB.

Volumes within Macintosh HD include:

• System, just over 12 GB,
• VM, varies in size according to how much virtual memory is swapped out to disk,
• Preboot, just under 8 GB,
• Recovery and others not normally mounted, a total of less than 2 GB,
• Data, whose size is determined by what you store there.

The system your Mac actually boots into isn’t the System volume itself, but a snapshot made of it, occupying the same space, plus a little extra for the snapshot’s metadata including its tree of hashes to form its seal and signature. Because this is a snapshot it uses the same data stored for the System volume, and doesn’t double that up.

This should allow your Data volume a maximum of 228 GB, less any space required by the VM volume. Although installation of a macOS upgrade or update will require substantial additional space, once that’s complete the space taken by the System volume and its snapshot should fall to little more than 12 GB.

What happens when macOS is upgraded?

In traditional macOS upgrades, the Installer app was downloaded first, and itself required around 13-15 GB. That was run, and expanded its contents to be installed onto the System volume, replacing much or all of it.

Updates work more economically, as they contain only the files that have changed, so far less than the Installer app. When they’re installed, they replace only those files changed in the System volume, ready for a new snapshot to be made from that, to be used to boot that Mac. So an update-style upgrade, as you should get when going from macOS 15.7 to 26.0, should require a much smaller download, a faster install, and less space to install the new version of macOS. However, the end result should be identical, with exactly the same files installed in the System volume, and exactly the same in the snapshot used when running.

Whichever is used, the installation process is similar. First, the files to be installed are expanded, then they’re written to the mounted System volume, with some going onto the Data volume as well. Once the System volume is complete, a snapshot is made of it, and that’s sealed using a tree hierarchy of hashes, culminating at the top of the tree in the seal.

What is System Data?

Storage settings scans the contents of the boot volume group, Macintosh HD, and divides the storage used into different categories like Applications and Podcasts. It appears to total those up and account for the remainder of storage used in the category System Data. That doesn’t include the size of the System volume, or its snapshot, but can include temporary files like caches, snapshots, and anything else it can’t account for in other categories.

Taking control

If there are substantial amounts of space that aren’t accounted for on your Mac’s internal SSD, and you want to reduce that, you need to account for it before deciding what to do about it.

First check for large snapshots. I hear repeatedly of Macs that turn out to have hundreds of GB being used by snapshots unnecessarily, and the current record is over 400 GB. The easiest place to check for those is in Disk Utility. In the sidebar on the left select the Data volume, then Show APFS Snapshots in the View menu for them to be displayed at the foot of the main view.

Backup utilities including Time Machine normally make a snapshot with each backup, and retain them for 24 hours, following which they’re automatically deleted. As snapshots can’t exclude folders in the way that Time Machine can in its backups, if you’ve been working with a couple of 100 GB VMs then they will be retained in snapshots even though you probably exclude them from being backed up.

Once you’re happy that free space isn’t being retained in snapshots, use a disk mapping utility like DaisyDisk or GrandPerspective to hunt down other large files and folders that you may not need. One reader here recently discovered that their iOS and iPadOS backups had taken over more than half the space on their Mac’s SSD.

Wait a day or two after upgrading

Installing a macOS upgrade also changes files on your Data volume, and may retain temporary support files. These are normally cleaned up in the next 24 hours, and you may be able to encourage that by starting your Mac up in Safe mode, leaving it a couple of minutes, then restarting it in normal user mode.

By a couple of days after the upgrade, your Mac should have returned to normal use of storage. If it hasn’t, check snapshots and go hunt that missing space.

One seemingly widespread complaint about recent versions of macOS has been slow launch times of notarized apps even after they have cleared quarantine in their first run. Debate on the cause of this was vigorous in April and May, but was overtaken by Apple’s announcement of macOS 26 Tahoe. I therefore postponed further work on app launch and Gatekeeper until after Tahoe’s release.

This proved worthwhile, as soon after the first beta-release, it was suggested that Tahoe would accelerate the first launch of notarized apps by exempting them from a malware scan, although I have been unable to confirm that from Apple’s published information. That would make good sense: if an app’s CDHashes verify and match those of its notarization ticket, and no known malware was found when it was notarized, then it’s not plausible for it to contain malicious content since notarization was performed. This article considers what has changed in Gatekeeper in macOS 26.0.

Although Apple hasn’t yet updated it for macOS 26, its Platform Security Guide explains what Gatekeeper does in macOS Sequoia. For an app, plug-in or an installer package downloaded from outside the App Store and opened on a Mac, Gatekeeper verifies the software:

• is from an identified developer, in signature checks;
• is notarised by Apple to be free of known malicious content, in notarization ticket checks;
• hasn’t been altered, in CDHash verification;
• doesn’t contain known malicious content the first time it’s opened, regardless of how it arrived on the Mac, in a first run XProtect scan.

To assess this, I have used Calibre version 8.11.0 installed in a macOS virtual machine running on a Mac mini M4 Pro. Calibre is a large app at just over 1 GB with many components to be checked. This version has 82 items in its Frameworks folder, 20 executables in its MacOS folder, and 25 dylibs in its Plugins folder, totalling 113 dylibs and others that need to be checked.

Two VMs were prepared, one with macOS 15.7 Sequoia installed, the other with macOS 26.0 Tahoe. Both were run with 5 CPU cores, 16 GB memory, 100 GB disk, and bridged networking.

Calibre was launched three times in Tahoe, first when freshly installed and still in quarantine. Following that, the VM was shut down, started up 4 hours later and Calibre was run a second time. The VM was shut down again, and started up two days later for a third run. Log extracts were collected within a minute using LogUI.

Tahoe: First run in quarantine

This proceeded similarly to first run in Sequoia, with the exception of XProtect malware scanning. Soon after com.apple.syspolicy.exec reported that a GK (Gatekeeper) process assessment was starting, it wrote the log entry
Skipping up front XProtect scan on: PST: (path: f0970f7f0ab1ff9f), (team: NTY7FVCEKP), (id: (null)), (bundle_id: (null))
That was reiterated later, shortly before the outcome of the GK evaluation
Skipping XProtect scan on seen software: PST: (path: f0970f7f0ab1ff9f), (team: NTY7FVCEKP), (id: (null)), (bundle_id: (null))
There were no other log entries that suggested an XProtect malware scan had been attempted.

As is normal in the first run, notarization was checked using CloudKit, there was abundant evidence of CDHash verification, the user was prompted for their approval, and once that was complete the code was allowed to proceed.

Despite the lack of an XProtect scan, launch was as long as previous first runs in recent versions of macOS, taking 10.4 seconds from the second click to launch the app, to display of the prompt for user approval. During that period, a standard progress dialog was displayed. Entries in the log consisted of about 13,000 messages of SecKeyVerifySignature from syspolicyd and trustd, with repeated errors of
SecError com.apple.securityd Malformed anchor records, not an array

Tahoe: Subsequent runs

The second and third runs, out of quarantine, were almost identical in the log, and similar to those in macOS 15.7 (below). com.apple.syspolicy.exec announced early that the code had already been evaluated, and those previous results would be used. Provenance data was found, and the evaluation completed without any CloudKit check of notarization. Times from the second click to launch the app, to loading of the app’s preferences were 0.64 and 0.66 seconds.

At various times, the kernel reported that it was considering a malware scan on one of the executables being checked, for example
ASP: considering malware scan (activeRulesVersion: 11716915239283693719 lastScanVersion: 0 chgtime: 1758884893 lastFileScanTime: 1758884893 threshold: 1758884893 pid: 949 info_path: /Applications/calibre.app/Contents/MacOS/calibre proc_path: /Applications/calibre.app/Contents/MacOS/calibre isNewerThanScan: 0 needsVersionScan: 0 is_time_eval_exempt: 0 is_scan_version_exempt: 1
Those appear new to macOS 26, and haven’t been seen in any log records from macOS 15.7 or earlier. Executables cited in those messages extended beyond components of Calibre to others that happened to be running at the time, but none was followed by any report of whether a scan was performed as a result.

Although they didn’t delay app launch, at the same time amfid entered the path of the main executable and 112 dylibs and others to check each individually. For the dylibs and others, each was accompanied by a report from the kernel of
AMFI: constraint violation [dylib path] has entitlements but is not a main binary
Those took a period of approximately 3 seconds in each of the two runs.

Sequoia: 2nd and 3rd runs

These were remarkably similar, and in many parts identical, to those in Tahoe, except that there were no messages reporting consideration of malware scans. Times from the second click to launch the app, to loading of the app’s preferences were slightly quicker than Tahoe, at 0.59 and 0.59 seconds. Concurrent time to iterate through all the executable components was also shorter at 2.6 seconds, with identical reports of constraint violations.

Conclusions

• macOS 26.0 Tahoe does now skip reported XProtect malware scans when a notarized app is run for the first time, when in quarantine.
• Despite that, first run checks undertaken in Tahoe can still take significantly longer than in subsequent runs.
• This is the result of a vast number of SecKeyVerifySignature entries written during checks on executables.
• Tahoe also considers explicitly whether to perform malware scans on other processes being run, although none were undertaken. These are new in Tahoe.

From this evidence, I’m not convinced of any significant improvement in launch times. Please let me know whether you think that Tahoe has improved the speed of your app launches.

Previous articles:
Why some apps launch very slowly
Gone to launch

Apple has just released macOS 26.0.1 Tahoe, which fixes the problem upgrading to 26.0 on Mac Studio M3 Ultra models, and apparently fixes other urgent bugs.

For Apple silicon, the update is a 1.76 GB download.

Tahoe 26.0.1 fixes a single vulnerability, although Apple doesn’t report that it’s already being exploited. The same is also fixed in Sequoia 15.7.1, and in Sonoma 14.8.1.

macOS 26.0.1 has build number of 25A362, Safari version 26.0.1 (21622.1.22.11.15), and a Darwin Kernel version of 25.0.0. There has been no change in iBoot firmware, which remains at 13822.1.2.

As Apple hasn’t been forthcoming about what else has changed, here’s my list:

• Passwords app has gone from version 2.0 to 2.0.1, suggesting it has at least one significant bug fixed.
• AppKit framework has had an increment in build number, also suggesting bug fixes.
• CoreText framework likewise, with bug fixes for a higher build number, possibly related to the fixed vulnerability in font handling.
• Security framework has a substantial increase in build number, implying bug fixes there as well.

Otherwise, remarkably little has changed.

Updated 1910 29 September 2025.

Last week’s outstanding news was the discovery of a potential treatment for Huntington’s disease, that killed Woodie Guthrie at the age of 55, a tragedy I learned of from his son Arlo’s movie Alice’s Restaurant (1969).

That treatment is so complex that even James Gallagher’s diagrammatic account doesn’t do it justice, but it provides a much clearer picture than some of the treatment offered for our Macs. Although in a different league, our novel treatment of the week is Device Recovery Assistant, as I showed here on Friday. It’s sufficiently new that Apple hasn’t quite gone firm on what to call it. Its sole account refers to it as Recovery Assistant, in accordance with the menu command used to open the app in Recovery mode. But when it’s running, it claims to be Device Recovery Assistant, which sounds like it might also be good for your iPhone or iPad, but isn’t. That’s a similar feature added to iOS and iPadOS 26, as explained here.

I’m still a little wary of magic healing tools in Recovery mode. The first is there even now, waiting to catch those who’ve taken AI a little too seriously, and think running repairHomePermissions might be a good idea. Whatever you do, please don’t try this one at home, as its effects can be devastating. I now only run it in a disposable virtual machine, as reversing its changes would be so time-consuming.

In Recovery mode, typing repairHomePermissions into Terminal launches a GUI app to ‘repair permissions’ in a selected Home folder in the Data volume. Far from repairing them, each time I have tried this it locks me out of every folder in my Home folder and wreaks havoc elsewhere. Yet somehow this historical remnant has been left behind in Recovery mode to catch the unwary.

(Device) Recovery Assistant doesn’t appear to do anything so disastrous, but Apple is completely opaque as to what it actually does. Even its description for macOS 26 beta testing used the same words, “Recovery Assistant is a new way to recover your device if it doesn’t start up normally. It can look for problems and attempt to resolve them if found.”

Just what “issues” can it discover, and how might it attempt to “resolve” them? One thing I can report is that it doesn’t attempt to repair the damage done by repairHomePermissions, and doesn’t see anything wrong with a user not having permissions to access their own folders. Maybe it isn’t that smart yet.

One small clue given by Apple is that it can leave your iCloud connection in need of a further recovery process run when back in normal user mode. Once again, though, information is lacking as to what that does, and why it might be needed.

Of course, if your Mac does have an appropriate problem that prevents it from starting up normally, and it instead puts itself into Recovery Assistant, you have little option but to give it a whirl and hope that it fixes whatever was causing the problem. But why might you want to run Recovery Assistant voluntarily from Recovery mode? Is this something worth doing for specific reasons, or is it just a universal panacea?

With Apple silicon Macs, we’re running out of panaceas. If you don’t know of a specific fix for a problem, most of the old tricks such as resetting NVRAM and SMC, repairing permissions, installing the Combo updater, and re-installing macOS have either become impossible or demonstrably futile. We’re currently left with the innocuous procedure of starting up in Safe mode, and quickly run out of ideas after that.

I’m not suggesting for a moment that Recovery Assistant is a placebo, but until we know more about it, neither can it be a new panacea.

If your Mac starts up in this new Recovery Assistant, or you use it manually in Recovery mode, please let us know what happened and whether it did resolve your problem.

One of the features new to macOS 26 Tahoe that you won’t find in Apple’s list is an enhancement to Recovery mode, in Device Recovery Assistant (DRA). This article explains what it is and how to use it.

When you put your Mac into Recovery mode from Tahoe, you should notice that Apple has changed the disk icon there, to one intended to more closely resemble an SSD rather than a hard drive, although of course it’s still quaintly named Macintosh HD.

If your Mac (upgraded to Tahoe) has problems starting up correctly, it should now automatically restart and open DRA. You can also enter it manually by starting up in Recovery, passing through to Options, and using the Recovery Assistant command in the Utilities menu there, where its app menu identifies itself as Device Recovery Assistant. DRA requires an internet connection to function. If you’re asked to choose a connection, opt for a Wi-Fi network if possible.

Distinctive to DRA’s opening window is its first aid symbol ⊕. Click on the Continue button to move on.

The next window invites you to send data to Apple for diagnostic purposes. Make your choice as you move on.

If your startup Data volume is protected by FileVault, you’ll then be prompted for the password to unlock it. Once that has been provided, DRA attempts to perform a ‘recovery’.

At the end of that, you should see one of three outcomes:

• no problems were found, and you can restart your Mac back into normal mode;
• problems were found and repaired successfully, so you can restart your Mac back into normal mode;
• problems were found but aren’t fully repaired.

When your Mac restarts, it may show a notification that you need to recover iCloud data. If so, open System Settings and you should see a new item in its sidebar to Recover iCloud Data.

If DRA doesn’t fix your Mac, you’ll almost certainly need to start up in Recovery and try to fix it there. You can also quit DRA to return to Recovery if you wish.

Apple’s support note doesn’t give any further information about what DRA does.

No sooner have we recovered from upgrading and updating macOS to 26.0/15.7/14.8 than Apple has released the next round of betas. This article looks at what’s in store for us over the coming year, as far as macOS is concerned.

With pandemics hopefully behind us, Apple’s planned OS updates have settled into a more regular pattern. Release dates when Sonoma was the current version of macOS (2023-24) were:

• 14.0 – 26 September
• 14.1 – 25 October
• 14.2 – 11 December
• 14.3 – 22 January
• 14.4 – 07 March
• 14.5 – 13 May
• 14.6 – 29 July
• 14.7 – 16 September.

Over the last year (2024-25), Sequoia has been almost identical, allowing for the small vagaries resulting from our calendar:

• 15.0 – 16 September
• 15.1 – 28 October
• 15.2 – 11 December
• 15.3 – 27 January
• 15.4 – 31 March
• 15.5 – 12 May
• 15.6 – 29 July
• 15.7 – 15 September.

If Tahoe follows the same pattern, you can expect releases to occur on the following dates:

• 26.0 – 15 September 2025
• 26.1 – 27 October 2025
• 26.2 – 15 December 2025
• 26.3 – 26 January 2026
• 26.4 – 30 March 2026
• 26.5 – 11 May 2026
• 26.6 – 27 July 2026
• 26.7 – 14 September 2026.

If you’d like a week’s notice of scheduled updates, watch Apple’s Developer Releases newsfeed at feed://developer.apple.com/news/releases/rss/releases.rss for Release Candidates. For minor versions, those are normally released about a week before the intended final release, so RCs seen on 20 or 21 October are likely to be followed by the public release on about 27 October.

Those can of course slip a few days or even a week if there are serious problems remaining with a release candidate, and some may be rescheduled to coincide with hardware announcements. These are also the ‘minor’ version updates, and Apple is likely to intercalate ‘patch’ releases to fix any serious bugs or urgent security vulnerabilities. Those almost never go through beta-testing or release candidacy.

For those staying with Sequoia or Sonoma for the time being, those security updates are most likely on the same dates as those for Tahoe.

Finally, a reminder for those whose Macs are still running macOS 13 Ventura: the final security update to 13.7.8 was released on 20 August this year, and Ventura is no longer officially supported by Apple. If your Mac can run Sonoma or later, and you want continuing security updates, then you’ll need to upgrade it to Sonoma 14.8 or later.

It has been barely a year since XProtect changed from stalwart to bogeyman. Over the course of dozens of updates through to macOS Sonoma, if there was one security data update you could rely on, it was XProtectPlistConfigData containing the many rules for XProtect. They guarded us through the dangerous days of Flash Player, the perils of ransomware, and a succession of stealers.

Then in Sequoia that changed, and XProtect’s data became stored in two locations, each with its own update method. The traditional location in CoreServices continued to be updated through softwareupdated, while the copy in the new location in /var/protected/xprotect has been updated by XProtectUpdateService over a connection to iCloud.

With both locations in play, XProtect updates have become more complicated. Some updates only came for one location, such as versions 5273 and 5275 that were released only to Sequoia’s new location. To help us manage XProtect in its new location, Apple provided a command tool, xprotect. That can check which version is available via iCloud, and update that when the local copy was no longer the latest.

One valuable feature was that it could also use a copy in the traditional location to update the new location, in the event that version was more recent than that available from iCloud, but most recently that has been disabled. Now, if a Mac running Sequoia or Tahoe has successfully updated its traditional location but not the copy in the new location, the user is unable to do anything to rectify that, and has to wait until that update is made available from iCloud. Sometimes both are provided at the same time, but it’s also common for iCloud to lag the traditional version by an hour or more, sometimes even longer.

Last week, with the update to XProtect 5315, the day after many of us were preoccupied with macOS updates, something even stranger happened. At around 18:00 GMT on 16 September, softwareupdated became able to download and install that new version into its traditional location, enabling macOS versions up to Sonoma to update successfully. But no such update was made available via iCloud for Sequoia or newly upgraded Tahoe systems, not for another 24 hours. Over that period attempts to obtain or convert the update using xprotect update were unsuccessful.

However, some hours after the traditional update was installed by those who had upgraded to Tahoe, XProtect’s new location was silently updated to 5315. Its version number had gone bump in the night. But if the xprotect command tool couldn’t accomplish that for the user, how could macOS? Were these silent updates coming by telepathy or radio waves?

Although there was no record in any of the usual places, such as Installations in System Information, or even found by my app SystHist, the xprotect version command disclosed that my Mac mini had updated XProtect’s new location at 06:46 GMT on the morning of 17 September, enabling me to hunt that event down in the log.

That update had been accomplished by a background check scheduled and dispatched by DAS-CTS (I have corrected times here to GMT):
2025-09-17 06:46:42.615072 com.apple.duetactivityscheduler REQUESTING START: 0:com.apple.security.syspolicy.xprotect-update:7874AD

This in turn fired up XProtectUpdateService
2025-09-17 06:46:42.695517 com.apple.xprotect Connecting to XProtectUpdateService
2025-09-17 06:46:42.744182 com.apple.security.XProtectFramework.XProtectUpdateService XProtectUpdateService booting
2025-09-17 06:46:43.157255 com.apple.security.XProtectFramework.XProtectUpdateService Attempting to apply update: [private]
2025-09-17 06:46:43.191178 com.apple.security.XProtectFramework.XProtectUpdateService Update completed. Activated update [private]

So the XProtect update had been completed and activated at 06:46 that morning. But how, given that iCloud was still only offering the old version?
2025-09-17 06:46:43.193159 com.apple.syspolicy.activities Finished Xprotect update in 496.4100122451782 ms: Error Domain=XProtectUpdateError Code=2 "Activated update LocalUpdate[5315]" UserInfo={NSLocalizedDescription=Activated update LocalUpdate[5315]}
2025-09-17 06:46:43.193285 com.apple.syspolicy Sent CloudTelemetry event: Xprotectupdateresult

“Activated update LocalUpdate” can only mean one thing, that XProtectUpdateService did what xprotect update used to do, and used the copy of XProtect 5315 in the traditional location to update the new location, taking just under half a second. In addition, com.apple.syspolicy had sent news of that event to Apple via iCloud.

That didn’t work for my old iMac Pro, still running Sequoia, though, which had to wait for the iCloud version of XProtect data to be updated, and wasn’t using version 5315 until 20:17 GMT on 17 September, over 26 hours after its initial release.

Prior to Sequoia, all supported and many unsupported versions of macOS got the same XProtect updates, available immediately they were released through Apple’s software update servers. Just over a year later,

• Macs running Sonoma and unsupported versions of macOS could be updated as soon as the softwareupdated update became available, in the traditional way;
• Macs running Sequoia could only be updated 24 hours later, when the iCloud update was made available;
• Macs running Tahoe could have been updated at any time after the traditional update had been installed, until the update was finally made available through iCloud.

I’m so looking forward to the time when I don’t need to use SilentKnight, the xprotect command and my log browser LogUI to track XProtect updates, and when those become timely again.