Why Some Apps Sometimes Launch Extremely Slowly
I can now try to explain why some apps may launch extremely slowly, occasionally taking more than 30 seconds, and on some Macs several minutes.
[…]
Log entries don’t provide any information as to what SecTrustEvaluateIfNecessary is likely to perform on these frameworks that can take anything from 0.03-9.96 seconds for each framework.
[…]
The most likely activity to account for these long checking times is computation of SHA-256 hashes for the contents of each item in the app’s Frameworks folder. Thus, these occasional extremely long launch times are most probably due to time taken ‘evaluating trust’ by computing hashes for protected code in the Frameworks folder in the app bundle, when those hashes have been flushed from their cache.
[…]
The only strategy that does appear to stop long launch times in most cases is to disable SIP and, in the case of Apple silicon Macs, to set the security mode to Permissive.
I think it used to be that, once an app passed the initial Gatekeeper check and was no longer quarantined, that was the end of the security checks. Now, Oakley has a chart showing how even code that is no longer quarantined will be rechecked if Launch Services no longer has a record of it, or if the app has been moved. Even if Launch Services does know about it, macOS will do malware and notarization checks if it doesn’t find the app in the cache.
I’m often in Activity Monitor, and a lot of what I see going on is security checks, both when launching apps and also continually checking that apps have proper access to the files they’re working with and the processes they’re sending Apple events to. Sometime I’d like to try turning off SIP and see whether everything feels snappier.
Previously:
- Mac App Launches Slowed by Malware Scan
- How Ventura Checks the Security of Apps and Tools
- Privacy and Security in macOS 14
- Apple Server Outage Makes Mac Apps Hang on Launch
- Faster Xcode Updates
- macOS 10.15: Slow by Design
Update (2025-05-05): Mark Rowe (Mastodon):
From the log snippet shared in the linked article, the delay during launch is clearly due to syspolicyd doing malware scanning.
Oakley seems to be claiming, with no empirical evidence, that Macs have a cache of SHA-256 hashes of all bundled files of all apps that have been launched. But where exactly is this cache??? I’ve never seen it or heard of such a thing.
[…]
I think the evidence suggests that what is cached is the result of a malware scan, which for practical purposes would make a lot more sense than a bunch of hashes.
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.
[…]
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.
As I see it, there are two main points: (1) the syspolicyd malware check is taking most of the CPU time during the slow app launches, as evidenced by samples, spindumps, and the like; (2) there is no on-disk cache of SHA256 hashes of app bundled files, and thus regenerating the alleged cache cannot explain the slow app launches.
One thing that is interesting is that the AppleSystemPolicy kernel extension has two separate up-calls it can make during an application’s launch. One requests a gatekeeper evaluation (also referred to as an “exec evaluation”), while the other requests a malware scan (also referred to as a “changetime scan”). If it determines the malware scan is needed it does this instead of the normal gatekeeper evaluation. Some applications seem to trigger these malware scans repeatedly.
I’m not entirely clear what the differences are between the two types of scans. The major things I have noticed are that the changetime scan appears to be slower than the exec evaluation, and the evaluation of the yara rules happens inside of
syspolicydwhen handling a changetime scan (rather than via the XProtect service).It’s worth noting that
AppleSystemPolicy/syspolicydhave additional logging that can be enabled viasudo sysctl -w security.mac.asp.logging_mode=1. Set that, killsyspolicyd, and then look atsudo log stream --debug --signpost --predicate 'sender = "syspolicyd" or sender = "AppleSystemPolicy"'while launching some infrequently-used applications.
But what subsystems in macOS are currently configured to send logging to the unified system log and how are those subsystem configured? For more details, please see below the jump.
See also this 2024 post from Jeff Johnson (Hacker News):
I finally got fed up with slow launches [of FileMerge] and decided to investigate by taking a spindump from Activity Monitor. Spindumps are a nice way to see what exactly is consuming resources on your Mac, because they show the “CPU Time” used by each process on your system and each thread in the process.
From the spindump I discovered that the slow launches are caused by the
syspolicydprocess, specificallyDispatchQueue “com.apple.security.syspolicy.yara”. The backtrace showedsyspolicydcalling theyr_rules_scan_filefunction.[…]
FileMerge is much smaller, only 2 MB. Why does that take so long? My theory is that syspolicyd also scans the launched app’s linked libraries.
[…]
Here’s a mystery: I see frequent slow launches and malware scans with Google Chrome but never with Google Chrome Beta, despite the fact that the Google Chrome beta app is about the same size as the Google Chrome app. I don’t yet have an explanation for the difference in behavior.
[…]
I’ve now confirmed that disabling SIP does indeed eliminate the
syspolicydmalware scan. Xcode launches so fast, it’s beautiful.
3 Comments RSS · Twitter · Mastodon
@Michael you could try something like this, which I just ran myself (and have also run previously).
xattr -d -r com.apple.quarantine /Applications/*
VLC.app, which is over 150 MB of compiled binary code, launched at exactly the same speed before and after, though.
I am also constantly clearing this flag from the entire Downloads folder, due to a bug going back at least 5 years now, where "Last Opened Date" will never be set on anything with a quarantine flag.
The human race is screwed, I think. For example, we will never get to explore space if this is an acceptable level of quality for software. We'll spend an astronomical amount of money, and then years later learn that some very fine men and woman perished because of something like "Keyboard Error, Press Any Key To Continue".
From the log snippet shared in the linked article, the delay during launch is clearly due to syspolicyd doing malware scanning.
The log message immediately prior to the 9 second delay is `syspolicyd` logging that it has no cached malware scan result for a file it was asked to scan. The malware scan is triggered by an up-call within the AppleSystemPolicy kernel extension during a MACF hook (`proc_notify_exec_complete`, `file_check_library_validation`, or `file_check_mmap`) if the kext doesn’t have a cached malware scan result for the vnode of the file in question.
The subsequent log message is from the AppleSystemPolicy kernel extension when it receives the result of the malware scan and permits the process to resume execution.
I don’t know why Apple makes third-party developers jump through hoops with notarization, which they claim is used to scan applications for malware, only to then ignored the notarization ticket that marks the application as having been confirmed free of malware.
