Quick question about AccessoryAccess on macOS 27: I’m trying to use it from a CLI tool (packaged as a minimal .app bundle, signed with com.apple.security.device.usb), but I keep getting: Internal AccessoryAccess error. Unable to communicate with service. From the WWDC26 session it sounds like just adding the entitlement isn’t enough and the corresponding capability in “Signing & Capabilities” needs to be enabled. Is AccessoryAccess even supported for CLI-tools, or does it require a full app target?

Hi, thanks for the comment. Fortunately, I was able to create a broader test setup to verify whether RAM was affecting build performance. I tested two hosts: Host A: 32 CPU cores, 96 GB RAM Host B: 24 CPU cores, 128 GB RAM For both hosts, I ran multiple VM configurations with different CPU and RAM allocations (80% and 90% of host memory). Result: The build times, and more important the CPU usage were almost identical across all test cases. It did not seem to matter whether the build ran on a machine with more RAM but fewer CPU cores. The overall behavior was very similar on both hosts. The dropping CPU usage during the build-phase was reproducible. One interesting observation is that in the most aggressive configuration (all CPUs assigned and 90% RAM allocated to the VM), the 96 GB host showed some swap activity, while the 128 GB host did not. However, this had no noticeable impact on build performance (in both cases the CPU usage dropped). Also, increasing the VM's RAM allocation did not increase actual memory usage during the build. The workload simply did not consume the additional memory, which suggests that RAM is probably not the limiting factor in this case. Based on these results, I think we can largely rule out RAM as the cause of the slowdown. Thanks again for the suggestion. Attached two screenshots showing the same build in the worst- and best setup. Host A - VM specs: 32 vCPU / 86 GB RAM: Host A - VM specs: 24 vCPU / 86 GB RAM:

Thanks for the suggestion. The host has 96 GB RAM. During testing I assigned approximately 80% of the host memory to the VM, and later also tested with 90% allocation. Based on the metrics I collected so far, memory does not appear to be the limiting factor. While memory usage increases during the build, the host still has roughly 20 GB of free RAM available and I only observed moderate swap usage (around 5 GB). My understanding of your comment is that Xcode may schedule more compilation tasks in parallel as additional vCPUs become available, increasing the overall memory requirements of the build. That certainly sounds plausible in general. I also tracked RAM usage during these tests and compared VM builds against builds running directly on the host. From what I've seen so far, the memory footprint looks reasonable in both cases, and I haven't found an obvious indication that memory pressure is causing the slowdown. That said, I haven't ruled it out completely yet. I'll take another look at the memory metrics during the runs with higher vCPU counts to see if there's something I may have missed. Most of the data I've reviewed so far comes from the host side, so it would be worth digging deeper into the memory usage inside the VM itself during the build to verify that I'm not overlooking something there.