We need the same clarification for Apara, a commercial Mac app that runs Windows games on Apple silicon. Direct3D 12 titles run well only through D3DMetal, and today every customer has to download the Game Porting Toolkit from Apple themselves because the licence doesn't make clear whether a commercial app may redistribute it. We'd welcome either an updated licence or a process for requesting permission, and will accept whatever conditions Apple sets (attribution, supported macOS versions, removal on request). We've filed our own Feedback referencing FB24262864.

Thanks Quinn, that's really helpful. I'll give the helper its own App ID and wrap the loader in a small app bundle, following the daemon article. Appreciate you digging into this.

Thanks Quinn, that worked for me too. One thing I noticed while playing with it: the small page-zero isn't actually needed. With the entitlement, the space below the image becomes a reservation I can free myself. So I kept the default 4 GB page-zero, called vm_deallocate on it at startup, and could then map 0x10000, 0x7ffe0000 and 0xfffe0000 every time. With just the 16 KB page-zero, 0x7ffe0000 works but 0x10000 never does, because the slide gap is still reserved. On packaging: a nested .app in Contents/Helpers that reuses the same bundle ID and profile gets the entitlement fine, and it notarized without issues. A bare helper binary gets killed at launch. Two quick questions: Is reusing the parent's bundle ID and profile for a nested helper app okay to rely on, or should each helper get its own App ID? Is there any supported way to give the entitlement to a plain helper executable? Our loader isn't a bundle's main executable. Thanks again, this helps a lot.

WIll wait, but this was helpful too.

Posted the details of my __PAGEZERO case here: https://developer.apple.com/forums/thread/845976 (DTS case 22070584). Same issue as this thread — an arm64 process can't map below 4 GB.