Starting up a Mac, iPad or iPhone begins a series of processes progressing from their small boot ROMs to user login, starting up the services required for the operating system and booting the array of hardware in the chip. Early phases, before the kernel is booted, leave little in the way of records, just a few ‘breadcrumbs’ in NVRAM, but the kernel and processes it starts write a great many entries in the log. This article describes a few of those, concentrating on macOS 15.5, with additional information on iPadOS and iOS 18.5.

Logs

These were obtained from logarchives made soon after normal startup on:

• Mac mini M4 Pro, booting macOS 15.5 in Full Security mode from the internal SSD;
• iPad Pro 11-inch (4th generation)(Wi-Fi), with an M2 booting iPadOS 18.5 normally;
• iPhone 15 Pro, booting iOS 18.5 normally.

Logarchives were opened in LogUI and all log entries (excluding Signposts) were extracted for the first 5 seconds following the start of kernel boot and saved to a LogUI JSON file. Following correction for time adjustments (see below), those contained:

• for macOS, 20,000 entries in a total of 5.7 seconds;
• for iPadOS, 10,000 entries in a total of 5.7 seconds;
• for iOS, 10,000 entries in a total of 5.6 seconds.

Each set of entries opens with an entry recording the first moment of the boot process, for example
08:23:33.343017 === system boot: CCB8E0AC-5B94-4789-B951-BF0B893FF45F
following which there is a gap of over 5 seconds during which preboot is completed. The next entry then records the start of kernel boot, for example in macOS with
08:23:38.536777 kprintf initialized

Periods between those two entries were 5.2 seconds for macOS, 5.3 seconds for iPadOS, and 5.1 seconds for iOS.

Times and their correction

One potential source of major error in using log entries during startup results from clock time corrections. When started up, Macs and Apple’s devices appear invariably to have clock times about 6 seconds in advance of UTC. This is corrected about 4 seconds into kernel boot, and marked in two log entries such as
00.827884 === system wallclock time adjusted
00.860742 === system wallclock time adjusted
The first adjustment normally sets the clock back slightly more than necessary, but the second corrects that more accurately.

Effects on timestamps in log entries can appear confusing, as entries prior to time adjustment are given later timestamps than entries written after the adjustments have been made. This may give the impression that the order of log entries is incorrect, and any time calculations that depend on times recorded before and after adjustment require compensation by the two adjustments made. All times given below are taken from records made before system wallclock time adjustment, thus don’t require correction.

Time adjustments may need to be taken into consideration when accessing Endpoint Security events, as some may be written before adjustments are made, so might appear to be out of kilter with later events. This could apply to boot events for the launchd Subsystem, for example.

Log entries

Shortly after the start of kernel log entries with the initialisation of kprintf, the kernel banner is written, but only in macOS
Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041

Virtual memory, logging and other fundamental features are then prepared, and in macOS (not iPadOS or iOS) TXM, the Trusted Execution Monitor, is started
TXM [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.3
followed by the announcement of two stages of preboot, at 0.11 seconds after the start of kernel boot:
iBoot version: iBoot-11881.121.1
iBoot Stage 2 version: iBoot-11881.121.1

It’s notable that macOS gave an iBoot version of 11881.121.1, but iPadOS and iOS gave a slightly later version of 11881.122.1.

According to Apple, TXM (together with SPTM) is active on all three platforms, although it only appears to be well-reported in macOS. Apple explains: “Secure Page Table Monitor (SPTM) and Trusted Execution Monitor (TXM) on iOS, iPadOS, macOS and visionOS are designed to work together to help protect page tables for both user and kernel processes against modification, even when attackers have kernel write capabilities and can bypass control flow protections.” TXM then enforces the policies that govern code execution.

The kernel then turns its attention to loading Core Crypto support, reported in detail in all three platforms, and support for Image4 files, used extensively during and after boot:
0.295967 Darwin Image4 Extension Version 7.0.0: Tue Apr 22 19:44:19 PDT 2025; root:AppleImage4-320.100.22~1926/AppleImage4/RELEASE_ARM64E
and security policy is loaded (reported in macOS only).

AMFI and credential management

All three platforms then report loading of Apple Mobile File Integrity (AMFI), which obtains the model designator from the device tree:
AMFI: queried model name from device tree: Mac16,11
AMFI: queried model name from device tree: iPad14,3
AMFI: queried model name from device tree: iPhone16,1
which is probably the simplest way to confirm the model identifier from the log at this stage. On iOS only, AMFI next reports disabling Swift Playgrounds JIT:
AMFI: disabling Swift Playgrounds JIT services on iPhone devices

The kernel then turns to management of credentials with Credential Manager, which works with secrets managed by the Secure Enclave Processor (SEP) (all platforms). One key log entry to look for is the report of SEP Key Store startup,
"AppleSEPKeyStore":326:0: starting (BUILT: Apr 22 2025 19:45:09) ("normal" variant 🌽 , 1827.120.2)

Startup of hardware systems continues, with Bluetooth reported early, followed by IOThunderboltFamily, and the Apple Neural Engine ANE. In macOS only, the remains of an old copyright notice will then appear:
Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved.
iPadOS and iOS report Backlight startup in
AppleARMBacklight::start: Using new Backlight Architecture 1

CPU cores

After those, in macOS only, the log records registration of CPU cores and their clusters, then starts each in turn. Prior to this, all code has been run on a single core, but once the others have been started, multiple cores are available. The exact log entries recording this may vary between different M families, but typically run as follows:

• ml_processor_register>pset_find(cluster_id=0) returned pset -1
• ml_processor_register>pset_create(cluster_id=0) returned pset 0
• ml_processor_register>cpu_id 0x0 cluster_id 0 cpu_number 0 is type 1
• repeated to create each cluster and allocate CPUs to them, then
• cpu_start() cpu: 0
• arm_cpu_init(): cpu 0 online
• for each CPU in turn.

Although the iPad tested has an M2 chip, no such sequence was reported for its CPU cores in the log.

Security policy

macOS reports Gatekeeper status and the start of AppleSystemPolicy:
AppleSystemPolicy GK status: enabled
AppleSystemPolicy Per file changetime scans: enabled
Security policy loaded: Apple System Policy (ASP)
AppleSystemPolicy has been successfully started

APFS

APFS follows, with differences between log entries according to platform. Initial loading is announced in each, giving the version number
apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.120.31, apfs-2332.120.31.0.2, 2025/04/22
In macOS only, NFS is announced shortly afterwards
com_apple_filesystems_nfs: successfully loaded NFS module
and handling individual file system devices follows.

Boot devices are recorded in full:
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16GFamilyIO/ans@9600000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP2048Z Media/IOGUIDPartitionScheme/Container@2/AppleAPFSContainerScheme/AppleAPFSMedia
/AppleAPFSContainer/Macintosh HD@1 (macOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleT811xIO/ans@77400000/AppleASCWrapV4
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0512Z Media/IOGUIDPartitionScheme/Container@1 (iPadOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16IO/ans@F9400000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0128Z Media/IOGUIDPartitionScheme/Container@1 (iOS)

Each platform states the BSD root in a paired entry:
BSD root: disk3s1
, major 1, minor 15
By that time, the boot process is well underway and log entries are being made every few microseconds.

Key points

• Log entry times need to be corrected when they straddle clock adjustments marked by === system wallclock time adjusted
• === system boot: marks the start of preboot, following which there are no log entries for over 5 seconds before kernel boot starts.
• Start of Trusted Execution Monitor (TXM) is only logged in macOS, although it’s also active in iPadOS and iOS.
• iBoot versions may differ between macOS, and iPadOS/iOS.
• An early log entry from AMFI reports the model designator.
• AMFI reports disabling Swift Playgrounds JIT services on iPhones.
• In macOS only, CPU clusters and cores are registered, and started up individually.
• macOS then reports Gatekeeper (GK) status and the start of AppleSystemPolicy.
• The boot device is reported in full.
• Throughout these, many other services and hardware features are started up.
• During early kernel boot, macOS writes 20,000 log entries in about 5.7 seconds, iPadOS and iOS 10,000.

Volume structure of internal startup disks has grown increasingly complex during the transition from Intel to Apple silicon Macs. There also seems to be little information on iOS and iPadOS to compare against. This article briefly reviews structures of macOS 15 Sequoia on Apple silicon, iOS 18 and iPadOS 18.

Information for macOS is derived from the diskutil command tool, and from APFS entries in the log when booting a Mac mini M4 Pro in macOS 15.5. That for iOS is drawn from APFS entries in the log when booting an iPhone 15 Pro in iOS 18.5. That for iPadOS is drawn from APFS entries in the log when booting an iPad Pro 11-inch (4th generation)(Wi-Fi) in iPadOS 18.5. All three had Apple Intelligence enabled prior to booting. iOS and iPadOS logs were obtained from sysdiagnoses, and all logs were read using LogUI.

macOS 15 (Apple silicon)

The boot volume group consists of six volumes in a single container (partition). Two other containers are normally hidden from the user:

• the first container of around 524 MB is reserved for preboot and secure boot support.
• another container of about 5.4 GB is used for fallback recovery frOS, and in Big Sur was the primary recovery system, until the introduction of paired recovery volumes in macOS 12 Monterey.

The boot volume group contains:

• System, left unmounted after booting from its Signed System Volume (SSV) snapshot;
• Data, the only encrypted volume in the group, with numerous cryptexes grafted into it, and firmlinked to the SSV at multiple points;
• paired, primary Recovery, containing a disk image of the Recovery system;
• VM, the backing store for virtual memory;
• Preboot, for early stages in the secure boot process, with cryptexes grafted into it;
• Update, used as a working volume for macOS updates.

There are two groups of cryptexes grafted onto those volumes:

• system cryptexes, including the large SystemCryptex or os.dmg of about 4.3 GB mainly containing dyld caches, and the smaller AppCryptex or app.dmg containing Safari and supporting components;
• PFK volumes containing support components for Apple Intelligence features. These are numerous, and some are listed in the Appendix at the end.

If you’re wondering what a PFK volume might be, so am I. But this is what Google’s AI had to say: “Mac PFK” likely refers to a combination of MAC knives and Practical Fishkeeping (PFK) magazine. MAC knives are known for their high-quality, sharp blades and are popular among chefs and home cooks. Practical Fishkeeping is a magazine focused on fishkeeping, covering various aspects of the hobby.

These are summarised, without the help of Practical Fishkeeping, in this diagram.

iPadOS 18

In contrast to macOS since Big Sur, iPadOS and iOS only appear to have two containers (partitions) on their internal storage. The first is presumed to be similar in purpose to that in macOS, in supporting preboot and secure boot, although there is a xART volume in the boot volume group. In iPadOS, this container is smaller, at around 367 MB.

The boot volume group contains a slightly different range of volumes:

• there is no Recovery volume;
• there is no VM volume, as iPadOS doesn’t ordinarily support swapping/paging, although M-series models can in certain circumstances;
• User, a second encrypted volume, appears unique to iPadOS;
• xART and Hardware volumes are additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

iOS 18

This is similar to iPadOS, with a first container/partition of around 351 MB, and the following differences in the boot volume group:

• there is no User volume, and no Update volume;
• Baseband Data is additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

Conclusions

• Volume structure of internal startup disks differs considerably between macOS, iPadOS and iOS.
• As would be expected, iPadOS and iOS are most similar, but even they have substantial differences.
• They each run their systems from a Signed System Volume firmlinked to an encrypted Data volume.
• They each graft on two sets of cryptexes, one supplementing the system with dyld caches and Safari, the other providing components for AI.
• There are now at least 24 cryptexes used to support AI.

I welcome corrections and explanations, please.

Appendix: Some PFK volumes from cryptexes

• UC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_300M_BAUC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_DRAFTS_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_CONCISE_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROFESSIONAL_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_SUMMARIZATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROOFREADING_REVIEW_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MESSAGES_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_AUTONAMING_MESSAGES_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_URGENCY_CLASSIFICATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_FRIENDLY_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_MULTILINGUAL_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_VISUAL_IMAGE_DIFFUSION_V1_BASE_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAGIC_REWRITE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_IF_PLANNER_NLROUTER_BASE_EN_GENERIC_H14G_Cryptex.dmg

Source: iPadOS 18.5, configured with AI enabled for British English.

There are several well-known methods for excluding items from Spotlight search. This article details one that, as far as I can tell, has remained undocumented for the last 18 years since it was added in Mac OS X 10.5 Leopard, when Spotlight was only two years old, and can still catch you out by hiding files from local Spotlight search. This was discovered by Matt Godden, who has given his account here.

Well-known exclusions

There have been three general methods of excluding folders from Spotlight’s indexing and search, although only two of them still work reliably:

• making the folder invisible to the Finder by prefixing a dot ‘.’ to its name;
• appending the extension .noindex to the folder name (this earlier worked with .no_index instead);
• putting an empty file named .metadata_never_index inside the folder; that no longer works in recent macOS.

Additionally, System Settings offers Spotlight Privacy settings in two sections. Search results won’t normally prevent indexing of those items, but does block them from appearing in search results. Spotlight’s indexing exclusion list is accessed from the Spotlight Privacy… button, where you can add items that you don’t want indexed at all.

Extended attribute

Matt Godden investigated repeated failure of Spotlight search to find some images in his large media library, and discovered that the extended attribute (xattr) named com.apple.metadata:kMDItemSupportFileType was responsible. Images that weren’t returned in a search of that library all had that xattr attached, and when that was removed, those images were found reliably.

According to Apple’s documentation, that xattr was available in Mac OS X 10.5 and has since been deprecated. No further information is given about its function or effect, nor does it appear in an older list of Spotlight metadata attribute keys.

Search of previous mentions of this xattr reveal that it has been found with either of two values, iPhotoPreservedOriginal as described for Matt’s images, and MDSystemFile used with several apps that have proved equally inaccessible to Spotlight search. Images that have this xattr attached appear to have originated in old iPhotos libraries, which may have been migrated to Photos libraries. Searches for files with this xattr suggest that even old collections of images seldom have the xattr present, in my case on only 9 files out of over 800,000 checked, and the MDSystemFile variant wasn’t found in over 100,000 application files.

The mere presence of this xattr is sufficient to exclude a file from Spotlight search: setting its value to the arbitrary word any, for example, was as effective as setting it to either iPhotoPreservedOriginal or MDSystemFile.

Strangely, the method used to search is important: files with the com.apple.metadata:kMDItemSupportFileType xattr can’t be found when using Local Spotlight search in a Find window, but can be found by Mints using a standard search predicate with NSMetadataQuery.

Detection and removal

The simplest way to detect whether your Mac has files with the com.apple.metadata:kMDItemSupportFileType xattr is to use the Crawler tool in my free xattred, with Full Disk Access. Open its window using the Open Crawler… command in the Window menu, paste the xattr name into the Xattr type box. Click on the Scan button and select the volume or folder to check. xattred then crawls the full directory tree within that and reports all files with that xattr.

The xattr can then be removed by dragging the file onto one of xattred’s main windows, selecting the xattr, and clicking on the Cut button. That change will be effective immediately, and the file made available through Spotlight search within a few seconds.

If you have more than a handful of files with the xattr, use xattred’s Stripper to remove them all. Paste the xattr name into the Xattr type box. Click on the Strip button and select the volume or folder to process.

Recommendations

• If your Mac is likely to search old images that might have the com.apple.metadata:kMDItemSupportFileType xattr attached, search for and remove all such xattrs to ensure those files aren’t excluded from search.
• Whether this behaviour is intentional or not, it’s clearly an undesirable legacy, has been deprecated for many years, and should be removed from Spotlight search.

I’m extremely grateful to Matt Godden for his painstaking research and keeping me informed.

Apple pre-releases some of the components for the next major version of macOS in the previous version. For example, when macOS Monterey 12.3 was released on 14 March 2022, a new XProtect.app bundle appeared in /Library/Apple/System/Library/CoreServices, and passed almost unnoticed until it was updated to version 2 in macOS 12.4 on 16 May 2022. By June that was being updated frequently, and is now a significant part of macOS protection against malware.

This article looks back at versions of Sequoia that have brought new components to identify those we might see more of next month, when the first betas of macOS 16 reach developers.

Officially announced

One new feature that Apple has already made available in macOS 15.4 and later is privacy control of access to the pasteboard, described here. It’s likely that a new Pasteboard item will be added to Privacy & Security settings in macOS 16, allowing you a choice between:

• automatically allowing all pasteboard access without notifying the user (as previously);
• always denying all pasteboard access, unless the user explicitly chooses to access the pasteboard for pasting;
• asking the user for permission to grant pasteboard access, although that will automatically be granted when the user explicitly chooses to access the pasteboard for pasting;
• the default, to ask the user for permission when an app rather than the user seeks access to the General pasteboard; all other pasteboards would always allow access.

This appears complicated, and I expect may need simplification during beta-testing, or users could be baffled. Apple’s note details a default setting you can use to preview this behaviour in macOS 15.5 for individual apps in testing.

To celebrate the 40th birthday of its accessibility support, Apple has announced some new features we can expect in macOS 16. Among them is a Magnifier app that will use an iPhone running iOS 19 through Continuity Camera as a live video magnifier. Others include:

• Vehicle Motion Cues, already available in iOS and iPadOS;
• Braille Access, a full-featured braille note-taker;
• Accessibility Reader, to make text easier to read across a wide range of disabilities.

New apps

macOS 15.5 introduces a new app in CoreServices named Apple Diagnostics. This is currently non-functional, but appears to give access to some form of online diagnostic service in the future.

New kernel extensions

Three kernel extensions to watch for in macOS 16 are:

• AppleDisplayManager, introduced in 15.2, and still at version 1.0
• AppleAOP2, introduced in 15.4, and still at version 1.0; AOP is the Always On Processor in Apple silicon Macs;
• AppleProcessorTrace, introduced in 15.4, and still at version 1.0.0.

New public frameworks

Two were added to 15.4, and remain at version 1.0, for CLLogEntry which appears to be part of Core Location, and SecurityUI which hasn’t yet been mentioned anywhere.

New private frameworks

Many new private frameworks have been added by updates to Sequoia. Although most of these remain at their initial build of 1.0, some have seen surprising increases, including:

• AppSystemSettings, introduced in 15.2, now at build 3.3.5
• CryptexKit and CryptexServer, introduced in 15.4, now at build 493.120.7
• DeepVideoProcessingCore, introduced in 15.4, now at build 1.17
• various GameServices, introduced in 15.4, and already at build 819.4.46
• OSEligibility, introduced in 15.2, now at build 181.120.32.

Among the new private frameworks with intriguing names that remain at their initial version are: Bosporus, Morpheus and MorpheusExtensions, an OnDeviceStorage group, and most recently CodableSwiftUI.

Your guess is no doubt better than mine as to what these all do, but I expect some of them will appear in macOS 16, in one guise or another.

The update to macOS Sequoia 15.5 is likely to be the last to include remaining enhancements and fixes before engineers are more committed to the beta-releases of macOS 16.0 from early June onwards. It’s therefore unfortunate that Apple chose to provide only limited information about what it addresses.

Correlating the general release notes with those for Enterprise results in a short list of:

• one new feature, that parents now receive a notification from a child’s device when its Screen Time passcode is used;
• large network shares should enumerate correctly in the Finder;
• the Pro Display Calibrator utility should work properly on M4 MacBook Pros, without causing a kernel panic;
• apps registering helper executables should now do so correctly.

Most important for many is that AFP is now deprecated and “will be removed in a future version of macOS”, according to notes for Enterprise.

Security release notes for Sequoia 15.5 are here, and list 46 vulnerabilities fixed, none of which are believed to have been exploited already. Eight of those vulnerabilities are in WebKit.

The macOS build number is 24F74. Firmware in Apple silicon Macs is updated to iBoot version 11881.121.1, while that in T2 Macs is updated to 2075.120.2.0.0 (iBridge 22.16.15072.0.0,0).

Version changes seen in bundled applications include:

• Books to version 7.5
• Freeform to version 3.5
• Music to version 1.5.5
• News to version 10.4
• Notes to version 4.12.6
• Passwords to version 1.5
• Safari to version 18.5 (20621.2.5.11.8)
• Stocks to version 7.3
• TV to 1.5.5
• Tips to 15.5
• Weather to version 5.1.

Those in /System/Library are more extensive, and include:

• Audio Plug-Ins HAL MacAudio driver to version 550.4
• In CoreServices, there’s a new Apple Diagnostics app at version 1.0, which currently doesn’t appear functional
• The XboxGamepad driver extension has a build increment
• AGX kernel extensions all have version increments
• AppleUSBAudio kernel extension has a version increment
• AudioDMAController kernel extensions have version increments
• APFS is updated to version 2332.120.31
• Most of the major public frameworks have build increments, with SwiftUI at version 6.5.4
• Many Private Frameworks are updated.
• A new Private Framework CodableSwiftUI has been added at version 1.0
• New Private Frameworks NDOAPI, NDOUI, SUDocAssets and SensorAccess have also been added at version 1.0.

The new Apple Diagnostics app looks particularly interesting, but appears to attempt a remote connection that is denied, so reports the error and does nothing else.

Overall, this appears to be a substantial update with many fixes included. It’s a pity that Apple hasn’t been prepared to tell us more in its haste to move on to 16.0.

Apple has just released the update to macOS Sequoia to bring it to version 15.5, and security updates for 14.7.6 and 13.7.6.

The Sequoia update for Apple silicon Macs is just under 3 GB in size, and just over 2 GB for Intel Macs.

Apple’s general release notes for Sequoia 15.5 only mention one new feature, that parents now receive a notification from a child’s device when its Screen Time passcode is used. Otherwise, it’s the usual “enhancements, bug fixes, and security updates”.

Security release notes for Sequoia 15.5 are here, and list 46 vulnerabilities fixed, none of which are reported as believed to have been exploited already. Those for 14.7.6 are here, and for 13.7.6 are here.

One important entry in the Enterprise release notes concerns the future of AFP: “Apple Filing Protocol (AFP) client is deprecated and will be removed in a future version of macOS.” I can hear the howls of anguish already.

Developer release notes claim three bugs are fixed:

• large network shares should enumerate correctly in the Finder,
• Pro Display Calibrator should work properly on M4 MacBook Pros,
• apps registering helper executables should now do so correctly.

The macOS build number is 24F74. Firmware in Apple silicon Macs is updated to iBoot version 11881.121.1, while that in T2 Macs is updated to 2075.120.2.0.0 (iBridge 22.16.15072.0.0,0).

Safari is updated to version 18.5 (20621.2.5.11.8), and there are 8 security bugs fixed in WebKit (15.5).

Last updated at 1845 GMT 12 May 2025.

Many of you have commented that you too find that apps and command tools can now take surprisingly long to launch. Although my previous analyses have demonstrated how those can often be attributed to security checks being made on components including frameworks and dylibs, there remains some dispute over the nature of those checks. Although I believe there’s convincing evidence that those checks are prolonged to recompute hashes and CDHashes, others are adamant that they are in fact ‘malware scans’. This article considers new evidence.

Inspecting and analysing the log during the launch of large apps isn’t the best way of getting a clear view of what happens when macOS runs its security checks. There’s a great deal going on at the time, with multiple security checks being performed for TCC, LaunchServices and RunningBoard in dialog, sandboxes and containers to set up, and iCloud services to connect. Last week I’ve been tackling this more methodically, and here use two launches of a simple command tool to give clearer insights into what’s going on when macOS runs its security checks.

Methods

The command tool in question is my blowhole, just over 200 KB of simple code to write a message to the log, hence directly telling us when it’s run. It has its signing certificate embedded into its Mach-O binary, and is notarized. However, because it’s a single binary and not an app bundle, its notarization ticket is stapled to its installer package, and not to the tool itself.

The two runs I analyse here are:

• On a Mac Studio M1 Max running macOS Ventura 13.4.1 at 14:32 on 4 July 2023. blowhole had already been installed on that Mac, but the copy being run was in a previously unknown location, ~/Documents, which normally forces macOS to perform more extensive security checks, including an XProtect scan and notarization checks, but not as thorough as when in quarantine.
• On a Mac mini M4 Pro running macOS Sequoia 15.4.1 at 20:07 on 2 May 2025. Although blowhole had been installed and run some weeks previously, it hadn’t been run since then, and was expected to attract more extensive security checks, including an XProtect scan and notarization checks, but not as thorough as when in quarantine.

The first of those was collected using Ulbow, and the second by LogUI. Excerpts giving milestone entries are given in the Appendix at the end. In the diagrams below, each milestone is given with time in seconds elapsed since the first mention of the binary.

Ventura

First mention of the tool to be run comes from AppleMobileFileIntegrity (AMFI), which leads immediately to its daemon amfid starting its assessment of the binary, with the entry SecTrustEvaluateIfNecessary to inspect the signature and the CDHashes it contains. As this takes a mere 0.003 seconds, and the next stage starts 0.01 seconds after amfid entered the path to the binary, all that could have done was confirm the integrity of the signature, its requirements, and that its hashes were already cached.

syspolicyd then records the start of the Gatekeeper process assessment, and initiates the Gatekeeper scan, first starting checks on the notarization ticket, then starting the XProtect scan while ticket checking proceeds. Of those, the XProtect scan completes first, returning its results to syspolicyd at 0.054 seconds after the start.

Ticket checking involves an explicit connection to iCloud using CloudKit, with abundant log entries. The CloudKit Ticket Store is found to be reachable, and the ticket checked for the CDHashes obtained earlier from the tool’s signature.

With both checks completed satisfactorily, at 0.192 seconds the Gatekeeper scan is declared complete, syspolicyd evaluates its result, and is almost ready for the tool to run. Before that can happen, details of the executable are entered into provenance tracking. syspolicyd confirms the evaluation allows the tool to run, and AppleSystemPolicy records the evaluation result.

Sequoia

The sequence here is very similar to that in Ventura, with some significant differences, marked in the emphasised items in the diagram above.

First, there’s a substantial delay of 0.063 seconds between amfid entering the binary’s path and the start of the Gatekeeper process assessment. This started with entries from amfid recording SecTrustEvaluateIfNecessary and trustd SecKeyVerifySignature, indicating that more took place here than in Ventura. However, there’s no evidence of any external signature checks being made, and it’s most likely that the binary’s hashes weren’t cached, so required recomputation to verify them. The delay is woefully inadequate for any form of malware scan to have taken place at this stage.

When XprotectService reports that XProtect is performing the malware scan, it additionally reports the location of the XProtect rules being used. That’s because Sequoia introduced a new location used for those data files, in /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara as recorded here.

Next, the XProtect scan here takes 0.126 seconds, rather than 0.030 seconds in Ventura. This is the result of the huge growth in the number and complexity of the Yara rules used for this scan over the last two years. The Ventura scan was performed using version 2168 of those rules, with a Yara file of 147 KB size and around 218 rules. By version 5296 used in the Sequoia scan, file size had risen to 947 KB with about 381 rules.

Size of the binary being scanned also affects scan time, although in an unexpected way. A great many of the Yara rules used include upper limits to file size, so those larger than a few MB are subject to few rules, probably intentionally. Thus, larger binary files are likely to complete their XProtect scan in shorter time than expected, and maybe more quickly than smaller binaries.

As a result of these two delays, Gatekeeper’s XProtect results aren’t reported until 0.247 seconds have elapsed since the start, already over 0.05 seconds longer than the whole process in Ventura. However, in this case there’s no mention of provenance tracking, and the blowhole tool is finally run after 0.3 seconds, taking just over 150% of the time in Ventura.

Summary of security checks

• Trust evaluation and signature verification, to confirm hashes and CDHashes if not cached;
• Gatekeeper scan, including simultaneous ticket check and XProtect malware scan;
• CDHash ticket check online using CloudKit with iCloud Ticket Store;
• XProtect malware scan against Yara rules;
• Gatekeeper evaluation for syspolicyd to allow or not;
• Result registered with the kernel;
• Command tool run.

Note that there’s no evidence of any OCSP checks being made with the certificate authority to determine whether certificates have been revoked. Additional time will be required if hashes and CDHashes are to be recomputed, and as a result of increased Yara rules.

Appendix: Log Milestones

Times are given in seconds, adjusted to a start of 0.0. The Ventura extract was obtained with log privacy disabled.

Ventura 13.4.1 2023-07-04 14:32:40 on Mac Studio M1 Max

XProtect version 2168, Yara file 147 KB, 218 rules
0.000000 AppleMobileFileIntegrity Checking in with amfid for DER co.eclecticlight.blowhole
0.001395 amfid Entering OSX path for /Users/howardoakley/Documents/blowhole
0.010608 syspolicyd GK process assessment: /Users/howardoakley/Documents/blowhole <-- (/bin/zsh, /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal)
0.022891 syspolicyd GK performScan: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null))
0.023291 syspolicyd looking up ticket: {length = 20, bytes = 0xe0cad936293cea0807ec2e5193bed5f3f02dc019}, 2, 1
0.023316 syspolicyd cloudkit record fetch: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, 2/2/e0cad936293cea0807ec2e5193bed5f3f02dc019
0.023554 XprotectService Xprotect is performing a direct malware and dylib scan: /Users/howardoakley/Documents/blowhole
0.053971 syspolicyd GK Xprotect results: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null)), {
XProtectMalwareType = 0;
XProtectSignatureVersion = 4321574501753746074;
}, version: 4321574501753746074
0.170283 syspolicyd CKTicketStore network reachability: 1, Wed Jun 21 19:33:35 2023
0.191576 syspolicyd GK scan complete: PST: (path: /Users/howardoakley/Documents/blowhole), (team: (null)), (id: (null)), (bundle_id: (null)), 4, 4, 0
0.191797 syspolicyd GK evaluateScanResult: 2, PST: (path: /Users/howardoakley/Documents/blowhole), (team: QWY4LRW926), (id: co.eclecticlight.blowhole), (bundle_id: NOT_A_BUNDLE), 0, 0, 1, 0, 4, 4, 0
0.191996 syspolicyd Putting executable into provenance with metadata: TA(917fa0aed8a1a838, 0)
0.191999 syspolicyd Putting process into provenance tracking with metadata: 1410, TA(917fa0aed8a1a838, 0)
0.192054 syspolicyd GK eval - was allowed: 1, show prompt: 0
0.192090 AppleSystemPolicy evaluation result: 17, allowed, cache, 1688477560
0.195467 blowhole Blowhole snorted!

Sequoia 15.4.1 2025-05-02 20:07:00 on Mac mini M4 Pro

XProtect version 5296, Yara file 947 KB, 381 rules
0.000 amfid Entering OSX path for /usr/local/bin/blowhole
0.063 syspolicyd GK process assessment: <private> <-- (<private>, <private>)
0.081 syspolicyd GK performScan: PST: (path: cc151acaee5bc8cd), (team: (null)), (id: (null)), (bundle_id: (null))
0.082 syspolicyd looking up ticket: <private>, 2, 1
0.082 syspolicyd cloudkit record fetch: <private>, <private>
0.121 XprotectService Xprotect is performing a direct malware and dylib scan: <private>
0.125 XprotectService Using XProtect rules location: /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara
0.247 syspolicyd GK Xprotect results: PST: (path: cc151acaee5bc8cd), (team: (null)), (id: (null)), (bundle_id: (null)), XPScan: 0,1089725382763820427,2025-05-02 19:07:00 +0000,(null),(null),file:///usr/local/bin/blowhole
0.283 syspolicyd CKTicketStore network reachability: 1, Fri May 2 17:21:52 2025
0.293 syspolicyd GK scan complete: PST: (path: cc151acaee5bc8cd), (team: (null)), (id: (null)), (bundle_id: (null)), 4, 4, 0
0.295 syspolicyd GK evaluateScanResult: 2, PST: (path: cc151acaee5bc8cd), (team: QWY4LRW926), (id: co.eclecticlight.blowhole), (bundle_id: NOT_A_BUNDLE), 0, 0, 1, 0, 4, 4, 0
0.296 syspolicyd GK eval - was allowed: 1, show prompt: 0
0.296 kernel evaluation result: 5, exec, allowed, cache, 1746212820, 4, 4, f1f7b76465d358b, 1746212820, /usr/local/bin/blowhole
0.303 blowhole Blowhole snorted!

For comparison, Catalina’s log entries are remarkably similar too.

I looked in the macOS cupboard last week and opened yet another can of worms, in those Macs that take many seconds or even minutes to launch some apps. In common with many other thorny problems, there’s little consensus about many of the details, other than this mostly affecting Intel Macs running macOS Big Sur or later, although I have seen reports of similar problems in M1 Macs.

Although some have apparently found solutions, such as Jeff Johnson’s recommendation to disable SIP, the only consistent answer appears to be moving the app to another location and moving it back again. Even that’s only a temporary measure, and sooner or later those apps will launch slowly again.

Last week I thought I might have a chance to get to the bottom of the problem, when Kristian kindly sent me some log extracts from his Mac’s slow launches, and patterns started to emerge. But like every other good can of worms, the deeper I dig into the can, the more worms there are. This article is a convenient opportunity to reveal some of those.

What takes time?

Looking at three test launches of Pages, greatest differences were seen in the time taken to check the many frameworks in the app bundle, shown in purple in the bar chart below.

In the slow launch provided by Kristian, total time was just over 4 seconds, within which checking frameworks took 3.2 seconds, 80% of launch time. A similarly slow launch in my test VM took just over 3 seconds, with 2.5 seconds on frameworks, while a fast launch completed in just over half a second, with less than 0.1 seconds spent in framework checks.

Cache misses and SIP

What I didn’t mention in those log extracts was the role of cache misses in framework checks in the slower launches. At that stage, it looked as if differences were down to whether each framework had to be checked from scratch as its previous assessment couldn’t be found in cached security checks.

I have therefore repeated the VM tests in two further conditions, with SIP disabled, and with Gatekeeper/XProtect checks disabled.

When launched after a restart, with SIP fully disabled, Pages did indeed launch quickly, in a total time of 0.34 seconds with less than 0.05 seconds checking frameworks. However, disabling Gatekeeper resulted in a total launch time that was only slightly quicker than normal at 2.4 seconds, and 1.8 seconds checking frameworks.

Behaviour with SIP turned off was odd, in that no Gatekeeper process assessment was recorded, and there was no mention of any cache misses for framework checks. In contrast, when Gatekeeper was turned off, there was a Gatekeeper process assessment using a previous code evaluation, and cache misses were recorded for all the frameworks checked. My previous experience with disabling Gatekeeper is that its checks still take place and are logged normally, but their results are ignored, so that wasn’t as paradoxical as it might appear.

Calibre

Pages is an atypical example, being an App Store app signed by Apple, so I then turned to the other log record provided by Kristian, from Calibre. This is remarkable for having 68 frameworks, and took a total of 4.6 seconds to launch on his Mac, with nearly 4.4 seconds of that spent checking those frameworks, all of which were cache misses and reported with constraint violations by amfid.

When I tried repeating this in my test VM and with SIP or Gatekeeper disabled, results became far more complicated, so I have summarised them in a table.

Rows in this table record results from each of six launches of the current release of Calibre. The first is that obtained by Kristian on his Mac, the remainder are all obtained from a 4-core VM running macOS 14.7.5 on a Mac mini M4 Pro. Those were:

• first run after installation, with the quarantine flag set;
• second run a minute or so after that first run, without a restart;
• third run after closing the VM and starting it up again;
• after downgrading security to permissive by disabling SIP completely;
• after disabling Gatekeeper/XProtect checks, but still at Full Security, with SIP enabled.

Total launch time is measured from the initial click in the Finder to the app loading its preferences. Time checking frameworks is measured from the start of the first check called by amfid on one of Calibre’s frameworks, to the completion of the its check on the last framework. XProtect scan is measured between the announcement of the start of Gatekeeper’s XProtect scan, and its completion.

The fastest launch by far was in the second run, when none of the checks were performed, there were hardly any log entries from security subsystems or processes, and it completed in 0.158 seconds. The slowest was the first run, when the XProtect scan took over 6 seconds, and accounted for 77% of the total launch time of almost 8 seconds.

Remaining results fall into two groups: Kristian’s original slow launch, with almost 4.4 seconds taken checking frameworks, all of them being recorded as cache misses, and the three VM tests. The latter were remarkable as launch time was uniform at just over 0.5 seconds, and a fifth of the time spent checking frameworks. That occurred because macOS proceeded to run the app before checking of frameworks was complete. In those three tests, no cache misses were recorded, and time was independent of whether a previous Gatekeeper assessment was used. Two of them even included brief local checks against the app’s notarization ticket.

Neither disabling SIP nor disabling Gatekeeper had any effect on the time taken to check frameworks, nor on the total time taken to launch the app.

Diagnosing slow launches

I have given details of my results because, if there’s one thing they demonstrate, it’s the complexity of determining app launch times. In Pages, much of the delay seems to result from cache misses slowing framework checks, and disabling SIP restored rapid launching, as Jeff Johnson reported. In Calibre, launches proceed without waiting for framework checks to complete, and disabling SIP doesn’t result in any acceleration.

This reflects the complexity of app launch. I’ve here concentrated on security checks, as they have been most commonly blamed for this problem. Other processes that have to be completed during launch include:

• LaunchServices registration and coordination
• RunningBoard registration and resource management
• TCC privacy controls
• sandbox and container preparation
• iCloud connection
• checks for app updates
• all other app initialisations

several of which can involve their own security checks.

Although most of those are well recorded in log entries, disentangling them when watching Activity Monitor or in spindumps is more demanding, and there’s ample opportunity to gain false impressions.

But none of these tests or logs represent what happens in the slowest of launches that can take several minutes. Even the 8 seconds total launch time taken on Calibre’s first run pales in comparison to the 300 seconds that some report. There’s a difference of two orders of magnitude, suggesting that really long launch times are different from all the observations and measurements here. There must be something seriously wrong for an app to take several minutes to launch. Investigating that is also a great challenge.

Tackling slow launching

Results above demonstrate how subtle factors can result in fairly modest apps launching in anything from less than 0.2 to almost 8 seconds. If an app regularly takes several seconds to launch, and that irks you, try pre-warming it first. Longer times are more likely to occur after a Mac has been started up from cold, and apps usually launch fastest when they’ve already been run in the same session. Even if your Mac doesn’t have sufficient memory to leave that app running, that could make subsequent launches quicker.

If an app not infrequently takes more than 30 seconds to launch, then finding the cause becomes more important, and if it takes several minutes, you really need to investigate further.

Capturing an excerpt of the whole log for several minutes isn’t going to help, but will just overwhelm you with many MB of inscrutable data. If you know your way around spindumps, you may find them helpful, although they too can only cover brief periods of time. There are some basic steps you can take that can also help you diagnose and address performance problems more generally:

• Measure launch time carefully and record it. Counting icon bounces in the Dock is better than nothing, and gives you an objective measure of time to launch.
• Try in Safe mode. That disables most customising software, and any improvement in launch times points the finger at extensions, startup items and other software you have installed.
• Create a new user and see if that account has the same problems. This can detect user-specific customisations that might be the cause.
• Build an external bootable SSD with a ‘clean’ system, install the app(s) there, start up from it, and see whether it still launches as slowly. You can also try this using a more recent version of macOS, to see whether that helps.

The best way to preserve a record of what happened during a slow launch is to wait until the app is running properly, then perform a sysdiagnose, as that saves much of the log in a logarchive. You can initiate that in the Options … popup menu in Activity Monitor, or by pressing Command-Option-Control Shift-. (period or full stop). That logarchive can be browsed using Ulbow or even Console, but not (yet) LogUI.

I’m also keen to look at log records from one of these much slower launches. If you’re interested in cooperating, please comment below or send me an email (see the About page).

With well over 400 app extensions and plugins managed by PlugInKit in Sequoia 15.4.1, this article tries to give an overview of their management and control, as well as the diversity of their functions. This follows:

• a general introduction
• an account of discovery and management by PlugInKit
• AppexIndexer to examine appexes known to PlugInKit
• Apple’s appex Home page for developers.

Appex types

Although Apple refers to the type identifier for appexes as NSExtensionPointIdentifier in its developer documentation, where it lists some of them, in macOS this is also synonymous with NSExtensionPointName. In pluginkit dumps, it’s referred to as the SDK, and LaunchServices dumps use both terms, NSExtensionPointName in NSExtensionsAttributes, and NSExtensionPointIdentifier in NSExtension. This is even more confused in the log, where PlugInKit’s entries use the term NSExtensionPointName, but use NSExtensionIdentifier to refer instead to the appex-specific identifier, such as com.apple.iCal.CalendarWidgetExtension.

For the sake of clarity and consistency here, I’ll refer to the appex type identifier as NSExtensionPointName.

Appex locations

Many appexes supplied in macOS are stored as bundles inside dedicated collections such as /System/Library/ExtensionKit/Extensions or in frameworks. Where they are supplied in an app or similar bundle, they’re normally in a PlugIns folder, although according to this article QuickLook generators should be installed in Library/QuickLook, and Spotlight importers in Library/Spotlight.

Types and management

The rest of this article lists appex types, omitting the universal prefix com.apple., according to their management and discovery by PlugInKit during startup. I provide for each, as far as I’m able to tell, the type-specific manager, any controls provided in System Settings or elsewhere, and illustrative examples and other relevant information.

Type-specific managers are those services or subsystems that PlugInKit hands over to during discovery. For example, when it discovers appexes that extend QuickLook by providing either thumbnails or previews, PlugInKit hands those over to com.apple.quicklook.ThumbnailsAgent to manage.

Many appex types aren’t exposed in System Settings, are managed by PlugInKit, but don’t appear to undergo startup discovery. I have relegated those to the appendix at the end. Most of those are single-appex types, and others are only used by macOS.

Appex types that are managed in System Settings and by PlugInKit, and undergo startup discovery:

• FinderSync, managed by the Finder, and controlled in File Providers settings, e.g. Keka Finder Integration
• quicklook.preview, managed by com.apple.quicklook.ThumbnailsAgent, and controlled in Quick Look settings; these are modern substitutes for qlgenerators
• quicklook.thumbnail, managed by com.apple.quicklook.ThumbnailsAgent, and controlled in Quick Look settings; these are modern substitutes for qlgenerators
• ui-services, managed by the Finder, and controlled in Actions settings, includes Markup, ShareSheetUI (not exposed in settings)

Appex types that aren’t managed in System Settings, but are managed by PlugInKit, and undergo startup discovery:

• AppSSO.idp-extension, managed by AppSSOAgent, includes Kerberos and Sign In With Apple; these are single-sign-on extensions
• appstored-services.testflight, managed by appstoreagent; these handle App Store TestFlight
• AudioUnit, managed by AudioComponentRegistrar and axassetsd, for WardaSynthesizer
• AudioUnit-Speech, managed by AudioComponentRegistrar and axassetsd, include KonaSynthesizer and AUSPs
• AudioUnit-UI, managed by AudioComponentRegistrar
• cache_delete_extension, managed by deleted; these support app-specific cache management
• contacts.donation, managed by contactsdonationagent; these exchange info with Contacts
• ctk-tokens, managed by ctkd, include CryptoTokenKit and PlatformSSOToken; these handle tokens for CryptoTokenKit
• diagnosticextensions-service, managed by ControlCenter and diagnosticextensionsd, includes many service-specific Diagnostic Extensions
• email.extension, managed by maild, e.g. SpamSieve; these are Mail plugins
• fileprovider-nonui, managed by the Finder, includes iCloud Drive and PhotosFileProvider
• services, managed by the Finder; none listed
• spotlight.import, managed by mdbulkimport, includes PDFImporter
• spotlight.index, managed by corespotlightd, includes system extensions but not mdimporters
• textinputmethod-services, managed by imklaunchagent, includes many Input Methods
• usernotifications.content-extension, managed by NotificationCenter, includes ContentExtensions
• widgetkit-extension, managed by chronod, includes system and third-party widgets.

Significant appex types that are managed by PlugInKit, but don’t undergo startup discovery:

• appintents-extension, multiple instances
• intents-service, many IntentsExtensions
• photo-editing, Photos editing, controlled in Photos Editing settings
• Safari.extension, Safari extensions, managed in Safari settings
• share-services, many Share extensions, managed in Sharing settings
• widget-extension, only a couple, e.g. iStat Menus.

Appex types that apparently aren’t managed by PlugInKit, but are controlled in System Settings:

• Dock Tiles
• Finder, these are services offered in the Finder’s Services menu
• Spotlight, these are mdimporters.

also Safari.content-blocker, which is managed in Safari settings rather than System Settings.

Appex types that aren’t apparently managed by PlugInKit or controlled in System Settings:

• authentication-services-account-authentication-modification-ui
• authentication-services-credential-provider-ui
• broadcast-services-setupui
• broadcast-services-upload
• callkit.call-directory
• classkit.context-provider
• dt.Xcode.extension.source-editor
• fileprovider-actionsui
• identitylookup.classification-ui
• identitylookup.message-filter
• intents-ui-service
• keyboard-service
• networkextension.app-proxy
• photo-project
• tv-top-shelf

Appendix:

Appex types that aren’t exposed in System Settings, are managed by PlugInKit, but don’t undergo startup discovery

System, multiple appexes:
followup-extension – multiple FollowUpExtensions
lighthouse.SAOrchestratedExtension – multiple Ingestors
message-payload-provider – multiple
mlhost.worker – many ML-related
mlruntime.extension-point-high
mlruntime.extension-point-ondemand
mlruntime.extension-point-restricted
screensaver – several ScreenSavers
Settings.extension.ui – System Settings
storagemanagement – many apps
usernotifications.service – several NotificationServiceExtensions
wallpaper – several Wallpapers

System, single-app extensions:
amsengagementd-extension – Books, News
amsutility-extension – News
app.non-ui-extension – Swift Playground
app.non-ui-extension.multiple-instances – Swift Playground
app.ui-extension.multiple-instances – Swift Playground
applemediaservices.extensions.compose-review – ComposeReviewExtension
askpermission-extension – App Store related
askto.extension – AskToMessagesHost
calendar.EventKitUIRemoteUIService – EventKitUIRemoteUIExtension
calendar.virtualconference – FaceTimeExtension
contact-view – System Service
contacts.avatar-picker-ui – AvatarPickers
deviceactivity.monitor-extension – ScreenTimeDeviceActivityMonitorExtension
deviceactivityui.report-service – DeviceActivityReportService
extension-view-service-sample-rk – RPVideoEditorExtension_macOS, ReplayKit
extensionkit.app-extension-management – AppExtensionManagement
extensionkit.app-extension-settings – ExtensionKit components
facetime.notification – FaceTimeNotificationExtension
feedback.drafting-extension – Feedback
freeform.USD-renderer-remote-UI – USDRendererExtension
fskit.fsmodule – exfat and msdos file systems (File System Extensions)
GenerativePlaygroundUI.remoteUI – Image Playground
groupactivities – FaceTime RemotePeoplePicker
Home.ui-extension.userList – HomeUIUserList
ImagePlayground.NonUIExtension – GPNonUIExtension
ManagedSettings.service – ManagedClientMSExtension
mapkit.private.RemoteUI – MKRemoteUI for MapKit
mobileslideshow.photo-picker – PhotoPicker and PhotosPicker
networkextension.packet-tunnel – network extensions
PaperKit.extension.ui – PaperKitExtension
PassKit.in-app-payment-ui – Wallet
pdfkit-private – PDFExtensionView in PDFKit
people-picker – System Service
people.legacy.extension – PeopleLegacyMessageService
Photos.MacMusicPickerExtension – PhotosMacMusicPickerExtension
preference.security.privacy – Apple Advertising
preference.sharing.service – Media Sharing
private.translation-api-support – TranslationAPISupportExtension
private.translation-ui – Translate
private.voiceshortcuts-ui – three extensions
replaykit.broadcast-picker – RPBroadcastActivityExtension_macOS in ReplayKit
screentime.web-service – ScreenTimeWebExtension.

For at least the last couple of years, folk have complained that launching some apps takes forever. It has been common for some to take several seconds of bouncing icon time in the Dock, and in a few cases larger apps can take more than 30 seconds to launch. This has been ascribed to ‘security checks’, with some claiming it’s because of delays in online checks of certificates, others attributing it to XProtect, or something else. This article, based on log extracts generously provided by Kristian, demonstrates what’s really holding up these apps.

App launch in Sonoma & Sequoia

I have written at length in previous articles about what happens during app launch in Sonoma 14.6.1 and Sequoia (links at the end). Although there are significant differences, I concentrate here on 14.6.1, as the crucial log records from Kristian are from Sonoma, and its analysis has been more extensive. Key steps are summarised in the diagram below.

For the sake of simplicity here, I’ll confine this article to launching known apps that aren’t in quarantine, and look in particular at Pages, which isn’t notarized, so will behave slightly differently.

Slow Pages

Launch starts with the click action triggering LaunchServices to start launching the app
16.924 Finder sendAction:
16.927 com.apple.launchservices LAUNCH: Opening <private> with 0 items on behalf of 436 role=e flags=8000001 (null)
and LaunchServices then hands the launch over to RunningBoard
16.941 com.apple.launchservices LAUNCH: _LSLaunchThruRunningboard: com.apple.iWork.Pages / <private>

Security checks start early, with amfid
16.966 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
16.969 amfid SecTrustEvaluateIfNecessary
Then, in accordance with system security policy, a Gatekeeper assessment is started
17.031 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
17.031 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>

The security system recognises that the code has already been evaluated, so uses the results from that, and its Gatekeeper scan result returns within 0.01 seconds
17.041 com.apple.syspolicy.exec Code already evaluated, using results.
17.041 com.apple.syspolicy.exec scan returning quickly for code: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
17.041 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
17.041 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))

So around 0.075 seconds after starting the security assessment, and only 0.117 seconds after double-clicking to launch the app, it looks like it has approval to proceed. But that doesn’t take into account the frameworks the app bundle contains. There are 17 of those that need to be evaluated before launch can proceed. Each is reported with distinctive lines like
17.564 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
17.567 amfid SecTrustEvaluateIfNecessary
the last of which isn’t reported until 20.593 seconds elapsed time, that’s 3.55 seconds after we thought security evaluation was complete, and over 3.6 seconds since the double-click.

From then until Pages opens its preferences with the log entry
20.998 Pages Loading Preferences From User CFPrefsD
is another 0.3 seconds, making a total launch time of just over 4 seconds, of which almost 90% was spend checking frameworks.

Performing the same launch in a VM running macOS 14.7.5 on 4 P cores with 16 GB memory on an M4 Pro host is a little faster, and only takes 2.5 seconds to check its frameworks.

Fast Pages

Launching Pages in a Mac mini M4 Pro running Sequoia 15.4.1 is, as you’d expect, significantly quicker. Tracing corresponding log entries reveals where much of the time is saved.

00.513 Finder sendAction:
00.715 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
00.741 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
00.741 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>

00.751 com.apple.syspolicy.exec Code already evaluated, using results.
00.751 com.apple.syspolicy.exec scan returning quickly for code: PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
00.751 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
00.751 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))

Framework checks start with
00.772 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
00.773 amfid SecKeyVerifySignature
and progress through to
00.843 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/AppleMediaServicesKit.framework/Versions/A/AppleMediaServicesKit
00.843 amfid SecKeyVerifySignature
with Pages opening its preferences at the end
01.087 Pages Loading Preferences From User CFPrefsD

Here, framework checks took a mere 0.07 seconds, and the total time from double-click to preferences was only 0.574 seconds.

Slow Calibre

Pages is an example of an app that completed its security checks without error or problems. Many of the apps that can be slowest to launch have additional problems, as shown in Calibre.

Progress through early checks proceeds briskly:
31.505 Finder sendAction:
31.567 com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
31.576 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 937222), (team: NTY7FVCEKP), (id: net.kovidgoyal.calibre), (bundle_id: (null)), 0, 0, 1, 0, 4, 4, 0

But when its frameworks come up for checking, there’s a problem reported in every one of them
31.614 kernel AMFI: constraint violation /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib has entitlements but is not a main binary
31.614 amfid Entering OSX path for /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib
31.615 amfid SecTrustEvaluateIfNecessary

AMFI runs a total of 68 checks on those frameworks in the app bundle before reaching the last
35.988 kernel AMFI: constraint violation /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib has entitlements but is not a main binary
35.989 amfid Entering OSX path for /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib
35.989 amfid SecTrustEvaluateIfNecessary

And preferences are opened 4.635 seconds after the double-click
36.140 calibre Loading Preferences From User CFPrefsD

Workarounds

Many different workarounds have been proposed blindly to tackle a problem that doesn’t appear to have properly diagnosed in the first place. I believe that it is possible, although difficult, to disable AMFI, but that’s like going out, leaving your front door wide open, and telling everyone you meet to go in and help themselves. Without AMFI’s protection, your Mac is a sitting duck.

As these framework checks are occurring outside Gatekeeper, and without XProtect even being thought about, mutilating any other part of your Mac’s security systems isn’t going to achieve anything other than exposing it to increased risk. Some report subjectively that moving apps around can bring relief, but it seems temporary, as ultimately AMFI will get those frameworks whatever you try to do with them. And so it should, if you want your Mac to remain secure.

I’ve seen no evidence that this is a bug, nor that it’s ‘fixed’ in Sequoia, which it isn’t. At first I suspected it might have been exacerbated or unmasked by launching apps using other apps, rather than in the Finder, but that’s not true either. What is abundantly clear from my results above is that a faster Apple silicon Mac does the trick, but please don’t misinterpret that as designing security to encourage users to upgrade to newer models, which simply doesn’t follow.

Conclusions

• Significant delays in launching apps can result from security checks of their frameworks.
• Known apps that aren’t in quarantine don’t normally undergo online certificate checks or XProtect scans, and normally complete Gatekeeper checks swiftly.
• The most likely cause of delayed launching of a known app that isn’t in quarantine is protracted security checks of its frameworks.
• Those delays are usually negligible in more recent Apple silicon Macs.
• There doesn’t appear to be any lasting workaround to expedite launch.
• Investigating delayed launches requires careful log analysis.

References

Sequoia
Sonoma 14.6.1 Full Security
Sonoma 14.6.1 Conclusions

Once again, I’d like to acknowledge the invaluable help of Kristian, who provided the slow log extracts and helpful discussion.

Apple has just released an urgent security update to macOS Sequoia to bring it to version 15.4.1. There are no matching security updates for Sonoma or Ventura.

This is claimed to install more reliably on those M1 and other Macs that struggled or failed to update to 15.4. However, it still terminates early with a kernel panic on some Apple silicon Virtual Machines.

For Apple silicon Macs the download is about 1.8 GB in size, and a mere 840 MB or so for Intel Macs.

This fixes two vulnerabilities in CoreAudio and RPAC that appear to have been exploited already in “an extremely sophisticated attack against targeted individuals on iOS” according to Apple’s security release notes.

macOS 15.4.1 has a build number of 24E263, and Safari is unchanged with a version number of 18.4 (20621.1.15.11.10). There are no changes in iBoot firmware for Apple silicon Macs, nor in firmware for Intel Macs.

Updated 1917 GMT 16 April 2025.

I’m very grateful to all of you who looked at my little AppexIndexer, and particularly to those who commented and made suggestions. I’m delighted to come back with version 1.0 build 8, which I hope gets closer to what you’ll enjoy using. Its changes include:

• Adding support for appex UUIDs. Although the log tends to censor most clues about which appex an entry is referring to, it’s more likely to give its UUID, and armed with AppexIndexer you can use that to identify the appex in question.
• Providing a range of four sort orders. These are the SDK or type, the name of its parent app, the UUID, and the appex’s display name. Once you have loaded up the list of appexes, you can switch instantly between these sort orders.
• ‘Live’ search for UUIDs, explained below.

Tools at the top of each window include the UUID search box at the top right, four radio buttons at the left to switch between sort orders, and checkboxes for the two content options of showing appex and parent paths, and UUIDs. Start by clicking on the Get Appexes button to populate the window, then you can set it up how you want.

To help distinguish the name of parent apps, there’s a ‘parent’ emoji preceding each. You’ll also notice that SDKs shown now omit the standard com.apple. opening, as that is universal.

As before, AppexIndexer supports mixtures of continuous and discontinuous selection. Copy those you want, and they’ll paste as text containing all the available fields, not just those being displayed at the time.

Search was quite a challenge, and my solution is inspired by that explained by Tiago Gomes Pereira in his Create with Swift blog.

SwiftUI Search on Lists and similar is nothing like macOS Find, and is better-suited to displaying those entries that match in a single field rather than in all their text content. With its new sort options, AppexIndexer should be quick and simple to locate appexes by all criteria except UUID. Rather than requiring the user to paste in the UUID they want to find, this ‘live’ search should produce perfect matches when you’ve only typed in a few characters from the target UUID. Those don’t have to be characters from the start, but can be any from within the UUID. For example, to find the appex with a UUID of E1366424-89DD-4CEB-85D8-C8E00928313F, you could start typing in e1366, or c8e00, etc., as you wish. You don’t need to use capitals either.

Typing the first couple of characters should narrow the list down quickly, and by the third or fourth you should have a perfect match. If you want to return to the full list of appexes, select that appex entry and empty the search box by clicking on the X button at its right and just that single entry will be selected in the full list.

If you type in an incorrect character, you’ll be informed that no results could be found.

AppexIndexer 1.0 build 8 is now available from here: appexindexer108
I’m afraid that it still requires Sonoma 14.6 or later, but hope that you find it efficient in use and a good tool for exploring appexes.

Enjoy!