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.

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

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

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

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

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

[Last updated 06:42 4 November 2025]

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.

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.

This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 26.0 Tahoe.

Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. Intel models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs just give an iBoot version.

Macs still running older versions of macOS are covered by information at:

• this page for Sequoia,
• this page for Sonoma,
• this page for Ventura,
• this page for Monterey,
• this page for Big Sur,
• this page Catalina,
• this page for High Sierra,
• this page for El Capitan and earlier.

Apple silicon Macs

The current iBoot version is 13822.1.2.

Intel Macs with T2 chips

The current EFI version is 2092.0.0.0.0 and iBridge is 23.16.10350.0.0,0.

Apple Studio Display

The current version remains 17.0 (build 21A329).

How to check your Mac’s firmware version

The simplest way is to run my free tool SilentKnight, available from its product page.

Alternatively, use the About This Mac command at the top of the Apple menu; hold the Option key and click on the System Information command. In the Hardware Overview listing, this is given as the Boot ROM Version or System Firmware Version.

What to do if your Mac’s firmware is different from that shown

If the version is higher than that given here, it indicates that Mac has installed a more recent version of macOS, which has installed a later version of the firmware. This is almost invariably the result of installing a beta-release of the next version of macOS. This occurs even when the newer macOS is installed to an external disk.

If the installed version of firmware has a version lower than that shown, you can try installing macOS again to see if that updates the firmware correctly. If it still fails to update, you should contact Apple Support.

Firmware updaters are now only distributed as part of macOS updates and upgrades: Apple doesn’t provide them separately.

All T2 and Apple silicon models automatically check the integrity of their firmware in the early part of the boot process anyway. If any errors are found then, the Mac should be put into DFU mode and firmware restored from the current IPSW image file. In Sonoma and later this can be performed in the Finder, and no longer requires Apple Configurator 2. Full instructions are provided in this article. If you don’t have a second Mac or don’t feel that you can perform this yourself, it should be easy to arrange with an Apple store or authorised service provider.

(Last updated 19 September 2025)

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.