Hi @RickMaddy, just tried the update method yesterday and now I can confirm it works as described. Installed macOS 14.6.1 to a fresh VM, then upgraded to Tahoe via System Settings. As one would expect, the UDID remained unchanged after the upgrade, which seems essential for the developer signature to work correctly. My developer-signed app built on the host machine starts without issues in the guest running macOS 16 (after adding the UDID in the Developer portal). Please see if it works for you—still a bit cumbersome, but looks much more convenient compared to the dual-boot scheme.

@RickMaddy Possible workaround mentioned in another thread is to create a VM with older operating system (macOS 14 Sonoma or earlier) and then upgrade the guest to a newer version. It ensures the VM has an old format UDID which will allow the provisioning profile to work correctly. May be worth trying until there is a proper fix.

Hi Kevin @DTS Engineer, thank you so much for the response! This is indeed a comprehensive answer. I suspected it was missing for similar reasons you mentioned, just wanted to make sure it was intentional. Following the topic of intercepting file access events: could you suggest other technologies that are better suited to achieve this goal? Let's say it does not have to be general purpose software for end users, so anything like kernel module or even a custom kernel build also count. P.S. Thank you for the warning and for the links to other forum threads on this topic; very useful. As someone who came from the kernel driver world, I can imagine the possible performance impact of a subsystem like Endpoint Security, and the responsibility that comes with it. My app is monitoring-only, so hopefully it will be less prone to such errors. Anyway, will use your advice and try to be more careful.

Hello and thank you so much for quick response! The service application running on the host must be able to tell which client has connected to it via vsock. I have working code that runs on Linux (based on a "classic" vsock implementation), and it has to use different port numbers for each client, otherwise it would be impossible for multiple guests to connect to a single host. I tried to reuse the same approach in macOS, but it seems to be impossible. However, I understand it is not even required in macOS, since VM instances run by the Virtualization.framework are already isolated from each other. When the host app receives an incoming connection, it will be able to tell which client has connected just by using different VZVirtioSocketListenerDelegate. I haven't tested it yet, but I feel like this approach should work. Thanks again for clarification!