It is a little more direct than that even. The application's entitlements are passed into the interpretation of the sandbox profile. It is the sandbox profile itself that determines which policies should be applied in the resulting compiled sandbox policy based on entitlements and other factors.
An example from /System/Library/Sandbox/Profiles/application.sb, the profile that is used for App Sandboxed applications, on my system:
App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.
By far the biggest advantage of App Sandbox is that the policy ships along with the OS. If a system framework changes what resources it accesses in a software update, Apple can update the policy so the framework functionality still works. If your app uses a custom sandbox policy, you're on your own to both notice that something has changed and to update your policy.
The downside is that the App Sandbox policy is limiting and inflexible.
See https://bdash.net.nz/posts/sandboxing-on-macos/ for more details on how sandboxing works on macOS. It touches on how the SBPL Scheme source code is interpreted in userspace to build a bytcode representation of the policy, and the kernel MAC hooks that the Sandbox kernel extension uses for enforcing sandbox policies.
SSVE instructions are executed by the SME engine, which trades latency for throughput. SSVE is really intended to support use of SME, rather than as a replacement for Advanced SIMD on the CPU core itself.
The Apple Silicon CPU Optimization Guide has a lot of great information on SME and SSVE, along with more general information on optimizing for Apple's CPUs
A few quotes from Apple's guide that are particularly relevant to SSVE, from "SSVE Vector Execution Unit Optimization":
> Broadly, this unit is designed to support long vector and matrix operations performed on
ZA storage _in the SME Processing Grid_.
> Recommendation: Use SSVE in a supporting role to enable high throughput SME grid computation.
> [Magnitude: High | Applicability: High] SSVE offers wide 64B vectors. While the ISA includes instructions that can operate on multi-vectors, the throughput is often only one 64B vector per cycle. Use SSVE to enable SME, which offers higher parallelism.
> Because of non-speculative execution, communication latencies, and in some cases long memory and computation latencies, SME engine instructions trail execution in the core by dozens to thousands of cycles. Any core compute instructions that consume data produced by the SME engine may have to wait an indeterminate (but long) amount of time for the data to arrive.
That makes a ton of sense and aligns with my observations. Thanks for the resource :)
If SSVE is slow, I was hoping that SME instructions could be used in a vector-like fashion (e.g. add two matrices with high throughput, or a Hadamard/element-wise product) but it seems most matrix accelerator ISAs don't have that.
There are SME / SME2 instructions that use the ZA tiles as vector registers / vector groups. These can take advantage of the higher throughput of the SME processing grid vs SSVE instructions that operate on Z registers. See the `FMLA (SME2)` case under Peak Performance at https://scalable.uni-jena.de/opt/sme/micro.html#peak-perform....
I was struck by the "Magnitude: High | Applicability: High" bit. Who writes like this? More importantly, who reads like this? The V4 doc (which I have yet to read, but I did a text search) has 64 occurences of this sort of phrasing; not actually all that many, given that there's 293 pages, but enough to be interesting. I wonder if this extra stuff is there to make LLMs pay particular attention.
Intel's software optimization guides have similar annotations on many of their guidelines, and have done since long before LLMs were a thing. As a reader it's useful to know how impactful a given recommendation is and how generally applicable it is without having to read the more detailed explanations.
Ahh, interesting, thanks. (I read the reference manuals but typically ignore the rest... I don't need to write this stuff, just read it!) I've seen people recommend creating docs to be LLM-friendly and I was wondering if this was an instance of that.
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...
An example from /System/Library/Sandbox/Profiles/application.sb, the profile that is used for App Sandboxed applications, on my system:
reply