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.

macOS 26 Tahoe has many smaller enhancements to make life easier. Among them is a novel way of customising folder icons, as explained here.

Traditional custom folder icons

One of the most ancient features in macOS is adding a different icon to a file or folder, by pasting it into the top left of the Get Info dialog for that item. I have detailed how to do that, and how it works, in this article. While that still works, it has some significant limitations and is fiddly.

Another disappointing behaviour in previous macOS is the effect of adding coloured Finder tags to folders, which don’t change the colour of the folder as displayed.

Tahoe custom folders

macOS 26 changes the behaviour of folder icons in three ways:

• Default folder colour is now set in Appearance settings. In most cases, that will be left to use the Theme colour.
• Applying a coloured Finder tag to a folder now changes the colour of that folder, as well as displaying a coloured dot.
• Folders can be customised additionally using the Customise Folder… command in the Finder’s File or contextual menu.

The last of those merits further attention, and an explanation of how it works.

Customising folders

Rather than adding an arbitrary icon to a folder, Tahoe’s custom folders consist of a traditional folder icon with a symbol or emoji superimposed. These are selected from a wide range of vector graphic symbols drawn from Apple’s huge SF Symbols collection, or the standard range of Unicode emoji.

Symbols appear embossed with little difference in tone, so aren’t easy to distinguish unless the folder icon is quite large. This isn’t suitable for use in the Finder’s Column or List views.

The familiar range of emoji is usually clearer and readily distinguishable in most sizes.

Adding a coloured Finder tag to a customised folder makes it even more distinctive, and increases colour contrast with the emoji.

Not only does this look good, but it solves the problems associated with old-style custom folder icons. Copy that folder anywhere within your Mac, and its new look goes with it. Move it into iCloud Drive, and it goes there too. Although Macs and devices running older versions don’t show the custom folder in its full glory, those running OS 26 do. Yes, open Files on your iPhone and you’ll see the custom icon there too.

The only shortcoming that I can find is that, while you can search for specific Finder tags in Spotlight, you can’t search for the symbol or emoji displayed on the folder icon. There is a search attribute Custom Icon, but these folders aren’t considered to have that attribute.

How it works

Tahoe’s custom folders rely on a combination of two extended attributes (xattrs) attached to the folder:

• com.apple.FinderInfo, 32 bytes that is also used in other Finder settings;
• com.apple.icon.folder, new to Tahoe and containing details of the symbol or emoji to be displayed.

Both have to be attached to the folder for it to be displayed correctly.

com.apple.icon.folder is of particular interest, as it has an S flag, and is itself usually displayed as com.apple.icon.folder#S. The S tells macOS that xattr should be preserved during syncing with services such as iCloud Drive. A full list of xattr flags is given in the Appendix. This xattr contains a Unicode string such as
{"emoji":"🔍"}
for an emoji, or
{"sym":"person.crop.circle")
for one of the vector graphics in SF Symbols. The first is self-explanatory, while the second uses the name of that symbol in the SF Symbols library. This currently only supports a subset of the whole library, and my attempts to get it to use others from SF Symbols have so far failed.

Conclusion

macOS has succeeded because of its attention to detail. Tahoe’s new custom folders are an excellent example. Enjoy them!

Postscript

For those who want to disable Tahoe’s default of colouring tagged folders according to one of the tag colours, I’ve now discovered that you can disable that in the control Tint folder based on tags at the foot of the Tags view in Finder’s Settings.

Appendix: Xattr flags

Flags can be upper or lower case letters C, N, P, S or B, and invariably follow the # separator, which is presumably otherwise forbidden from use in a xattr’s name. Upper case sets or enables that property, while lower case clears or disables that property. There are currently five properties:

• C: XATTR_FLAG_CONTENT_DEPENDENT, which ties the flag and the file contents, so the xattr is rewritten when the file data changes. This is normally used for checksums and hashes, text encoding, and position information. The xattr is preserved for copy and share, but not in a safe save.
• P: XATTR_FLAG_NO_EXPORT, which doesn’t export or share the xattr, but normally preserves it during copying.
• N: XATTR_FLAG_NEVER_PRESERVE, which ensures the xattr is never copied, even when copying the file.
• S: XATTR_FLAG_SYNCABLE, which ensures the xattr is preserved during syncing with services such as iCloud Drive. Default behaviour is for xattrs to be stripped during syncing, to minimise the amount of data to be transferred, but this will override that.
• B: XATTR_FLAG_ONLY_BACKUP, which keeps the xattr only in backups, including Time Machine (added recently).

These operate within another general restriction of xattrs: their name cannot exceed a maximum of 127 UTF-8 characters.

If you have a Mac Studio M3 Ultra and want to upgrade it to run macOS 26.0 Tahoe, then I’m afraid you’re going to have wait for Apple to build a new release that will install on your Mac.

I’m very grateful to Ken who has tried unsuccessfully to upgrade from 15.7 to 26.0. There are plenty of others reporting exactly the same: the upgrade goes well until towards the end, then aborts and the Mac is restarted back into 15.7. The problem seems to originate from an error in its neural engine driver.

Having just taken a look through a comparison between kernel extensions shipped with macOS 15.6 and 26.0, there are several Apple silicon hardware kexts that seem to have gone missing in 26.0, although whether that’s the cause only Apple’s engineers should know.

Apple is advising all those affected to put their Tahoe upgrade on pause until it releases a new build that does fully support the M3 Ultra. Until then, 15.7 is the limit for Apple’s most powerful and expensive Macs yet.

Among the many new features Apple lists for macOS 26 Tahoe is a new disk image format, Apple Sparse Image Format or ASIF. In that list it appears as a feature for virtualisation, and is explained as: “Create virtualized disk images with a virtualized file format that can be formatted to any kind of file system.”

Yet in the help pages for Disk Utility, the claim goes further: “A modern sparse read/write image. The space it uses on your disk is proportional to the data it contains, making it efficient and general-purpose.” In Apple’s developer documentation for virtualisation, there’s more detail still:
“Apple Sparse Image Format (ASIF) files transfer more efficiently between hosts or disks because their intrinsic structure doesn’t depend on the host file system’s capabilities. The size the ASIF file takes on the file system is proportional to the actual data stored in the disk image.”

This article considers whether this new ASIF disk image format, as implemented in macOS 26.0, is more suitable for general purposes than the other two leading contenders. Should you use ASIF instead of sparse bundle or read-write (UDRW) disk images?

Testing

To assess the performance of these disk images, read and write speeds were measured in macOS 26.0 Tahoe running on a Mac mini M4 Pro with a 2 TB internal SSD. Each disk image was created using Disk Utility, with a single APFS volume in a disk of maximum size 100 GB stored on the internal SSD, with FileVault enabled. Each format was tested using plain APFS, and separately using APFS Encrypted with 256-bit AES.

When each disk image was created and mounted, a single folder was created in it, and the image unmounted. The disk image was mounted again, and a standard write test performed into the folder using Stibium. That writes in random order a total of 160 files ranging in size from 2 MB to 2 GB, totalling 53 GB. Once the write speed had been measured the image was unmounted again and Stibium closed. For the read test the image was mounted again and all 160 files in the test folder were read in random order using Stibium to measure their speed.

Results

Read and write performance for each of the tests are shown in the table, where results are ranked by read speed.

All three disk image formats achieve similar read and write speeds with unencrypted images. There were substantial differences in performance, though, when encryption was used. With encryption, the sparse bundle was faster than both RAW (Read-Write, UDRW) and ASIF. The new format read at exactly half the speed of a sparse bundle, and at 57% of write speed. ASIF with APFS Encrypted was the slowest of the seven tests in both read and write.

Differences in the size on disk of images were small. Empty disks were smallest for sparse bundles and ASIF, and following deletion of all test files, ASIF returned to the smallest size, indicating that it’s the most space-efficient.

Why use ASIF?

If ASIF doesn’t perform any better than existing formats, and any gains in space on disk are small, when and why should you use the new format? To appreciate its strengths, you need to consider how the other two formats work in terms of the file system they’re hosted on, and the file system they run internally.

A sparse bundle stores its contents on many band files inside its bundle. When its internal file system is able to compact free space, used space can be compacted into a minimum number of bundles, and those containing just free space can be deleted. Thus the total size of its bundle will vary according to the space required to store its contents. Coupled with efficient read and write support this results in good space efficiency and performance.

When a Raw Read-Write disk image has an internal file system that is capable of Trimming free space, as APFS and HFS+ can, that process will compact free space within the image. When the image is stored on a host file system that supports sparse file format, as APFS does, the space in the image that is free can be skipped, resulting in a space-efficient sparse file. However, a host file system like HFS+ that doesn’t offer a sparse file format is unable to take advantage of that.

ASIF is claimed to be able to accomplish similar economy of storage space without relying on the host file system’s special file formats, making it more suitable when the conditions required by sparse bundles and Raw Read-Write disk images aren’t available.

Although this new feature has been announced for virtualisation, it’s most probably only going to be useful for those running VMs stored on file systems other than APFS. Prior to the introduction of ASIF, VMs hosted on APFS have used Raw Read-Write style storage which has benefited from sparse file format, whether they’re macOS or Linux. Where ASIF may be of greatest benefit is for VMs run from network shares or cloud services, whose host file system won’t be APFS.

Recommendations

• ASIF should be the disk image format of choice when neither sparse bundles nor Raw Read-Write images can achieve similar economy in host storage space.
• In other circumstances, where sparse bundles or Raw Read-Write images can provide space-efficient storage and full performance, they are still to be preferred.
• At present, ASIF isn’t generally a better replacement for sparse bundles or Raw Read-Write images, particularly when their internal and host file systems are APFS.
• ASIF is likely to be of greatest benefit to those running macOS or Linux virtual machines from network shares or cloud services, where the VM can’t be hosted on APFS.

Apple has just released macOS 26.0 Tahoe (build 25A354), together with security updates to Sequoia taking it to 15.7, and for Sonoma to 14.8. As expected, there are no further security updates provided for Ventura, which is now unsupported.

The upgrade to Tahoe is once again provided as an ‘update’ rather than a full Installer app. If you want to run the Installer app to upgrade, download it from the App Store rather than using Software Update. If you’re updating Sequoia or Sonoma and your Mac is capable of running Tahoe, be very careful to select the right update in Software Update.

The Tahoe upgrade weighs in at 7.7 GB for Apple silicon Macs upgrading from a recent version of Sequoia. For Intel Macs it should be 6.1 GB.

On Apple silicon Macs, iBoot is updated to version 13822.1.2. Intel Macs have their firmware updated to version 2092.0.0.0.0 (iBridge 23.16.10350.0.0,0). Safari is version 26.0 (21622.1.22.11.14). The Darwin kernel version is 25.0.0.

Security release notes are also available:

• Tahoe 26.0 lists 75 vulnerabilities fixed, none of which is reported as already being exploited.
• Sequoia 15.7 lists 34 vulnerabilities fixed.
• Sonoma 14.8 lists 38 vulnerabilities fixed.

Useful links

Prepare to upgrade macOS – what you should have done already
What should you do when an update goes wrong?
When you should use Safe Mode, and what it does
What to do when there’s something fundamentally wrong with an Apple silicon Mac
Eclectic Light software updates for Tahoe

Last updated at 1928 GMT 15 September 2025. My apologies for some previous incorrect versions, which were the result of an unintended update.

macOS 26 Tahoe’s big thing is its redesigned interface, with additional variations to appearance modes and its new Liquid Glass effects. Whether you’re installing the upgrade because of those, or in spite of them, allow me to take you on a quick tour of how you can set its interface up, and which controls do what.

There are three sets of controls:

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

That comes to a total of more than 20 combinations before factoring in icon tinting colour, so there’s no shortage of choice.

Light mode

There are three overall variations of light mode, depending on those Accessibility settings.

The starting point and default is in light mode 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 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, 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.

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.

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, 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;
• Display variations to Reduce transparency or Increase contrast, in Accessibility settings;
• Icon & widget styles, in Appearance settings, with Icon, widget & folder colour when appropriate.

Have fun!

For the last three months, since Apple released the first developer beta of macOS 26 Tahoe, I’ve been fairly busy updating my apps so they’re ready for its release. This quarter of the year is usually quite busy, but the changes brought by Tahoe have required more work than any version of macOS so far. This article provides checklists of every one of my apps and command tools that I believe should be compatible with macOS 26, and in most cases I have tweaked and rebuilt to ensure that.

The first problem posed by Tahoe was its rough handling of app icons that it didn’t like, because they deviated from its standard square with rounded corners. This isn’t something to be ignored, as if you can’t recognise apps in the Dock, how can you use them?

Here are two icons for the same app viewed in Tahoe. The left one uses a traditional AppIcon.icns icon image, while that on the right is the same circular PNG that has been applied using Icon Composer and added as a .icon file for Tahoe. So every supported app has required a new icon to be designed for it, and incorporated into a new build. Here’s part of my beauty parade.

Unfortunately, the moment you rebuild an app with its new icon, its whole interface is also rebuilt to Tahoe’s new standards. Those not only include all those infernal rectangles with rounded corners, but many controls and elements are larger than in Sequoia. While this is implemented intelligently so as not to upset layouts when running in older versions of macOS, Tahoe’s new look can wreak havoc with windows and dialogs.

This demo, Mallyshag, looks the same in Sequoia above, but has become a mess in Tahoe (below) because of those changed control dimensions.

Those three buttons are significantly wider, so now overlap one another and are wider than the text box below. They need a careful overhaul before they’re ready for Tahoe. Conversion can also have unexpected side-effects: for example, I’ve had some selectable text fields changed to be editable as well.

Here are the 31 updated apps that I have equipped with a new icon and adjusted their interface for Tahoe:

• Alifix version 1.4
• Apfelstrudel version 1.6
• Cirrus version 1.16
• Cormorant version 1.6
• DelightEd version 2.4
• Dintch version 1.8
• DropSum version 1.2
• Dystextia version 1.9
• Fintch version 1.4
• LogUI version 1 build 70
• Metamer version 1.6
• Mints version 1.21
• Nalaprop version 1.4
• Podofyllin version 1.4
• Precize version 1.16
• Revisionist version 1.10
• SilentKnight version 2.12
• Skint and SkintM version 1.09
• Sparsity version 1.4
• Spotcord version 1.0
• SpotTest version 1.1
• Spundle version 1.9
• Stibium version 1.2
• SystHist version 1.21
• The Time Machine Mechanic (T2M2) version 2.03
• Ulbow version 1.11
• UTIutility version 1.4
• Versatility version 1.1
• xattred version 1.6
• XProCheck version 1.7

There are also my three macOS virtualisers for Apple silicon Macs, which require more than an overhaul. However, I regularly use these in Tahoe and believe they’re fully compatible, even if their icons will disappoint:

• Viable version 1.0.12 (b12)
• ViableS version 1.0.12 (b12)
• Vimy version 0.7 (fourth beta)

I intend working on those in the coming months, to update them and cast them into fresh interfaces.

I have also tested five of my command tools, and believe they too are fully compatible with Tahoe:

• alisma version 4
• blowhole version 11
• cintch version 3
• cmpxat version 4
• unorml version 5

At least they don’t have custom icons.

So that was the summer of 2025, in more nutshells that I had expected. I hope you still find these useful, and will report any problems you encounter.

With macOS 26 Tahoe due to be released on Monday 15 September, I’m delighted to provide version 1.09 of my simple security checker Skint and its menu bar sibling SkintM.

These new versions should recognise Tahoe correctly, and check its version against an updated database.

Skint and SkintM versions 1.09 are now available from here: skint109
from Downloads above, from their Product Page, and via their auto-update mechanism.

Note that, because of the way it (mis)handles Dock icons, Skint might prove to be one of the few apps you run in Tahoe that doesn’t conform to its standard icon format. I also resisted the temptation to make these version 26.

Apple has announced that macOS 26 Tahoe will be released on Monday 15 September, slightly earlier than had been speculated. Even if you’re not intending to upgrade to that, you might instead be looking at moving from Sonoma to Sequoia, or perhaps dragging your feet and considering Sonoma as it enters its final year of support. This article considers what you should do when preparing to upgrade macOS.

One of the surgeons I worked for in my first internship in hospital taught me an important lesson in life: when considering the outcome of anything that could go wrong, assume that it will go wrong, and prepare for that. When it actually works out better than you planned for, you can enjoy your success.

Emergencies

The worst case is that your Mac dies during the upgrade. Although that’s also the least likely, you need to think through your disaster plan. I ensure that all my most essential files and data are shared or copied up to iCloud so that I could get by for a day or three without that Mac. A recent full backup is also essential: if your Mac needs to go away to be resuscitated, one way or another that’s what you’ll be restoring from.

Upgrades do bring a tiny but significant risk of bricking your Mac in a way that only a full Restore will recover it. Although this can apply to Intel Macs with T2 chips if a T2 firmware update goes wrong, this is more the preserve of Apple silicon Macs. I’ve recently stepped through your options with full details here. Your first DFU Restore is daunting, but once you’ve done one, you’ll realise that they’re not that challenging if you have the right cable and DFU port. When you’ve restored firmware and macOS, you’ll then be restoring from that last backup, emphasising its importance.

In the days before the SSV, when there was only one boot volume and that could so readily be corrupted during upgrades, you also needed to have an emergency toolkit handy to repair an upgrade that went wrong. These days, the whole of the System in the SSV is either perfect, or macOS has to be reinstalled. Minor glitches are almost invariably corrected by restarting after the upgrade has completed, or starting up in Safe mode (remember on Apple silicon Macs that’s performed from Recovery).

Reverting macOS

The other possibility that you should plan for is beating a hasty retreat and reverting to an older version of macOS. Provided that you’re fully aware of the changes to the macOS interface brought in Tahoe, I think this is less likely for those upgrading from Sequoia, but if you’re skipping a version or two you could still find yourself unable to use a vital peripheral or one of your key apps, leaving you with reversion as your only option.

I’m sometimes asked by eternal optimists whether you can revert to your previous macOS simply by using its SSV snapshot. Sadly, snapshots are of no help: the only way back is to wipe and reinstall that macOS.

On Intel Macs, you’ll need to do this when booted from an external bootable installer, which doesn’t have to be on a USB ‘thumb’ drive, but does still require its own HFS+ volume to work. Apple explains this here, and Mr. Macintosh has links to all available installer apps.

Although you can do that with an Apple silicon Mac, if you have a second Mac and the right USB-C cable, it’s usually quicker and simpler to do this by restoring from the appropriate IPSW file in DFU mode, then restoring your files from your latest backup, as explained here. This is particularly valuable, as it also restores the original firmware, which may be the root of your problems. Unfortunately, that doesn’t seem possible with Intel Macs. Once their firmware has been upgraded, the user isn’t able to downgrade it.

Checklist

• Check you’re prepared to use your disaster plan if needed.
• Consider sharing and copying to iCloud to help you use another Mac or device temporarily.
• Make a full backup immediately before starting the upgrade.
• Restart, or start up in Safe mode, if the upgrade leaves your Mac with problems.
• Reverting to an older macOS isn’t trivial, and will require you to restore from your backup.
• Revert an Intel Mac using a bootable external installer.
• Consider reverting an Apple silicon Mac by restoring it in DFU mode, using an older IPSW.

Whatever you choose to do, I wish you success, and hope that your preparations prove completely unnecessary.

Unlike Apple’s bundled apps in macOS, the great majority of third-party software needs to run on more than just the latest version of macOS. This is a challenge when there’s a major redesign of the interface, as there is in macOS Tahoe. While OS 26 may bring greater consistency across platforms, it’s also important to developers and users that it doesn’t sacrifice consistency between, say, Sequoia and Tahoe.

As I showed recently in my simple little utility DropSum, at times the appearance of windows can be very different between macOS 15 Sequoia and 26 Tahoe. DropSum uses AppKit rather than SwiftUI, and is a little unusual in applying colour to its window. This is used in a popular mechanism to indicate when that window is ready to receive a file being held over it, by changing the view colour from systemOrange to systemGreen. As that coloured view extends over the controls in the window, I have had to be careful to ensure those controls remain readable in both appearance modes, with the Reduce transparency and Increase contrast settings in Accessibility settings, and across recent versions of macOS. That hasn’t proved easy, so what you see below appears to be the best compromise I can achieve. DropSum doesn’t alter its settings or behaviour between different versions of macOS, instead relies on the host API’s appearance modes and Accessibility settings.

Although I have confirmed the observations below on individual systems, to make comparison easier here each screenshot shows two DropSum windows. The upper is running in a Tahoe beta 7 VM (where the window title is left-aligned), and the lower in Sequoia 15.6.1 on the host (where the window title is centred).

Light mode

In both light appearance modes, all boxed text is displayed in black on a white background, making their contents and controls clear. There are marked differences in the hues seen, though, with both systemOrange and systemIndigo (chosen for better contrast in labels) being more intense in Tahoe than Sequoia. As expected, Tahoe’s controls are slightly larger, and the corners of all four text boxes are rounded rather than square.

Reducing transparency made little difference in either rendering, merely whitening the window title bar.

Increasing contrast changes the intensity of some colours. In Sequoia, systemOrange is lightened, and in both windows the traffic light buttons at the top left, and the Clear button, are darkened. Otherwise the most obvious effect is the outlining of all components, including each of the controls.

Apps built to support macOS 26 thus appear consistent between macOS 15 and 26 when used in light mode.

Dark mode

Most apparent here are the contrasting effects of dark mode on the background of the four text boxes. In Sequoia, their background is the systemOrange of the coloured view, but in Tahoe it’s black. The latter makes the text contents more readable, while unselected text in Sequoia is more difficult to read.

Increasing contrast has different effects on colours when in dark mode. In Sequoia all colours including the systemOrange view become slightly lighter, whereas in Tahoe the contrast of some is enhanced, with black becoming blacker and white whiter, but there’s little discernible change in systemOrange, which remains significantly more intense than in Sequoia. systemIndigo is rendered lighter though, making it more difficult to read against the systemOrange background.

Reduce transparency

Apple describes this effect as replacing “the transparent effect used on some backgrounds in macOS with a solid background to improve contrast and readability.” In both Sequoia and Tahoe, and in both appearance modes, the only effect observed is a lightening of the window title bar, as the rest of the window is already opaque.

Increase contrast

Apple describes this as increasing “the contrast of items on the screen (such as borders around buttons or boxes) without changing the contrast of the screen itself.” Although the borders are the most prominent effect in both versions of macOS and both appearance modes, there are also colour changes that aren’t consistent between Sequoia and Tahoe.

Conclusions

• Appearance modes in Tahoe exhibit different behaviours from those in Sequoia, most markedly in dark mode. In this example, Tahoe has the effect of enhancing readability in dark mode.
• Colour rendering of systemOrange also differs between Tahoe and Sequoia.
• Reduce transparency has little effect other than making transparent views opaque.
• Increase contrast primarily adds black (light mode) or white (dark mode) borders to controls, but its small colour changes, as seen here in Tahoe, may impair readability.
• Designing an interface that behaves consistently in both macOS Tahoe and older versions of macOS is a challenge that may not always work out. Developers need to assess their app’s human interface thoroughly in multiple macOS, appearance modes and Accessibility settings.

DropSum is my simple drag-and-drop utility for checking MD5 and SHA256 hashes, and using them to compare pairs of files to see if they’re identical.

This new version brings two changes:

• Text entered in its two text boxes, where you paste hashes, is now cleaned of any spaces and hyphens, and set in lower case, before being used as a hash, although it’s not altered in the text box. This should save you having to edit what you paste there. Thanks to Panda for requesting that.
• I have tried to improve readability when in dark mode in Sequoia and earlier. Thanks to EcleX for requesting this.

That said, the window’s appearance is a compromise between what looks best in Sequoia, and that in Tahoe. To see what I mean, here’s the same app, in its new version 1.2, in two versions of macOS, both in dark mode with Reduce Transparency enabled.

In macOS Tahoe there’s strong contrast throughout, and all text is readable, as it is in light mode.

Yet in macOS Sequoia, white text in unselected text boxes is shown against its orange background, rather than grey or black.

I have a feeling we’re in for an autumn of similar visual discrepancies appearing in other apps, whether or not they’ve been built for compatibility with Tahoe.

DropSum 1.2 for Big Sur and later, including Tahoe, is now available from here: dropsum12
from Downloads above, and from its Product Page.

Its MD5 hash is 9370f006d65eb3f6f65ab97dc78ce345
and SHA256 is f898b580138dc05d273c8b7f16321ad6d6754d76ecabf1c49fcac1d32bc156e6

Enjoy!

As we near the end of Tahoe’s incubation period, and Apple’s engineers code its last fixes and tweaks ready for its launch in just a few weeks, I’d like to reflect on what macOS 26 has to offer beyond its marketing headlines.

While there are several worthwhile new features such as the Phone app, Magnifier, and live translation, there’s nothing to compare with the fundamental changes in recent versions of macOS that brought the SSV, Shortcuts, System Settings and Apple Intelligence. Instead Tahoe is overwhelmingly about its human interface.

Every new design of the Mac’s operating systems that I can recall has elicited outcry from many. Understandably, the majority almost invariably want constancy, the same Finder and app icons that we’ve become so familiar with. It’s only human. It’s also a sure route to what others will condemn as stale, as it hasn’t been refreshed for so many years.

Personally, I don’t like to see a design on my Mac. If I notice it, then it’s a distraction. I’d much prefer to have an interface as clean as the whistles of the late Classic Mac OS period: lean, purposeful and lacking in visual trickery or frippery. But I accept that, without all the adornments and animations, many today would wonder why their Mac needed a GPU. I confess that I was never a fan of the original Aqua interface either. Given that its declared goal was to “incorporate colour, depth, translucence, and complex textures into a visually appealing interface”, I wonder whether much the same could be said of Tahoe.

Perhaps the most striking feature of this redesign is its lack of contrast between elements and tools in window controls and their contents, whether its appearance is set to light or dark mode, or one of its new in-between variants. You can see this clearly in most screenshots of Tahoe, such as those posted by Apple, and as far as I can see it hasn’t improved during beta-testing. This is also universal, and isn’t confined to apps using the more novel SwiftUI, although I have to keep pinching my thigh to remind myself that SwiftUI is now six years old, only two years younger than APFS. The contrast in stability and maturity between the two couldn’t be greater.

You can of course ‘improve’ contrast by enabling Reduce Transparency in Accessibility settings, but in doing so you lose most if not all of Tahoe’s Liquid Glass effects, as they depend on the transparency you’ve just turned off.

Transparency is a good example of design being given priority over readability or content. Because the appearance of the upper layer containing controls or content depends on what is underneath, it’s down to chance whether the greyed text you’re struggling to read happens to be over a background that further reduces its contrast. In the worst case, you could find yourself having to move a window so you can read part of it clearly, not a sign of a good human interface.

My other major concern with Tahoe’s new look is that it seems not to recognise the differences between Macs, iPads and iPhones, in terms of displays, input controls, and apps. Rather than sameness, I’d much rather have consistency that recognises the difference between manipulating Xcode’s compound windows containing dense structured text on a 27-inch display, and checking a family photo filling the 6.1-inch display of an iPhone.

One of my favourite controls in macOS is the Combo Box, a versatile and elegant hybrid of the popup/dropdown/pulldown menu/button and a text entry box. I can’t recall seeing one used in iOS, as it would be clumsy and inappropriate. It’s well supported for macOS in AppKit but hasn’t yet been implemented in SwiftUI. If controls are going to be common across all Apple’s operating systems, then macOS is about to lose one of its best.

It seemed only appropriate that, in the weeks before Apple releases OS 26 across Macs and devices, Tim Cook should go to the White House to pay its corporate tribute in a block of materialised Liquid Glass mounted on pure bling. But the image that I keep thinking of in fear, is that of Elon Musk demonstrating the resilience of his Cybertruck’s window by throwing a metal ball at it, in November 2019. I just hope Tahoe’s Liquid Glass doesn’t go the same way.

We’re now into August, Apple has released the last substantial updates to macOS before the arrival of Tahoe, so where does macOS stand now?

macOS Sequoia has just had its last scheduled update to 15.6 before it’s expected to enter the first of its two years of security-only updates. The main benefits of this update are an important fix to restoring Macs in DFU mode using either the Finder or Apple Configurator, and its long list of security updates, 81 vulnerabilities in total. If you’re already running Sequoia, it’s an important update.

Sequoia is fully supported on the following Macs:

• iMac 2019, all T2 iMacs including iMac Pro from 2017
• MacBook Air 2020 and later, but not 2018 or 2019
• MacBook Pro 2018 and later (all T2 models)
• Mac mini 2018 and later
• Mac Pro 2019 and later
• all Apple silicon Macs.

macOS Sonoma is now entering its second and final year of security-only updates, and in the latest to 14.7.7 has around 50 vulnerabilities fixed. Although that’s a lot less than in 15.6, those are still important if you’re staying with Sonoma for the time being.

Sonoma is fully supported on the following Macs:

• iMac 2019
• all Intel Macs with T2 chips
• all Apple silicon Macs.

macOS Ventura has probably had the last of its security updates, although in the past Apple has sometimes released one more update in the autumn/fall. Its latest update to 13.7.7 has around 41 vulnerabilities fixed, making it essential if your Mac can’t be upgraded to Sonoma or later. If your Mac is supported by Sonoma, now is the time to plan upgrading it so that it can continue receiving security updates from September.

Tahoe

macOS Tahoe has now entered the public phase of its beta-testing, with the fourth version provided to developers. While much of the debate surrounds its Liquid Glass and new look, it does bring new features such as a Phone app to Macs. So far it appears internally stable and doesn’t look likely to be delayed for major bugs to be wrangled.

Tahoe is fully supported on the following Macs:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon Macs.

Although the first couple of versions of Tahoe presented themselves to older apps and scripts as macOS 16, since beta 3 it has been thoroughly macOS 26 regardless of how it’s asked. As this hasn’t been mentioned in Apple’s release notes, it’s unclear what it will do in the final release. If you have apps or scripts that could break when they discover the version of macOS running is 26, now is the time to send Apple feedback to make your case for it to report as version 16.

Older Macs

Open Core Legacy Patcher, OCLP, is being updated in the hope that it will be able to run macOS Tahoe on at least some unsupported models, although that probably won’t be available until the end of this year. You can follow progress here, where you’ll see some of the challenges its developers are facing. Another site worth watching is Mr. Macintosh on YouTube.

Next stop, probably in September, should be:

• macOS 26.0 Tahoe
• macOS 15.7 Sequoia
• macOS 14.8 Sonoma

if Apple remains consistent with previous numbering. Farewell to Ventura, old friend!