“codesign”

And just to verify that it is in fact signed (team ID partially redacted): % codesign -dv /Applications/SMAppServiceSampleCode.app/Contents/Resources/SampleLaunchAgent Executable=/Applications/SMAppServiceSampleCode.app/Contents/Resources/SampleLaunchAgent Identifier=SampleLaunchAgent Format=Mach-O thin (arm64) CodeDirectory v=20400 size=853 flags=0x0(none) hashes=16+7 location=embedded Signature size=4786 Signed Time=Sep 12, 2025 at 2:22:55 PM Info.plist=not bound TeamIdentifier=******9437 Sealed Resources=none Internal requirements count=1 size=188

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. I am using macOS style that starts with Team ID OK. The Xcode App Group editor is not fully up to speed when it comes to macOS-style app group IDs. The screen shot of your provisioning profile shows the it’s correctly authorising you to use any group matching 2V________.*. And the App Groups editor is showing that you claim two of those groups. That’s all good. Note Regarding the group.com._.MySecurtiyAppGroup, it’s presence isn’t a problem. You’re not claiming access to that group, because the checkbox next it in the App Groups editor isn’t checked. And it’s fine for the profile to authorise you to use groups that you don’t then claim. I suspect that the red indicates that the app group ID you’re claiming isn’t literally in the app group ID listed in the profile. With iOS-style app groups ID that’d be a serious problem. With macOS-style app group IDs, that’s fine because of the wildcar

When building as described above, the helper crashes in such a way (Termination Reason: CODESIGNING 4 Launch Constraint Violation) that suggests I need to apply launch constraints to resolve the problem. I had not previously had launch constraints in my project.

This is my extension's entitlements which dump by codesign

I should add, that using codesign -d -vvvv to interrogate my helper, it doesn't appear that the parent process plist (.coderequirement) is getting embedded in my command-line helper tool. The info.plist IS getting embedded, however.

TN3125 is correct in saying that the hardened runtime entitlements are unrestricted, that is, their used doesn’t have to be authorisation by a profile. I’m not sure what’s going with your app but this is working for me: Using Xcode 16.4 on macOS 15.6.1, create a new project from the macOS > Command Line Tool target. In Signing & Capabilities > Hardened Runtime, check the Disable Library Validation box. Build and run; the program runs just fine. Dump the entitlements of the built executable: % codesign -d -vvv --entitlements - Test799497 … CodeDirectory v=20500 size=630 flags=0x10000(runtime) … … [Dict] [Key] com.apple.security.cs.disable-library-validation [Value] [Bool] true … The runtime flag indicates that the hardened runtime is enabled, and the com.apple.security.cs.disable-library-validation entitlement disables library validation. Moreover, this is a command-line tool, and thus it has no provisioning profile. Please repeat the above, just to make sure that we’re on the same page. As

My understanding is that Xcode Cloud uses cloud signing [1]. Assuming that, the result you’re seeing make sense. With cloud signing the signing identity is never present in the keychain. Hence the whole “cloud” thing (-: Cloud signing is only supported in Xcode (and xcodebuild). It’s not directly supported by codesign [2]. So, you won’t be able to use it to sign your disk image. That leaves you with a few options: Don’t use a disk image. If it’s just a normal app, distributing it as a zip archive is a reasonable option. Don’t sign your disk image. While I generally recommend that folks sign their disk images, it’s not an absolute requirement. Pass your normal (so, not managed) Developer ID Application signing identity to Xcode Cloud and use that to sign your disk image. I’ll admit that none of these are particularly appealing, and I think it’d make sense for you to file an enhancement request against Xcode Cloud for a better way to deal with this. Please post your bug number, just for the record. Sha

Hi. Yes, the Developer ID identity. Thanks for promoting the use of proper terminology 😁 I've read through a number of your other posts on this forum and found them informative and helpful. And yes, I'm referring to Xcode Cloud. My ci_post_xcodebuild.sh script includes: codesign ... --sign $CODESIGN_IDENTITY diskimage.dmg Where CODESIGN_IDENTITY is the SHA-1 of my Developer ID Application: My Company (MYTEAMID). It unsurprisingly fails with: error: The specified item could not be found in the keychain. I can also see there are no identities in the keychain with: security find-identity -v -p codesigning I'm hoping Xcode Cloud provides me a better way to access the identity than uploading the .p12 to the host... Thanks!