I'm working on a multi-process macOS application (based on Chromium/Electron) that uses Mach ports for inter-process communication between the main app and its helper processes. Background I have an MAS build working successfully via TestFlight for internal testing. However, public TestFlight testing requires Apple review, and while waiting for that review, I wanted to provide a directly distributable build for external testers. I attempted to create a Developer ID signed build with App Sandbox enabled, expecting it to behave similarly to the MAS build. The Problem With App Sandbox enabled (com.apple.security.app-sandbox) and identical entitlements, I observe different behavior depending on the signing certificate: Apple Distribution certificate: App launches successfully, mach-register and mach-lookup work Developer ID certificate: App crashes at launch, mach-register is denied by sandbox The Console shows this sandbox violation for the Developer ID build: Sandbox: MyApp(13605) deny(1) mach-register XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.13605 The crash occurs when the app calls bootstrap_check_in() to register a Mach service for child process communication. What I've tried Adding com.apple.security.temporary-exception.mach-register.global-name with wildcard pattern XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.* to the main app's entitlements - this resolved the mach-register denial. However, helper processes then fail with mach-lookup denial. Adding com.apple.security.temporary-exception.mach-lookup.global-name with the same wildcard pattern to the main app's entitlements (for inheritance) does not work. Analysis of /System/Library/Sandbox/Profiles/application.sb I examined macOS's App Sandbox profile and found that mach-register.global-name supports wildcard patterns via select-mach-filter: (sandbox-array-entitlement "com.apple.security.temporary-exception.mach-register.global-name" (lambda (name) ... (let ((mach-filter (select-mach-filter name global-name-prefix global-name))) (allow mach-register mach-filter)))) But mach-lookup.global-name does not - it only accepts exact names: (sandbox-array-entitlement "com.apple.security.temporary-exception.mach-lookup.global-name" (lambda (name) (allow mach-lookup (global-name name)))) Since the Mach service name includes the PID (e.g., ...MachPortRendezvousServer.13605), it's impossible to specify exact names in entitlements. I also verified that com.apple.security.application-groups grants mach-register and mach-lookup only for service names prefixed with the group ID (e.g., group.com.mycompany.myapp.), which doesn't match the TEAMID.bundleid. prefix used by Chromium's MachPortRendezvousServer. My questions What mechanism allows Apple Distribution signed apps to use mach-register and mach-lookup for these service names without temporary exceptions? I don't see any certificate-based logic in application.sb. Is there a way to achieve the same behavior with Developer ID signing for testing purposes? Related threads https://developer.apple.com/forums/thread/747005 https://developer.apple.com/forums/thread/685601 https://developer.apple.com/forums/thread/128714 (confirms temporary-exception can be used freely for Developer ID apps) Environment macOS 15.6 (Sequoia) Xcode 16.4 Both certificates from the same Apple Developer account

Problem summary I have a macOS helper app that is launched from a sandboxed main app. The helper: has com.apple.security.app-sandbox = true and com.apple.security.inherit = true in its entitlements, is signed and embedded inside the main app bundle (placed next to the main executable in Contents/MacOS), reports entitlement_check = 1 (code signature contains sandbox entitlement, implemented via SecStaticCode… check), sandbox_check(getpid(), NULL, 0) returns 1 (runtime sandbox enforcement present), APP_SANDBOX_CONTAINER_ID environment variable is not present (0). Despite that, Cocoa APIs return non-container home paths: NSHomeDirectory() returns /Users/<me>/ (the real home). [[NSFileManager defaultManager] URLsForDirectory:inDomains:] and URLForDirectory:inDomain:appropriateForURL:create:error: return paths rooted at /Users/<me>/ (not under ~/Library/Containers/<app_id>/Data/...) — i.e. they look like non-sandboxed locations. However, one important exception: URLForDirectory:... for NSItemReplacementDirectory (temporary/replacement items) does return a path under the helper's container (example: ~/Library/Containers/<app_id>/Data/tmp/TemporaryItems/NSIRD_<helper_name>_hfc1bZ). This proves the sandbox is active for some FileManager APIs, yet standard directory lookups (Application Support, Documents, Caches, and NSHomeDirectory()) are not being redirected to the container. What I expect The helper (which inherits the sandbox and is clearly sandboxed) should get container-scoped paths from Cocoa’s FileManager APIs (Application Support, Documents, Caches), i.e. paths under the helper’s container: /Users/<me>/Library/Containers/<app_id>/Data/.... What I tried / diagnostics already gathered Entitlements & code signature codesign -d --entitlements :- /path/to/Helper.app/Contents/MacOS/Helper # shows com.apple.security.app-sandbox = true and com.apple.security.inherit = true Runtime checks (Objective-C++ inside helper): extern "C" int sandbox_check(pid_t pid, const char *op, int flags); NSLog(@"entitlement_check = %d", entitlement_check()); // SecStaticCode check NSLog(@"env_variable_check = %d", (getenv("APP_SANDBOX_CONTAINER_ID") != NULL)); NSLog(@"runtime_sandbox_check = %d", sandbox_check(getpid(), nullptr, 0)); NSLog(@"NSHomeDirectory = %s", NSHomeDirectory()); NSArray *urls = [[NSFileManager defaultManager] URLsForDirectory:NSApplicationSupportDirectory inDomains:NSUserDomainMask]; NSLog(@"URLsForDirectory: %@", urls); Observed output: entitlement_check = 1 env_variable_check = 0 runtime_sandbox_check = 1 NSHomeDirectory = /Users/<me> URLsForDirectory: ( "file:///Users/<me>/Library/Application%20Support/..." ) Temporary/replacement directory (evidence sandbox active for some APIs): NSURL *tmpReplacement = [[NSFileManager defaultManager] URLForDirectory:NSItemReplacementDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:&err]; NSLog(@"NSItemReplacementDirectory: %@", tmpReplacement.path); Observed output (example): /Users/<me>/Library/Containers/<app_id>/Data/tmp/TemporaryItems/NSIRD_<helper_name>_hfc1bZ Other facts Calls to NSHomeDirectory() and URLsForDirectory: are made after main() to avoid "too early" initialization problems. Helper is placed in Contents/MacOS (not Contents/Library/LoginItems). Helper is a non-GUI helper binary launched by the main app (not an XPC service). macOS version: Sequoia 15.6 Questions Why do NSHomeDirectory() and URLsForDirectory: return the real /Users/<me>/... paths in a helper process that is clearly sandboxed (entitlement + runtime enforcement), while NSItemReplacementDirectory returns a container-scoped temporary path? Is this behavior related to how the helper is packaged or launched (e.g., placement in Contents/MacOS vs Contents/Library/LoginItems, or whether it is launched with posix_spawn/fork+exec vs other APIs)? Are there additional entitlements or packaging rules required for a helper that inherits sandbox to have Cocoa directory APIs redirected to the container (for Application Support, Documents, Caches)? *Thanks in advance — I can add any requested logs

I have multiple Xcode versions installed on my system using the XcodesApp. Whenever I need to work with a specific Xcode version, I have to switch between them using the xcodes select command: xcodes select 14.3.1 # or 15.3, etc. After selecting the desired Xcode version, I use CMake to generate Ninja build files for my projects. However, having to switch Xcode versions manually every time is quite tedious and prevents me from concurrently building projects that require different Xcode versions. Is there an official or recommended way to configure CMake to use the appropriate Xcode toolchain (compilers, linkers, etc.) for each project without having to manually switch between Xcode versions? Ideally, I'd like to be able to specify the desired Xcode version when running CMake, and have it automatically use the corresponding toolchain for that version. I'm aware that one potential solution could be to create separate toolchain files for each Xcode version, specifying the paths to the compilers and other tools. However, I'm wondering if there's a more official or recommended approach from Apple or the CMake community. Any guidance or suggestions on how to achieve this would be greatly appreciated.