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.

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.

Each of the main security services in macOS such as XProtect relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.

Currently, those most frequently updated are XProtect and XProtect Remediator, the former being updated most weeks. However, Sequoia changed the way that XProtect’s data is updated, and it’s now intended to occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.

This article details each of the main security data files found in macOS 26 Tahoe, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, left frozen in time, or removed completely. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.

Main Security Data

XProtectPayloads, alias XProtect.app and XProtect Remediator
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app in the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every month or so using Software Update or a substitute.

XProtectPlistConfigData
These are whitelists and blacklists used by XProtect. Since Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle in the Data volume; the secondary is also in the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and can used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Tahoe is also intended to update the primary bundle via a CloudKit connection to iCloud. This is routinely updated every week, at the same time as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, if a more recent version is available.

Bastion
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. This doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb, and reports them to Apple as security intelligence. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated irregularly.

AppleKextExcludeList
Latest version: 21.0.0, 9 September 2025 (26.0 release).
This is a huge list of kernel extensions that are to be treated as exceptions to Tahoe’s security rules, and is stored in the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist. At one time, this was a blacklist of kexts to block, but in Mojave 10.14.5 that changed, and it has since been a list of over 18,000 kexts that are given exceptional treatment, as explained here. However, this doesn’t appear to apply to Apple silicon Macs, as they have their own separate rules about which kexts to allow and which to block, that are far more stringent. Accordingly, this list should go away in macOS 27.

Others

IncompatibleAppsList
Latest version: 260.200 (26.0 release).
This is a bundle in the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.

Vestigial Data

MRTConfigData
Last version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored in the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but is installed later as a security data update.

Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database in the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db and may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database isn’t currently used.

Gatekeeper E Configuration Data (GKE), alias Gatekeeper Compatibility Data
Latest version: 1.0 dated 2 October 2019.
This was an SQLite database in the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since. Although this is still downloaded and installed, it’s nowhere to be found in Tahoe, and appears to be a historical remnant.

Last updated: 19 September 2025.

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.

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.

Apple has just released urgent security updates to bring macOS Sequoia to 15.6.1, Sonoma to 14.7.8, and Ventura to 13.7.8.

Security release notes for these are already available, for 15.6.1, 14.7.8 and 13.7.8 Each refers to the same single vulnerability in ImageIO, which is apparently being exploited “in an extremely sophisticated attack against specific targeted individuals” using a crafted image file.

The download for 15.6.1 is about 1.56 GB for an Apple silicon Mac, and should be well under 1 GB for Intel. Time to update!

For many of us, Live Text and Visual Look Up are real boons, making it simple to copy text from images, to perform Optical Character Recognition (OCR) on images of text, and to identify objects of interest. They are also used by the mediaanalysisd service to extract text and object identifications for indexing by Spotlight, making those image contents searchable. Although the latter can be disabled generally or for specific folders in Spotlight settings, there appears to be only one control over Live Text, and none for Visual Look Up. This article examines what that single control does, using log extracts obtained from a Mac mini M4 Pro running macOS Sequoia 15.6. It follows my recent article on how these features work.

Setting

Live Text, which is enabled by default, can be disabled in Language & Region settings. When that is turned off, opening an image containing text in Preview no longer makes any text selectable. However, Visual Look Up still works as normal.

Textual images

When an image containing recognisable text but no other objects is opened in Preview, the VisionKit subsystem is still activated soon after the image is loaded. VisionKit initially reports that the “device” supports analysis, but immediately clarifies that to
Device does not support image analysis, but does support Visual Search, limiting to just Visual Search.
It then starts a VKImageAnalyzerProcessRequestEvent with a MAD parse request. That leads to a Visual Search Gating Task being run, and the Apple Neural Engine (ANE) and all CPU P cores are prepared for that.

Less than 0.1 second later, the end of the VKImageAnalyzerProcessRequestEvent is reported, and VisionKit returns an analysis that no image segments merits further analysis. Preview’s ⓘ Info button remains in its normal state, and clicking on that doesn’t alter the image displayed.

Images with other objects

An image containing potentially recognisable objects doesn’t stop there. If VisionKit returns an analysis indicating Visual Search could extract objects from the image, the ⓘ Info button adds stars and waits for the user to open the Info window.

VisionKit reports in the log
Setting Active Interaction Types: [private], [private]
then that it
DidShowVisualSearchHints with invocationType: VisualSearchHintsActivated, id: 1

When one of those Visual Search Hints is clicked, the Lookup View is prepared, followed by a notice from LookupViewService that it’s Changing state from LVSDisplayStateConfigured to LVSDisplayStateSearching. That leads to VisionKit making a Visual Search request from mediaanalysisd.

After the Apple Neural Engine (ANE) is run to progress that, successful search results in PegasusKit making its internet connection to identify the object, exactly as it does when Live Text is enabled and text has been recovered from the image:
Querying https: // api-glb-aeuw1b.smoot.apple.com/apple.parsec.visualsearch.v2.VisualSearch/VisualSearch with request (requestId: [UUID]) : (headers: ["Content-Type": "application/grpc+proto", "grpc-encoding": "gzip", "grpc-accept-encoding": "gzip", "grpc-message-type": "apple.parsec.visualsearch.v2.VisualSearchRequest", "X-Apple-RequestId": "[UUID]", "User-Agent": "PegasusKit/1 (Mac16,11; macOS 15.6 24G84) visualintelligence/1", "grpc-timeout": "10S"]) [private]

The ANE is finally cleaned up and shut down as the search results are displayed in the Lookup View.

Conclusions

• When Live Text is disabled in Language & Region settings, images are still analysed when they are opened, to determine if they’re likely to contain objects that can be recognised in Visual Search for Visual Look Up.
• If there are no such objects detected, VisionKit proceeds no further.
• If there are suitable objects, mediaanalysisd and VisionKit proceed to identify them using Visual Search Hints, as normal.
• If the user clicks on a Visual Search Hint, PegasusKit connects to Apple’s servers to identify that object and provide information for display in the Lookup View.
• Although there is less extensive use of the ANE and CPU cores than when Live Text is enabled, neural networks are still run locally to perform a more limited image analysis.

I’m very grateful to Benjamin for pointing out this control over Live Text.

Live Text and Visual Look Up are recent features in macOS, first appearing in Monterey nearly four years ago. As that immediately followed Apple’s short debacle over its now-abandoned intention to scan images for CSAM, most concerns have been over whether these features send details of images to Apple.

Although recent Intel Macs also support both these features, they don’t have the special hardware to accelerate them, so are far slower. For this walkthrough, I’ll only present information from Apple silicon Macs, in particular for the M4 Pro chip in a Mac mini.

Initiation

When an image is opened from disk, the VisionKit system starts up early, often within 0.1 second of it starting to open. Its initial goal is to segment the image according to its content, and identify whether there’s any part of it that could provide text. If there is, then Live Text is run first so you can select and use that as quickly as possible.

In the log, first mention of this comes from com.apple.VisionKit announcing
Setting DDTypes: All, [private]
Cancelling all requests: [private]
Signpost Begin: "VKImageAnalyzerProcessRequestEvent"

It then adds a request to Mad Interface, that’s the mediaanalysisd service, with a total method return time, and that’s processed with another signpost (a regular log entry rather than a Signpost):
Signpost Begin: "VisionKit MAD Parse Request"

com.apple.mediaanalysis receives that request
[MADServicePublic] Received on-demand image processing request (CVPixelBuffer) with MADRequestID
then runs that
Running task VCPMADServiceImageProcessingTask

This is run at a high Quality of Service of 25, termed userInitiated, for tasks the user needs to complete to be able to use an app, and is scheduled to run in the foreground. Next Espresso creates a plan for a neural network to perform segmentation analysis, and the Apple Neural Engine, ANE, is prepared to load and run that model. There’s then a long series of log entries posted for the ANE detailing its preparations. As this proceeds, segmentation may be adjusted and the model run repeatedly. This can involve CoreML, TextRecognition, Espresso and the ANE, which can appear in long series of log entries.

Text recognition

With segmentation analysis looking promising for the successful recognition of text in the image, LanguageModeling prepares its model by loading linguistic data, marked by com.apple.LanguageModeling reporting
Creating CompositeLanguageModel ([private]) for locale(s) ([private]): [private]
NgramModel: Loaded language model: [private]
and the appearance of com.apple.Lexicon. An n-gram is an ordered sequence of symbols, that could range from letters to whole words, and the lexicon depends on the language locales. In my case, two locales are used, en (generic English) and en_US (US English).

At this point, mediaanalysisd declares the VCPMADVIDocumentRecognitionTask is complete, and runs a VCPMADVIVisualSearchGatingTask, involving com.apple.triald, TRIClient, PegasusKit and Espresso again. Another neural network is loaded into the ANE, and is run until the VCPMADVIVisualSearchGatingTask is complete and text returned.

The next task is for the translationd service to perform any translations required. If that’s not needed, VisionKit reports
Translation Check completed with result: NO, [private]
These may be repeated with other image segments until all probable text has been discovered and recognised. At that stage, recognised text is fully accessible to the user.

Object recognition

Further image analysis is then undertaken on segments of interest, to support Visual Look Up. Successful completion of that phase is signalled in Preview by the addition of two small stars at the upper left of its ⓘ Info tool. That indicates objects of interest can be identified by clicking on that tool, and isn’t offered when only Live Text has been successful. VisionKit terms those small buttons Visual Search Hints, and remains paused until the user clicks on one.

Visual Search Hints

Clicking on a Visual Search Hint then engages the LookupViewService, and changes the state from Configured to Searching. VisionKit records another
Signpost Begin: "VisionKit MAD VisualSearch Request"
and submits a request to MAD for image processing to be performed. If necessary, the kernel then brings all P cores online in preparation, and the ANE is put to work with a new model.

PegasusKit then makes the first off-device connection for assistance in visual search:
Querying https: // api-glb-aeus2a.smoot.apple.com/apple.parsec.visualsearch.v2.VisualSearch/VisualSearch with request (requestId: [UUID]) : (headers: ["grpc-message-type": "apple.parsec.visualsearch.v2.VisualSearchRequest", "Content-Type": "application/grpc+proto", "grpc-encoding": "gzip", "grpc-accept-encoding": "gzip", "X-Apple-RequestId": "[UUID]", "grpc-timeout": "10S", "User-Agent": "PegasusKit/1 (Mac16,11; macOS 15.6 24G84) visualintelligence/1"]) [private]

When the visual search task completes, information is displayed about the object of interest in a floating window. Visual Look Up is then complete, and in the absence of any further demands, the ANE may be shut down to conserve energy, and any inactive CPU cluster likewise:
ANE0: power_off_hardware: Powering off... done
PE_cpu_power_disable>turning off power to cluster 2

Key points

• Image analysis starts shortly after the image is loaded.
• Central components are VisionKit and mediaanalysisd, MAD.
• In Apple silicon Macs, extensive use is made of the Apple Neural Engine throughout, for neural network modelling.
• Most if not all is run at high QoS of 25 and in the foreground, for performance.
• Segmentation analysis identifies areas that might contain recoverable text.
• Segments are then analysed, using language modelling for appropriate locales and languages, and lexicons, to return words rather than fragmented characters.
• When Live Text is ready, segments are then analysed for recognisable objects. When that’s complete, each is marked by a Visual Search Hint.
• Clicking on a Visual Search Hint initiates a network connection to provide information about that object, displayed in a floating window.

With the next scheduled update to macOS Sequoia likely to be released in September or October, macOS 15.6 officially marks the end of its year-long cycle of full support. This article looks at its updates and how it has changed.

Updates

It took Sequoia a total of 11 updates to reach version 15.6 at the end of July, including five unscheduled patch updates, which is close to average. Prominent through those updates has been the number of security vulnerabilities addressed, peaking at 81 in 15.6.

In terms of cumulative size of updates, Sequoia was close to average at a total of 27.5 GB for Apple silicon Macs and 19.3 GB for Intel models. Although not as bad as Big Sur which took over 50 GB for Apple silicon Macs, it wasn’t as good as Sonoma at just over 21 GB. Update size was relatively small up to 15.3, but added over 9 GB in the three updates it took to reach 15.4. Apple doesn’t appear to have made progress in reducing the size of updates for Apple silicon Macs, and that may not be achieved until macOS 27 next year, when Intel support is finally dropped.

Bundled apps

The total number of bundled apps has increased slightly, from 60 in Sonoma to 62 in 15.0, and 64 in 15.6. That’s set to rise again in Tahoe, with the addition of Journal and Phone.

/System/Library

The total number of bundles in /System/Library has risen further to reach 9,304, almost double the number in 10.14.5 six years ago, and up from 8,392 a year ago in 14.6. Unusually, this has risen by nearly 300 through Sequoia’s cycle. Previously it has been more common for only small rises to occur during a cycle, and in macOS 13 the total fell slightly.

Over that period, the main growth has been in the number of Private Frameworks, which have risen from about 1,760 in 10.14 to over 4,400 in 15.6. Public Frameworks have risen less, from less than 520 to 806. Despite Apple’s campaign for third-parties to move away from kernel extensions, those in macOS also continue to grow, rising from a minimum of 515 in 10.15.0 to 939 in 15.6. Sequoia has added 39 of those in going from 15.0 to 15.6.

This is a more detailed breakdown by category of bundles in /System/Library, comparing 10.15.6 with 15.6:

• Accessibility, a small increase from 125 to 161
• Automator, a small reduction from 266 to 252
• Templates, a marked reduction from 383 to 252
• CoreServices, a small reduction from 390 to 363
• AssetsV2, a substantial growth from 188 to 806
• Public Frameworks, a modest increase from 600 to 806
• Kernel extensions, a substantial increase from 534 to 939
• Private Frameworks, a huge increase from 2,055 to 4,407.

Five years ago in 10.15.6, public Frameworks were almost a quarter of all Frameworks. In 15.6, they are less than 18%. macOS continues to become an increasingly private operating system supporting Apple’s apps, not those of third party developers.

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!