Hi, I have a project that integrates the Firebase SDK via SPM as a dependency of an internal Swift Package: My app ⟶ My Library ⟶ Firebase SDK The project builds successfully and can be archived locally ✅. The uploaded .ipa is valid and gets published 🚀. However, we are now trying to automate the release process using Xcode Cloud, but the iOS Archive action is failing ❌ on Xcode Cloud. The logs show the following error ⬇️: error: exportArchive codesign command failed (/Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: replacing existing signature /Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: invalid or corrupted code requirement(s) Requirement syntax error(s): line 1:178: unexpected token: <COMPANY_NAME> ) ** EXPORT FAILED ** I have been researching this issue for a while and have tried several solutions to fix it, but with no luck. Even though the error points to a specific library—the Firebase SDK—I don’t believe Firebase is the root cause. There were related issues in the past, but those were already fixed by the Firebase team, and as I mentioned, the project archives correctly when built locally. On the other hand, the error states: line 1:178: unexpected token: <COMPANY_ACRONYM> This makes me wonder if there’s an issue parsing our Team Name during the re-signing process, as it contains special characters ": "name": "Apple Distribution: Company Full Name "COMPANY_ACRONYM""

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!

Hello! I've just recently discovered LaunchCodeRequirement API and I'm exploring how it works compared to existing alternatives available for macOS versions below 14.4. Some questions I have with regards to safety of older and newer APIs examining the given example: func runProcess(executableURL: URL) throws { let process = Process() process.executableURL = executableURL if #available(macOS 14.4, *) { process.launchRequirement = try LaunchCodeRequirement.allOf { ValidationCategory(.developerID) SigningIdentifier("some-signing-identifier") TeamIdentifier("some-team-identifier") } } else { try secStaticCodeCheckValidity(executableURL) // Point #1 } do { try process.run() // Point #2 if #available(macOS 14.4, *) { // process.launchRequirement should take care of the process // and kill it if launchRequirement constraint is not satisfied } else { try secCodeCheckValidity(process.processIdentifier) // Point #3 } process.waitUntilExit() } catch { process.terminate() throw error } // Point #4 guard process.terminationReason == .exit else { throw SomeError() } } let requirement = """ anchor apple generic and identifier = "some-signing-identifier" and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf [subject.OU] = "some-team-identifier" """ func secStaticCodeCheckValidity(_ executableURL: URL) throws { // Init SecStaticCode from `executableURL` // Init SecRequirement from `requirement` let flags = SecCSFlags(rawValue: kSecCSBasicValidateOnly) guard SecStaticCodeCheckValidityWithErrors(code, flags, secRequirement, nil) == errSecSuccess else { throw CodeSignError() } } func secCodeCheckValidity(_ processIdentifier: Int32) { // Init SecCode from `processIdentifier` // Init SecRequirement from `requirement` guard SecCodeCheckValidityWithErrors(code, [], secRequirement, nil) == errSecSuccess else { throw CodeSignError() } } Before macOS 14.4+ flow There's still a small chance that between checking executable binary codesign requirement (Point #1) and launched process' one (Point #3) the binary could be replaced with something malicious and even get some CPU between Points #2 and #3 so technically it can't be 100% safe. Is that a correct statement? Any advices on making it safer? macOS 14.4+ flow Now let's see how launchRequirement is better. I guess initialized launchRequirement gets evaluated on running the process (Point #2). What does it exactly check? Executable at URL before launching the process (as OnDiskConstraint) or launched process (as ProcessConstraint)? Is there any chance the process gets some CPU before it's killed in case of failed codesign check? Any way to distinguish between codesign requirement termination and other reasons at point #4? It returns SIGKILL (9) as terminationStatus but it's not precise enough to be sure it was killed due to failed requirement check. I guess newer SecStaticCodeCheckValidityWithOnDiskRequirement & SecCodeCheckValidityWithProcessRequirement are the same as SecStaticCodeCheckValidityWithErrors & SecCodeCheckValidityWithErrors but a little simpler and can't be used as a 'more secure' way of validating codesign requirement. Thanks, Pavel

I have a .NET 6 application that runs in the background. The installer is a .pkg file built using a third-party tool called "Packages". All .dylib and executable files are codesigned before packaging. The resulting .pkg file is notarized. The app uses these entitlements: com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.allow-dyld-environment-variables com.apple.security.cs.disable-library-validation The app is built on a macbook Air 2015 running macOS 12.6 and it works without issues on that machine. On a macbook Pro M3 running macOS 14.6.1 the app fails to run even though the installation itself is successful. The only logs that I was able to find are related to syspolicyd (4 warnings): Unable to apply protection to app: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null)) Failed to register app bundle for protection: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null)) scan failed, finishing evaluation : PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null)) Terminating process due to Gatekeeper rejection: 95158, Unfortunately, verification commands such as sudo codesign --verify --deep --strict -vvv MyApplication.App spctl -a -vvv -t install MyApplicationInstaller.pkg do not indicate any issues. Are there any additional steps that need to be performed in order for my app to work properly on newer machines?

i was complete my program, and export a mac app already it work ok in my macmini, but if i want send it to app store, that i have no way now i still do not know how to make this app perfect like, when i use pyinstaller to build this app, is there any info or elements need make with? i can sign my app now, even i use codesign -dvvv my.app to check the sign, it is also ok, there no any feedback said it anything wrong. so, any master know fix app sign or any infoplist please tech me... help

Hi everyone. Sorry if this is not an appropriate forum section for this question. I'm making a game engine and it doesn't launch on my colleague's MacBook, although it does launch on mine. There's an application file, let's say, Sample.app. And along with it in the same folder there's Engine.dylib. If we look at the app-file structure, the executable file's path is Contents/MacOS/Sample. So for the executable file the library is located at the path ../../../Engine.dylib. But when my colleague runs the Sample.app file, he gets an error "Library not loaded: @executable_path/../../../Engine.dylib". Although the path is correct and on my MacBook it works. Are there any ideas how to fix it?

Hi Team, I have created multiple certificates for macOS application. Below are the certificates created- Apple Development Certificate DeveloperID Installer Certificate Apple Distribution Certificate others certificates Later, I have imported the all these above certificates in keychain-access. Now, I tried to compile the code through Xcode. I am getting error for code signing certificate. Warning: unable to build chain to self-signed root for signer "Apple Development: Amit (M2WMF2YERI)” .... Command CodeSign failed with a nonzero exit code When I checked the TeamID of User(Amit) I can see that his current TeamID is [P8ZW3W9R2Q]. There is mismatch of teamID in apple development certificate generation. Note- All certificates are generated with current TeamID[P8ZW3W9R2Q] of user (Amit) except Apple Development certificate which has been generated with TeamID [M2WMF2YERI] which is generated with old TeamID of user (Amit). I attempted to generate the apple development certificate multiple times but it is getting generated with old TeamID TeamID[M2WMF2YERI] of user(Amit)
 Summary- While creating a developer certificate using apple developer account and mapping it in keychain, the certificate is being generated with old apple account details (Inactive) instead of the current one. This is causing issues when using the certificate in keychain. If anyone has encountered this issue, how it was resolved?
 Thanks

Hi Team, I have created multiple certificates for macOS application. Below are the certificates created- Apple Development Certificate DeveloperID Installer Certificate Apple Distribution Certificate others certificates Later, I have imported the all these above certificates in keychain-access. Now, I tried to compile the code through Xcode. I am getting error for code signing certificate. Warning: unable to build chain to self-signed root for signer "Apple Development: Amit (M2WMF2YERI)” .... Command CodeSign failed with a nonzero exit code When I checked the TeamID of User(Amit) I can see that his current TeamID is [P8ZW3W9R2Q]. There is mismatch of teamID in apple development certificate generation. Note- All certificates are generated with current TeamID[P8ZW3W9R2Q] of user (Amit) except Apple Development certificate which has been generated with TeamID [M2WMF2YERI] which is generated with old TeamID of user (Amit). I attempted to generate the apple development certificate multiple times but it is getting generated with old TeamID TeamID[M2WMF2YERI] of user(Amit)
 Summary- While creating a developer certificate using apple developer account and mapping it in keychain, the certificate is being generated with old apple account details (Inactive) instead of the current one. This is causing issues when using the certificate in keychain. If anyone has encountered this issue, how it was resolved?

Hello, After deploying our app, we encountered an issue where the app fails to launch properly on certain devices. To rule out potential code issues, we created a new clean project and tested it with the basic setup (certificate, bundle ID, and team). The app installs and runs fine on most devices, but it fails to open immediately on specific models. (The affected model is listed below.) Version: iOS 18.3.1 Model: iPhone 14 Pro After reviewing the console logs, we found an issue related to the app launching process. Could this issue be related to the app's configuration or the provisioning profile? We would appreciate any insight into why this issue occurs only on certain devices. Thank you for your help!

Hi Developer Community, I'm encountering persistent code signing failures on macOS Sonoma 15.3 with a valid Developer ID Application certificate. The error occurs consistently across multiple certificate regenerations and various troubleshooting approaches. Environment macOS Version: Sonoma 15.3 Developer Account Type: Developer ID Certificate Type: Developer ID Application Certificate Details: Developer ID Application certificate valid until 2027 Using SHA-256 with RSA Encryption Certificate shows as valid in Keychain Access with associated private key Error Message Warning: unable to build chain to self-signed root for signer "Developer ID Application: [my certificate]" [filename]: errSecInternalComponent Steps to Reproduce Install certificate chain in order: Apple Root CA (System keychain) Apple WWDR CA (System keychain) Developer ID CA (System keychain) Developer ID Application certificate (Login keychain) Verify certificate installation: security find-identity -v -p codesigning Result shows valid identity. Attempt code signing with any binary: codesign -s "Developer ID Application: [my certificate]" -f --timestamp --options runtime [filename] Results in errSecInternalComponent error Troubleshooting Already Attempted Regenerated Developer ID Application certificate multiple times from Developer Portal Completely removed and reinstalled entire certificate chain Verified trust settings on all certificates (set to "Always Trust" for code signing) Tried multiple codesign command variations including --no-strict flag Verified keychain integrity Installed latest Apple CA certificates from apple.com/certificateauthority Verified certificate chain is properly recognized by security verify-cert Additional Information All certificates show as valid in Keychain Access Private key is properly associated with Developer ID Application certificate Trust settings are correctly configured for all certificates in the chain Problem persists after clean certificate installations Error occurs with any binary I try to sign Has anyone else encountered this issue on Sonoma 15.3? Any suggestions for resolving this system-level certificate trust chain issue would be greatly appreciated. Thanks in advance!

Hi everyone, I am doing my app playground, when I change the development team or try to clear it, this bug happend? So I wonder do I have to remove it when I submit my work or just leave it there. Signing for "myapp" requires a development team. Select a development team in the Signing & Capabilities editor.

In an expo managed project which utilizes custom expo plugins, we're having trouble getting the keychain-access-groups entitlement inserted to our provisioningprofile for signing. The provisioning profile we download from apple dev portal contains: <key>keychain-access-groups</key> <array> <string>56APMZ7FZY.*</string> <string>com.apple.token</string> </array> and this is not recognized by xcode for signing; an error is thrown: Provisioning profile "ccpp" doesn't include the com.apple.developer.keychain-access-groups entitlement. A matching error is thrown during EAS build. So we need to find a way to modify the ccpp.mobileprovision locally and then sign the build using the modified ccpp.mobileprovision. Or, we need guidance on the proper way to resolve this situation. Questions: why does the downloaded mobileprovision file have the keychain-access-groups key, and not com.apple.developer.keychain-access-groups? Both Xcode and EAS appear to demand the latter keyname. when I use expo prebuild, I am able to see the following in the .entitlements file: <key>com.apple.developer.keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.myapp</string> </array> I am adding this entitlement using a custom expo plugin. However, the mobileprovision file downloaded from apple developer portal has no knowledge of this setting which is only applied through expo prebuild. So what I am left with at the end is an entitlements file generated by my expo prebuild which has the correct setting, and a provisioningprofile downloaded from dev portal with an incorrect setting, and I don't know how to mend the downloaded provisioningprofile (incorrect setting) with my local entitlements file (correct setting).

Can someone please describe what is necessary to perform signing using codesign in a system that runs as LaunchDaemon. All workarounds like placing the codesigning cert + private key a custom keychain and unlock it in the session of the LaunchDaemon doesn't work anymore on Sequoia. Or are there alternatives for signing MachO binaries without codesign?

Hi, I'm doing Java 22 experiments with open source package "wgpu-macos-aarch64-release" on my Mac M3. This library contains a .dylib file and a .a file. In Java you can load native dynamic libraries using JNI. I used that in the past. Now in MacOS 15 this stopped working. Currently, I compile my Java file and run the binary file on the command line, including the library directory. The application would load the library from that directory. This should normally works but the library is not loaded. After some investigation it seems the .dylib is rejected by MacOS. Calling spctl --assess --verbose=4 libwgpu_native.dylib gives libwgpu_native.dylib: rejected without any extra reason message. Using sudo xattr -rd com.apple.quarantine libwgpu_native.dylib doesn't solve the problem. I also can't "accept" it in "Privacy & Security" because it's run as a command line call. I know that code signing should be done for "complete" applications. But these are just experiments and working with single dynamic libraries. How should this be done, to be able to load those libraries in a Java command line program? Or in general, how can you load an unsigned dylib in an application (apart from using Java as a tool). Kr, J

Can you please revoke my developer id application and installer certs? So i may recreate. I deleted the private key by mistake before realizing i cannot recreate everything using the developer website portal. I dont have macos backup or did i backup my certs with attached pkey. I just did not realize this was important until now. Please help as Im now blocked. I opened a case too but i have not yet got a response. its been 3 days now. case id: 20000093632858

My app is a Safari extension. When trying to validate the app, I get the following error: App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "app.rango.Rango.pkg/Payload/Rango for Safari.app/Contents/MacOS/Rango for Safari" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. I don't know why this is happening. I have app sandbox enabled in both the app and the extension target. I have both entitlement files. When executing codesign -d --entitlements :- /path/to/binary I get the following: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.files.user-selected.read-only</key><true/><key>com.apple.security.get-task-allow</key><true/><key>com.apple.security.network.client</key><true/></dict></plist> If I check on Activity Monitor, on the sandbox column it shows true. I have no idea why I keep getting this error when all indicates that the app is actually sandboxed.

We have a MacOS application that we plan on distributing standalone (it'll be installed through MDM or directly, not through the app store). We utilize endpoint security and full disk access for this (enterprise) app. I have a makefile that uses codesign to sign the app inside-out. All that appears to work (i.e., when I try to run the app directly it functions as I expect it to). What's the recommended way to allow the developers in my team to also sign the app for local development so it functions as close as possible to production? My first thought is to distribute the developer identity to their machines using MDM. However, ideally i'd like to rule out the ability for a developer who has the MDM profile assigned to export the keys. That really only leaves a centralized solution in place or disabling SIP on their system (which I don't want to do). Alternatively, would creating a separate identity for production make more sense, so that in the case the developer certificate is revoked, the production releases continue to function as normal (however, I assume this would also require creating two different profiles for the endpoint security entitlement--one for each certificate). Thanks! Derek

Howdy, I thought this would be an easy question, but it turns out it's really not! In fact, it flies in the face of how the Apple ecosystem is set up. That said, I still need an answer to be able to inform our customers of what their app update options are. The question: Does app store provisioning ever expire? Based on the very limited information I can find, it either expires in one year, two years, or never. Anecdotal evidence seems to indicate that the answer could be never, but I need to confirm this. The use case: Some of our customers are very old school. They tend to find a technical solution and stick with it. As such, they do not update apps regularly on their field iPads. They generally only update when they are forced to. They use MDM to deploy the app, and would set the MDM not to pull updated apps from the app store when available, essentially keeping the same version of the app in use for as much as 3 years or more. If this were to happen, I need to know if the provisioning for the old version of the app will ever expire if they get it from the app store. I know with an enterprise deployment of .ipa files via MDM, the app provisioning/certificate will expire after 1 or 2 years (can't remember which atm), but I can't find an answer about app store provisioning. Hopefully someone can provide me with an answer on this forum. Thanks in advance, Mapguy

I'm about at my wit's end trying to figure out why I can sign and notarize code, but am unable to staple the notarization, no matter what I do. I've reinstalled Xcode, reinstalled certificates, and tried about every suggestion that I can find, but still no luck. 2023 M3 MacBook Pro, OS X 15.3.1, Xcode 16.2. I have created a very basic Xcode app to test this with. I am building the project: codegen generate && xcodebuild -project SimpleNotarizationTest.xcodeproj -scheme SimpleNotarizationTest -configuration Release clean build (see attached file for build log) build-log.txt The signature and entitlements verify: codesign -d --entitlements :- ~/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-*/Build/Products/Release/SimpleNotarizationTest.app Output: Executable=/Users/minter/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-ecqihdiubptfnldimmjgnqpjr xun/Build/Products/Release/SimpleNotarizationTest.app/Contents/MacOS/SimpleNotarizationTest warning: Specifying ':' in the path is deprecated and will not work in a future release <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple .com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.app-sandbox</key><true/><k ey>com.apple.security.files.user-selected.read-only</key><true/></dict></plist> I created a zip file: ditto -c -k --keepParent ~/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-*/Build/Products/Release/SimpleNotarizationTest.app SimpleNotarizationTest.zip I submitted the app for notarization and it was approved: xcrun notarytool submit SimpleNotarizationTest.zip --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" --wait Output: Conducting pre-submission checks for SimpleNotarizationTest.zip and initiating connection to the Apple notary service... Submission ID received id: d2c0d6b0-cd55-4fa6-b958-09767d562a33 Upload progress: 100.00% (23.6 KB of 23.6 KB) Successfully uploaded file id: d2c0d6b0-cd55-4fa6-b958-09767d562a33 path: /Users/minter/tmp/simple-app-stapling/SimpleNotarizationTest.zip Waiting for processing to complete. Current status: Accepted......... Processing complete id: d2c0d6b0-cd55-4fa6-b958-09767d562a33 status: Accepted I attempt to staple the app: xcrun stapler staple -v ~/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-*/Build/Products/Release/SimpleNotarizationTest.app And it fails. See verbose stapling log. verbose-stapling-log.txt The top line is that it finds and downloads the ticket, but can't/won't staple. Downloaded ticket has been stored at file:///var/folders/dd/cgm9_v3n399_zqqsphgzs5jh0000gn/T/1b7cb7d8-9a9e-462c-831b-09de1b896d9e.ticket. Could not validate ticket for /Users/minter/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-ecqihdiubptfnldimmjgnqpjrxun/Build/Products/Release/SimpleNotarizationTest.app The staple and validate action failed! Error 65. Wade-Minter~/tmp/simple-app-stapling(:|✔) % From my debugging, I can say: The code signature appears valid and includes a secure timestamp from Feb 23, 2025 The app is properly signed with Developer ID Application The notarization ticket is being successfully retrieved from Apple's servers (as shown in the verbose output) The ticket is being downloaded to a temporary location, but the stapler is failing to validate it with error 65 The app bundle structure appears complete with all required components The CDHash matches between the code signature and the notarization ticket: 604544b32d7074dd77e2e6f2070f6e2d41f6368d If I run: spctl -a -vv ~/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-*/Build/Products/Release/SimpleNotarizationTest.app The output is: Wade-Minter~/tmp/simple-app-stapling(:|✔) % spctl -a -vv ~/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-*/Build/Products/Release/SimpleNotaspctlionTest.app /Users/minter/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-ecqihdiubptfnldimmjgnqpjrxun/Build/Products/Release/SimpleNotarizationTest.app: rejected source=Unnotarized Developer ID origin=Developer ID Application: Fourth Line LLC (6U2KJ5KDT4) To summarize: The app is being recognized as "Unnotarized Developer ID" despite successful notarization The stapler is able to retrieve the ticket but fails during validation The error code 65 consistently appears during stapling attempts All code signing and bundle integrity checks pass The notarization ticket is being successfully downloaded but not successfully attached Any insight will be appreciated, since I've exhausted every option that I can find.

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?