Mac app launches slowed by malware scan (2024)(lapcatsoftware.com)
lapcatsoftware.com
Mac app launches slowed by malware scan (2024)
https://lapcatsoftware.com/articles/2024/2/3.html
Follow-up: https://lapcatsoftware.com/articles/2025/5/1.html
33 comments
I’ve got a personal project compiler I built and it’s hit by this very hard. Testing involves (naturally) generating lots of executables. Running it in a Linux docker container takes around ~1s for all 500 tests. macOS by default takes around a _minute_, and even with the workarounds I’ve found (“allow untrusted software to be run by iterm2”) it takes 5-8 seconds.
It’s a pretty niche use case but it’s deeply frustrating
It’s a pretty niche use case but it’s deeply frustrating
Related, I found that even after designating an application (iTerm2) as a "Developer Tool" in System Settings -> Privacy & Security, there were circumstances where notarisation checks were still carried out. Particularly, launching tmux then detaching and reattaching would cause the processes to no longer be exempt. This applies to any executable (+x), including shell scripts. I put together a test script that proves it at https://gist.github.com/davebarkerxyz/4111276ae1fb4a7566b271... (the second run is much quicker than the first one after a tmux reattach, but within applications marked as Developer Tools the times should be nearly identical).
Fortunately as of Sequoia (15.4.1), I'm no longer able to reproduce the issue.
Fortunately as of Sequoia (15.4.1), I'm no longer able to reproduce the issue.
EVERYBODY: You can fix the Affinity slow start-up problem on MacOS in a simple step:
Go to your App folder and duplicate the "Affinity Photo 2" app. Then remove the original and use the duplicate.
Now Affinity starts in 2 seconds instead of in 30 seconds on my M3 machine.
Go to your App folder and duplicate the "Affinity Photo 2" app. Then remove the original and use the duplicate.
Now Affinity starts in 2 seconds instead of in 30 seconds on my M3 machine.
I'd legitimately love to know why this has worked wtf
Does this still load as fast. I have found that, after you have run the app once, it will load very quickly for a day or so and then load more slowly again. I believe that there is a cached state which does not run the slow check and which expires after a while and a new check must be run.
It has been two days since I ran Affinity Photo, latest version, and it took about 30 sec to load.
It has been two days since I ran Affinity Photo, latest version, and it took about 30 sec to load.
This fixes the problem permanently.
Why does this work?
I have no idea. I found it deeply buried in a support forum the other day.
I think I checked this once and it was doing Rosetta translation
I just updated to the latest version and Affinity Photo 2 opens in seconds now.
I bet you could get the same results by duplicating the inner binary only rather than the whole folder. I saw something very similar with terminal apps.
The blog post doesn't mention this app - am I missing something?
The blog post doesn't mention this app - am I missing something?
The follow up blog post published today mentions Affinity. It's also one of the worst apps to start slowly on macos.
I think this needs blog post and a much deeper explanation.
> 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 always assumed this had to be the case? When you first launch an application gatekeeper takes a long time verifying it, but on subsequent launches it's fast. So _some_ bit seems to be stored somewhere indicating whether or not this is "first launch" and whether full verification needs to be performed (maybe it's the launch services cache?)
As for whether the entire image is verified before _each_ launch, I'm not 100% familiar with the flow but I don't think that's correct, it can be done lazily on a page by page basis. https://developer.apple.com/documentation/endpointsecurity/e...
>In the specific case of process execution, this is after the exec completes in the kernel, but before any code in the process starts executing. At that point, XNU has validated the signature itself and has verified that the cdhash is correct. This second validation means that the hash of all individual page hashes in the Code Directory match the signed cdhash, essentially verifying the signature wasn’t tampered with. However, XNU doesn’t verify individual page hashes until the binary executes and pages in the corresponding pages. XNU doesn’t determine a binary shows signs of tampering until the individual pages page in, at which point XNU updates the code signing flags.
If you can replicate this on an Intel mac where code signature is optional, you could try more rigorous comparisons comparing an unsigned binary vs a signed one. In both cases I'd assume yara signature checks would apply.
I always assumed this had to be the case? When you first launch an application gatekeeper takes a long time verifying it, but on subsequent launches it's fast. So _some_ bit seems to be stored somewhere indicating whether or not this is "first launch" and whether full verification needs to be performed (maybe it's the launch services cache?)
As for whether the entire image is verified before _each_ launch, I'm not 100% familiar with the flow but I don't think that's correct, it can be done lazily on a page by page basis. https://developer.apple.com/documentation/endpointsecurity/e...
>In the specific case of process execution, this is after the exec completes in the kernel, but before any code in the process starts executing. At that point, XNU has validated the signature itself and has verified that the cdhash is correct. This second validation means that the hash of all individual page hashes in the Code Directory match the signed cdhash, essentially verifying the signature wasn’t tampered with. However, XNU doesn’t verify individual page hashes until the binary executes and pages in the corresponding pages. XNU doesn’t determine a binary shows signs of tampering until the individual pages page in, at which point XNU updates the code signing flags.
If you can replicate this on an Intel mac where code signature is optional, you could try more rigorous comparisons comparing an unsigned binary vs a signed one. In both cases I'd assume yara signature checks would apply.
> So _some_ bit seems to be stored somewhere indicating whether or not this is "first launch"
Yes, of course.
How do you go from that to "a cache of SHA-256 hashes of all bundled files of all apps that have been launched"?
Yes, of course.
How do you go from that to "a cache of SHA-256 hashes of all bundled files of all apps that have been launched"?
Isn't there some cache of code-signing info? https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS
>Specifically, the code signing information (code directory hash) is hung off the vnode within the kernel, and modifying the file behind that cache will cause problems. You need a new vnode, which means a new file, that is, a new inode. Documented in WWDC 2019 Session 703 All About Notarization - see slide 65 (PDF).
This seems to be described in https://eclecticlight.co/2024/04/29/apfs-beyond-to-vfs-and-v... but I'm just a layman here. I don't quite understand the benefits of this caching if you have to recompute them to detect mismatch anyway. [1]
And I realize now the initial gatekeeper scan is probably just controlled by presence of quarantine bit, the result themselves are probably not cached.
Edit: Now I'm not so sure, spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow. And presumably as you noted it's a cache miss for this which causes the long application launch delay.
[1] https://github.com/golang/go/issues/42684 has a bit more info on this, I'm happy to see that even seasoned experts are confused about these things.
>Specifically, the code signing information (code directory hash) is hung off the vnode within the kernel, and modifying the file behind that cache will cause problems. You need a new vnode, which means a new file, that is, a new inode. Documented in WWDC 2019 Session 703 All About Notarization - see slide 65 (PDF).
This seems to be described in https://eclecticlight.co/2024/04/29/apfs-beyond-to-vfs-and-v... but I'm just a layman here. I don't quite understand the benefits of this caching if you have to recompute them to detect mismatch anyway. [1]
And I realize now the initial gatekeeper scan is probably just controlled by presence of quarantine bit, the result themselves are probably not cached.
Edit: Now I'm not so sure, spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow. And presumably as you noted it's a cache miss for this which causes the long application launch delay.
[1] https://github.com/golang/go/issues/42684 has a bit more info on this, I'm happy to see that even seasoned experts are confused about these things.
> This seems to be described in https://eclecticlight.co/2024/04/29/apfs-beyond-to-vfs-and-v... but I'm just a layman here. I don't quite understand the benefits of this caching if you have to recompute them to detect mismatch anyway.
It appears that Howard Oakley is once again very confused. Unfortunately, his blog is sometimes a foundation of misinformation, which drives me nuts. The Apple technical note that he links to is talking about a process updating itself at runtime while its code signing information is cached by the kernel in memory. Oakley has somehow warped that into a some kind of disk cache, using the odd phrasing "saved to the kernel's cache against the vnode".
> spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow.
Yes. I think it's in /var/db? But again, it's not a cache of the hashes of every file in the app bundle. What would the system even do with that? Not only is there no evidence for the existence of such a thing, but its existence would make no practical sense. Oakley is simply grasping for something that takes a significant amount of time computationally, without giving much consideration to what would be done with the products of that computation.
> And presumably as you noted it's a cache miss for this which causes the long application launch delay.
No, I've showed that it's a periodic malware scan.
It appears that Howard Oakley is once again very confused. Unfortunately, his blog is sometimes a foundation of misinformation, which drives me nuts. The Apple technical note that he links to is talking about a process updating itself at runtime while its code signing information is cached by the kernel in memory. Oakley has somehow warped that into a some kind of disk cache, using the odd phrasing "saved to the kernel's cache against the vnode".
> spctl has a --ignore-cache option. So the result of gatekeeper is indeed cached somehow.
Yes. I think it's in /var/db? But again, it's not a cache of the hashes of every file in the app bundle. What would the system even do with that? Not only is there no evidence for the existence of such a thing, but its existence would make no practical sense. Oakley is simply grasping for something that takes a significant amount of time computationally, without giving much consideration to what would be done with the products of that computation.
> And presumably as you noted it's a cache miss for this which causes the long application launch delay.
No, I've showed that it's a periodic malware scan.
What's most amusing is that in the most recent blog post (https://eclecticlight.co/2025/04/30/why-some-apps-sometimes-...), the handful of log statements that serve as the source of the claim in fact confirm that it is syspolicyd performing a malware scan that is responsible for the delay during launch.
11.012004 com.apple.syspolicy.exec Recording cache miss for <private>
20.898736 AppleSystemPolicy Waking up reference: 174
The first of the two messages is from `syspolicyd` and is reporting 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 second log message is from the AppleSystemPolicy kernel extension when it receives the result of the malware scan and permits the process to resume execution.
It's a little puzzling that the original analysis is published based on speculation, without any real attempt at verifying that the data supports their hypothesis. Looking at `top` or Activity Monitor during the slow launch would show which process is performing work. A spindump captured during the slow launch would reveal what work it is doing. The system log store captures the process and subsystem that logged any given message. A few minutes in Binary Ninja or Hopper gives you a rough idea of what the code that emits the log is doing.
11.012004 com.apple.syspolicy.exec Recording cache miss for <private>
20.898736 AppleSystemPolicy Waking up reference: 174
The first of the two messages is from `syspolicyd` and is reporting 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 second log message is from the AppleSystemPolicy kernel extension when it receives the result of the malware scan and permits the process to resume execution.
It's a little puzzling that the original analysis is published based on speculation, without any real attempt at verifying that the data supports their hypothesis. Looking at `top` or Activity Monitor during the slow launch would show which process is performing work. A spindump captured during the slow launch would reveal what work it is doing. The system log store captures the process and subsystem that logged any given message. A few minutes in Binary Ninja or Hopper gives you a rough idea of what the code that emits the log is doing.
Oakley's brain just seems to be stuck in a loop of misunderstanding and mistaken assumptions. He gave the same bizarre response to me that he gave to you:
"The only feature in macOS that I know of that matches that description is what Apple terms XProtect, and there are only two (in Sequoia, previously one) sets of Yara rules in macOS. Now if I’m missing something, please tell me where those other Yara rules are." https://eclecticlight.co/2025/04/22/why-some-apps-launch-ver...
"Well, the only Yara rules that I know of in macOS are those in the XProtect bundle. Do you know of any others?" https://eclecticlight.co/2025/04/30/why-some-apps-sometimes-...
"The only feature in macOS that I know of that matches that description is what Apple terms XProtect, and there are only two (in Sequoia, previously one) sets of Yara rules in macOS. Now if I’m missing something, please tell me where those other Yara rules are." https://eclecticlight.co/2025/04/22/why-some-apps-launch-ver...
"Well, the only Yara rules that I know of in macOS are those in the XProtect bundle. Do you know of any others?" https://eclecticlight.co/2025/04/30/why-some-apps-sometimes-...
I wonder if this is why Fusion 360 is so slow to start. It's by far the slowest app on my relatively modern M1 MacBook Pro.
It's slow on almost everything, so I kinda doubt macOS is to blame.
Never saw a CAD app boot fast... Shapr3D is the best but something as advanced as Fusion or Solidworks has always been slow to open
> doubt that the built-in system libraries are scanned for malware, because they reside on a separate cryptographically-signed read-only disk volume.
Would be nice to be able to do the same for user apps and only scan on volume updates (when app update) instead of the current constant waste of time and energy
Would be nice to be able to do the same for user apps and only scan on volume updates (when app update) instead of the current constant waste of time and energy
TIL: MacOS ships with YARA.
syspolicyd rears its ugly head again.
Author here. It's unclear why HN is interested in this post, because it's just a response to another blogger's recent posts, which weren't even submitted to HN. Visitors aren't going to have the background context.
My original post "Mac app launches slowed by malware scan" was submitted to HN last year, though it received 0 comments at the time. https://lapcatsoftware.com/articles/2024/2/3.html
My original post "Mac app launches slowed by malware scan" was submitted to HN last year, though it received 0 comments at the time. https://lapcatsoftware.com/articles/2024/2/3.html
Submitter here. I submitted it because it explains a bug I recently encountered. Other people apparently found it useful. Should I delete it?
> Should I delete it?
Is that even possible?
Anyway, I just think my 2024 post is a better place to start, because it explains the issue directly, whereas this new post simply refutes another blogger and argues that there's nothing new beyond my 2024 post. That interpersonal drama/conflict probably isn't going to be understandable or useful to readers.
Is that even possible?
Anyway, I just think my 2024 post is a better place to start, because it explains the issue directly, whereas this new post simply refutes another blogger and argues that there's nothing new beyond my 2024 post. That interpersonal drama/conflict probably isn't going to be understandable or useful to readers.
Ok, we've switched to that from https://lapcatsoftware.com/articles/2025/5/1.html above, and I'll add a link to the follow-up to the top text.
@dang or mods can replace a main discussion link if they think its apt/good for the final user you might write to the email on the footer of this page to reach them