Strangely the WindowServer issue is a constant issue on my personal MacBook Pro, but I've never seen it on my identical work MacBook Pro. It seems like there's some other factor that is necessary to trigger the problem.
This affects some of the most widely used applications on the platform, including "productivity" applications such as Slack that Apple uses internally. How did no-one at Apple notice this and do something about it prior to macOS 26 being released?
I stopped using the Slack Electron wrapper as soon as Safari added support for "installing" web apps (File > Add to Dock…). Wouldn't be surprised if people within Apple did similar.
This made me try it out again since the feature was first released. Looks like they added support for Safari extensions and content blockers to PWAs in macOS 15.0.
It mostly seems to be deprecated to encourage developers to use App Sandbox rather than doing custom sandboxing things. With custom sandboxing baking implementation details of system frameworks into the sandbox policy is almost unavoidable, and Apple would really rather you didn't do that as it limits their ability to make changes in the future.
The underlying sandbox subsystem is what App Sandbox uses.
Apple can happily rely on implementation details of system frameworks in their policies because they can update them as the system frameworks change.
The sandbox subsystem is what all of Apple's system software uses for sandboxing, as well as many security-conscious third-party programs such as web browsers. It's not going anywhere anytime soon, despite being marked as deprecated.
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.
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...
The code snippets are purely declarative because they are reconstructed from the simple bytecode that the macOS sandbox library generates after evaluating the Scheme code. At that point any abstractions present in the source code are long gone and only predicates and actions remain.
If you look at typical SBPL source code you'll see it tends to contain a mix of straightforward, declarative `(allow …)` policies and custom functions/macros used to simplify repeated patterns. See https://github.com/WebKit/WebKit/blob/11b5279aec6113c661dac3..., for example.
When I first run locally-built software I tend to notice XProtect scanning each binary when it is launched. I know that XProtect matches the executable against a pre-downloaded list of malware signatures rather than sending data to the internet, but I haven't monitored network traffic to be sure it is purely local. You can see the malware signatures it uses at /private/var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara if you're curious.
It used to be that you could run any third-party application you downloaded. And then for a while you'd have to right-click and select Open the first time you ran an application you'd downloaded, and then click through a confirmation prompt. And macOS 15, you have to attempt to open the application, be told it is unsafe, and then manually approve it via system settings.
