General: DevForums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained DevForums post --deep Considered Harmful DevForums post Don’t Run App Store Distribution-Signed Code DevForums post Resolving errSecInternalComponent errors during code signing DevForums post Finding a Capability’s Distribution Restrictions DevForums post Signing code with a hardware-based code-signing identity DevForums post Mac code signing: DevForums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding Nonstandard Code Structures in a Bundle documentation Embedding a Command-Line Tool in a Sandboxed App documentation Signing a Daemon with a Restricted Entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example DevForums post The Care and Feeding of Developer ID DevForums post TestFlight, Provisioning Profiles, and the Mac App Store DevForums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am signed into Xcode for automatic signing. Which works for a random amount of builds and then the Account/AppleID dissappears from Xcode. This is a vital part of our CI/CD processes and disrupts the workflow alot. MacOS version: Apple M2 15.3 (24D60) Sequoia related: https://developer.apple.com/forums/thread/724434 https://stackoverflow.com/questions/50252887/account-automatically-removed-from-xcode

In xcode, the signing&capabilities TAB for ios says: Automatic signing failed Xcode failed to provision this target. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator. Provisioning profile "iOS Team Provisioning Profile: com.kikk.morsecode" doesn't include the com.apple.developer.in-app-purchase entitlement. Even though I've already configured the corresponding Certificates, Identifiers & Profiles in developer Does anyone have the same problem? My Version of xcode is Version 15.4 (15F31d), running on m2pro.

I am developing a macOS app that requires the Associated Domains entitlement. The app will be distributed as a custom app. The app needs to be signed using Team A’s Developer ID Application certificate and packaged under Team A’s Team ID. Team A has a secure signing and packaging setup, but they do not provide access to their Developer ID Application Identity (cert) or their provisioning profile. I am part of Team B and have access to Team B’s Developer ID Application identity and provisioning profiles. I am thinking of doing the following: I create a provisioning profile under Team B that authorizes the Associated Domains entitlement. I sign the app using Team B’s Developer ID Application identity, ensuring the required entitlements are included. Then, I re-sign the app using Team A’s Developer ID Application identity, since Team A has also set up the same bundle ID with the Associated Domains entitlement and corresponding provisioning profile. Questions: Is this approach correct & does it have any drawback? Will the double signing process work without issues, given that Team A has the required provisioning profile for the same bundle ID? Are there better ways to handle this situation where signing must be done under Team A but access is limited? Thanks!

I have used XCode for decades as my default C/C++ programming IDE. I write code that I run locally on my Mac, via "Sign to run locally". Typically this has always "just worked". I am now using MacOS 14.7 Sonoma, and I suddenly find I cannot run my code projects because I cannot dynamically load unsigned libraries. "not valid for use in process: library load disallowed by system policy" BUT - it appears that to allow my local MacOS code to bypass this requires I have a bundle identifier to modify entitlements. Which in turn requires a developer account which I don't have. Is this all correct? Is there any way to have code run locally and use dynamic libraries as I've done previously? Any advice is much appreciated.

I am trying to get a PKG installer through the Apple codesign and notarytool process. When I submit the PKG installer I get a status message of "Invalid" and when I review the log file it has 2 errors. For "status summary" it says: "Archive contains critical validation errors", and for "message" it says" "The binary is not signed". The installer contains a flat file that is installed in the "Users/Shared" folder via the PKG installer. Here are the steps I've taken to get the installer through the codesign and notarytool process. codesign the file that's placed in the "Users/Shared" folder: codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/"flat file" which I get a message saying "signed generic". Create the PKG installer with the signed "flat file". Sign the PKG installer containing the signed "flat file": codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/"flat file" which I get a message saying "signed generic". Submit the PKG file with notarytool: xcrun notarytool submit /Users/.../Documents/folder/"flat file" --verbose --apple-id username --password password --team-id ID# --progress It completes and provides the submission ID. I check the status and get the error message that it's invalid. When I check the full details via the log I get the error messages mentioned above. What am I missing or failing to do?

I can't upload my macOS app to app store connect. Each time i try to upload, i see this message: Provisioning profile failed qualification Profile doesn't support App Groups. An empty app without an app group uploads fine, but if i add an app group to it, it does not upload.

I'm getting this error when uploading a build of my macOS app to App Store Connect. It has always worked before, and nothing changed about my use of app groups, and the iOS build uploaded without any problems. Cleaning the build folder and derived data folder doesn't help. I'm using automatically managed signing in Xcode. Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “[group.]” value for the com.apple.security.application-groups key in “.pkg/Payload/.app/Contents/MacOS/” isn’t supported. This value should be a string or an array of strings, where each string is the “group” value or your Team ID, followed by a dot (“.”), followed by the group name. If you're using the “group” prefix, verify that the provisioning profile used to sign the app contains the com.apple.security.application-groups entitlement and its associated value(s).

I am having difficulty getting my container app with an embedded endpoint security extension to work on a virtual Mac. My virtual Mac has system integrity protection turned off. I have used spctl and System Settings to allow applications from anywhere. I am using the development entitlement profile to sign my container app. When I run my app, it crashes with Termination Reason: COODESIGNING 1 Taskgated Invalid Signature. I assume this has to do with the app being signed with my developer profile that contains a list of Macs that can run the software. How can test my endpoint security extension on a virtual Mac?

Hi all, reposting from here: https://unix.stackexchange.com/questions/789849/xattr-c-not-removing-com-apple-finderinfo-attribute I was trying to build my Xcode project, but ran into the error "resource fork, Finder information, or similar detritus not allowed." I was following the solutions from this stack exchange post, but xattr seems to not be working as expected. Basically, running xattr -cr . on my project directory successfully removes all xattrs except for com.apple.FinderInfo, which persists on all .xcodeproj and .xcworkspace files. I've tried everything under the sun, from xattr -d to sudo to dot_clean to tar to rsync and nothing can remove it. Is this just some kind of immortal attribute? It's preventing me from building my project. I'm at a loss here, this is my senior thesis project.

My question is: Do I need two App IDs? One for my launch daemon in order to sign it properly, allowing it to use the Endpoint Security framework. One for the container app. My understanding is that my existing launch daemon can perform the endpoint security requirements I need. So far, I have had just one App ID for my container app that lives in /Applications. I have applied for the endpoint security restricted entitlement and have this for development now. Do endpoint security items have go in Library/SystemExtension? Can my launch daemon live in Library/LaunchDaemons and still use the Endpoint Security framework?

I'm calling this command to export archive: xcodebuild -exportArchive -archivePath .build/XYZ.xcarchive -exportPath .build/XYZ.ipa -exportOptionsPlist Authenticator/ExportOptions.plist -quiet -allowProvisioningUpdates Here is my exportOptions file content <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>method</key> <string>app-store-connect</string> <key>signingStyle</key> <string>automatic</string> <key>teamID</key> <string>ABCD</string> </dict> </plist> Most of the time this command fail with this error: error: exportArchive No Accounts error: exportArchive No signing certificate "iOS Distribution" found What we found is that our Apple ID just disappear from Xcode and we need to add it again manually. So there are two questions here: Why Apple ID account dissapears and how I can fix this? Is there an option to not use Apple ID account in Xcode and for example to use -authenticationKeyID flags of xcodebuild? Just to mention this happens only on our CI machine and not locally.

Xcode 16.2 Framework Signing Issues with Cloud Managed Developer ID in Automated Builds Issue Description After upgrading from Xcode 15.4 to 16.2, our macOS app's frameworks are failing notarization with the error "The binary is not signed with a valid Developer ID certificate" for embedded frameworks when building through fastlane. This worked correctly in Xcode 15.4. Importantly, manually archiving and notarizing through the Xcode GUI still works correctly - the issue only occurs during automated builds. Build Configuration We use fastlane to build and notarize our macOS app: build_mac_app( scheme: 'Runner', export_method: "developer-id", xcargs: '-allowProvisioningUpdates' ) This generates the following xcodebuild commands: Archive: xcodebuild -workspace ./Runner.xcworkspace -scheme Runner -destination 'generic/platform=macOS' -archivePath /path/to/archive -allowProvisioningUpdates archive Export with plist: xcrun -exportArchive -exportOptionsPlist '/path/to/plist' -archivePath /path/to/archive -exportPath '/output/path' -allowProvisioningUpdates Export options plist contents: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>installerSigningCertificate</key> <string>Developer ID Installer: Company Inc (1234567891)</string> <key>method</key> <string>developer-id</string> <key>signingStyle</key> <string>automatic</string> </dict> </plist> Notarization: ditto -c -k --rsrc --keepParent "My App.app" "My App.app.zip" xcrun notarytool submit "My App.app.zip" --output-format json --wait --key /path/to/key --key-id ABCDEFGHIJ --issuer 12345678-abcd-1234-5678-fc2d96b1735a Error Output Notarization fails with the following errors: { "severity": "error", "code": null, "path": "My App.app.zip/My App.app/Contents/Frameworks/some_package.framework/Versions/A/some_package", "message": "The binary is not signed with a valid Developer ID certificate.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721", "architecture": "arm64" } Key Details Using Xcode Cloud managed Developer ID certificates (not local certificates) ✅ Building, archiving, and notarizing through Xcode GUI works correctly Automatic signing is enabled Expected Behavior Frameworks should be automatically signed with the cloud managed Developer ID certificate during the export process, as they were in Xcode 15.4. Has there been a change in how framework signing is handled with cloud managed certificates in Xcode 16.2's command line tools? Any guidance on how to ensure frameworks are properly signed during automated builds when using automatic signing with cloud managed Developer ID certificates would be appreciated.

I am developing and distributing an XCFramework, and I want to ensure that it remains valid for as long as possible. I have some questions regarding certificate expiration and revocation: I understand that if an XCFramework is signed with a timestamp, it remains valid even after the signing certificate expires. However, if the signing certificate is revoked, the XCFramework immediately becomes unusable. As far as I know, Apple allows a maximum of two active distribution certificates at the same time. I assume that once a certificate expires, it will eventually need to be revoked in order to issue a third certificate. Is this correct? If an expired certificate is later revoked, will the XCFrameworks signed with that certificate also become invalid, even though they were timestamped? I want to ensure that released XCFrameworks remain valid for as long as possible. What is the best approach to achieve this? If anyone has insights or official documentation references on how to manage signing certificates for long-term XCFramework validity, I would appreciate your guidance. Thank you!

We’re encountering a strange issue with our app submission to the App Review Team. It’s a paid macOS app with no in-app purchases. The App Review Team reports that the app fails to launch, displaying an “App is Damaged” dialog. In the Console app, they see the app exiting with code 173. We don’t have any receipt validation code. I’ve double-checked our code and dependencies, and I don’t see exit(173) being called anywhere. The same builds distributed through TestFlight work fine. Our builds are generated using Xcode Cloud, and the last build was successfully tested by the App Review Team. The only difference between this build and the last successfully tested build is a one-line bug fix—none of the settings or dependencies have changed. Both builds were created and submitted using Xcode Cloud. We’re completely stumped. Has anyone seen this behavior or have suggestions for further debugging? The problem is we can’t seem to reproduce this behaviour anywhere.

I'm using libxpc in a C server and Swift client. I set up a code-signing requirement in the server using xpc_connection_set_peer_code_signing_requirement(). However, when the client doesn't meet the requirement, the server just closes the connection, and I get XPC_ERROR_CONNECTION_INTERRUPTED on the client side instead of XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT, making debugging harder. What I want: To receive XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT on the client when code-signing fails, for better debugging. What I’ve tried: Using xpc_connection_set_peer_code_signing_requirement(), but it causes the connection to be dropped immediately. Questions: Why does the server close the connection without sending the expected error? How can I receive the correct error on the client side? Are there any other methods for debugging code-signing failures with libxpc? Thanks for any insights!

After I upgraded to macOS 15.3, all of my current Xcode project have the signing issue, I spent half day and I didn't make any progress, I tried two projects, one is Swift AppKit App calling one C++ dylib, another one is a pure Swift AppKit app, when I build, there will be error: Warning: unable to build chain to self-signed root for signer "Apple Development: Steven Tang (XXXXX)" /Volumes/TwoTSSD/steventang/Library/Developer/Xcode/DerivedData/ImageEnhancement-ddbilgyraofrdyfeljyuknusunza/Build/Products/Release/ImageEnhancement.app: errSecInternalComponent I tried remove account, add account back in Xcode, none of it worked, also tried ChatGPT's WWDR updating and it won't help.

MacOS Version: 14.7.2 macOS SDKs: macOS 14.5 -sdk macosx14.5 I am working on a sample program for validation Against: Team Identifier Developer ID I started with validating Team Identifier, but my validation is not working and it is allowing to launch programs which are not matching the team identifier in the signature. Below is my code: func verifyExecutableWithLCR(executablePath: String, arguments: [String]) -> Bool { let task = Process() task.launchPath = executablePath task.arguments = arguments if #available(macOS 14.4, *) { print("launchRequirementData is available on this system.") do { let req = try OnDiskCodeRequirement.allOf { TeamIdentifier("ABCDEFGHI") //SigningIdentifier("com.***.client.***-Client.****") } let encoder = PropertyListEncoder() encoder.outputFormat = .xml let requirementData = try encoder.encode(req) task.launchRequirementData = requirementData print("launchRequirementData is set.") try task.run() print("[SUCCESS] Executable passed the code signature verification.") return true } catch { print("[ERROR] Code signature verification failed: \(error.localizedDescription)") return false } } else { print("[WARNING] launchRequirement is not available on this macOS version.") return false } } Could you please help me in identifying whay am I doing wrong here?

I have created a XPC server and client using C APIs. I want to ensure that I trust the client, so I want to have a codesigning requirement on the server side, something like - xpc_connection_set_peer_code_signing_requirement(listener, "anchor apple generic and certificate leaf[subject.OU] = \"1234567\"") This checks if the client code was signed by a code-signing-identity issued by Apple and that the teamID in the leaf certificate is 1234567. My questions are- Is using teamID as a signing requirement enough? What else can I add to this requirement to make it more secure? How does xpc_connection_set_peer_code_signing_requirement work internally? Does it do any cryptographic operations to verify the clients signature or does it simply do string matching on the teamID? Is there a way actually verify the clients signature(cryptographically) before establishing a connection with the server? (so we know the client is who he claims to be)

I've noticed that NSTaks has this property as of macOS 14.4 @property (nullable, copy) NSData *launchRequirementData API_AVAILABLE(macos(14.4)) API_UNAVAILABLE(ios, watchos, tvos, visionos); It has no documentation whatsoever. Even google search has no clue. Does this have anything to do with code signature requirements validation? Any explanations and examples would be appreciated!

In the macOS 14.0 SDK, environment and library constraints were introduced, which made defense against common attack vectors relatively simple (especially with the LightWeightCodeRequirements framework added in 14.4). Now, the application I'm working on must support macOS 13.0 too, so I was looking into alternatives that do work for those operating systems as well. What I found myself is that the SecCode/SecStaticCode APIs in the Security Framework do offer very similar fashion checks as the LightWeightCodeRequirements framework does: SecCodeCopySigningInformation can return values like signing identifier, team identifier, code requirement string and so on. SecStaticCodeCreateWithPath can return a SecStaticCode object to an executable/app bundle on the file system. Let's say, I would want to protect myself against launchd executable swap. From macOS 14.0 onward, I would use a Spawn Constraint for this, directly in the launchd.plist file. Before macOS 14.0, I would create a SecStaticCode object for the executable path found in the launchd.plist, and then examine its SecCodeCopySigningInformation dictionary. If the expectations are met, only then would I execute the launchd.plist-defined executable or connect to it via XPC. Are these two equivalent? If not, what are the differences?