Apple has just released the update to bring macOS Tahoe to version 26.2, and security updates to Sequoia and Sonoma to bring them to 15.7.3 and 14.8.3 respectively. The latter two should also have associated Safari updates.
The update to 26.2 is about 3.78 GB to download to an Apple silicon Mac, and 2.5 GB for an Intel Mac. Some Macs may require larger downloads, though, with some in excess of 10 GB.
Tahoe 26.2 introduces Edge Light to light your face during low-light video calls, improves Podcasts with automatic chapter generation, adds filters to the Games library, adds AirDrop codes as an additional verification with unknown contacts, enhances Freeform tables, and more. Fuller release notes are available here, and are a significant improvement in themselves.
Security release notes for Tahoe report a total of 46 vulnerabilities addressed. Among them are multiple WebKit vulnerabilities, including two that Apple believes have been exploited already “in an extremely sophisticated attack against specific targeted individuals” in earlier versions of iOS. Notes for Sequoia list 25, and those for Sonoma 21. The Safari update for Sequoia and Sonoma does address those critical vulnerabilities.
Its macOS build number is 25C56, it updates iBoot firmware to version 13822.61.10 on Apple silicon Macs and Intel firmware to 2094.40.1.0.0 (iBridge 23.16.12048.0.0,0), and brings Safari to version 26.2 (21623.1.14.11.9).
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.
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.
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.
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.
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.
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.
Login
