I’m having issues trying to codesign a .app file. We generated the Developer ID Application certificate using the organization owner’s account. I downloaded the certificate to my Mac and imported it into my keychain, but when I run the codesign command below, I get the following error. Could you help me? What am I doing wrong? Is there any other way to sign the .app executable? From what I’ve seen in other posts, it looks like the certificate needs to have a private key, but the certificate I download from the developer portal doesn’t include the key. Also, about exporting it as a .p12 — I couldn’t quite understand if that’s considered a safe practice, since the organization owner’s private key would be included in this certificate that we plan to use in our pipeline.

I have an app that only crashes once it's been notarised. I read a few posts that essentially said before trying to identify issues by reviewing the crash report I should ensure signing and notarisation has happened correctly. I've worked through the document "Resolving common notarization issues" spctl -vvv --assess --type exec: gives no errors and correctly returns my developer id. codesign -dvv: returns a timestamp My app uses a hardened runtime. My app shows up in Xcode as a macOS Archive (e.g not a Generic Xcode Archive) Here is the crash report. Translated Report (Full Report Below) Process: Scene Finder [44479] Path: /Users/USER/Downloads/Scene Finder.app/Contents/MacOS/Scene Finder Identifier: Version: 0.9 (20250206.1) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2025-02-11 13:09:03.7786 +1000 OS Version: macOS 15.3 (24D60) Report Version: 12 Anonymous UUID: EE8B1269-0A8A-3AB6-516B-C752E8A18B5A Sleep/Wake UUID: 436CD7CF-7B13-4A9C-9425-7EF94CC007A9 Time Awake Since Boot: 98000 seconds Time Since Wake: 9524 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Scene Finder [44479]

Hi all, I'm developing a simple Finder Sync Extension, using Xcode 16.3. When running in Debug with Xcode, everything works fine. Instead, when compiling in Release and launching the containing app (by double-clicking on it), the Extension is not recognized (neither loaded) by the system. The only difference between Debug and Release stands in Signing configuration: Debug: Release: As you can see, in Release I'm using a Provisiong Profile, configured with my company's Developer ID. I'm wondering if Capabilities and Entitlements are not what is needed by my app. Anyway, I have no idea what the issue is. Any suggestion will be appreciated. Thank you in advance _Alex

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""

Hey all! I'm building a Python based app with PySide6-deploy. This gives me a .app directory with all the necessary things already in it. To be able to distribute this I provided just the .app path to the codesign looking like this: codesign -s "My Name" --keychain "keychain" -f --deep RenderRob.app If I try to check or sign the package, it looks promising: codesign --verify ... RenderRob.app: valid on disk RenderRob.app: satisfies its Designated Requirement Unfortunately this signed package does not work when checking with spctl. spctl --assess --verbose RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: rejected If I look in the log of the notarizing, I saw that something is off with signature of the binary dependencies. Then I checked the binary dependencies, it turns out it complains about an edited signature: codesign -dv -verbose=4 RenderRob.app/Contents/MacOS/libcrypto.3.dylib RenderRob.app/Contents/MacOS/libcrypto.3.dylib: edited signature Mach-O thin (arm64) [com.dreisicht.renderrob] I then also tried to move this into RendeRob.app/Contents/Frameworks, but there it's also having the same issue. Any idea what this could be?

How can I disable Hardened Runtime in Xcode only when signing ad hoc? If I make a new project, Xcode will say Disabling hardened runtime with ad-hoc codesigning. at the beginning of the build logs. However, somehow my project isn't doing this -- it's still hardening the runtime when ad-hoc signing. What should I do to debug this?

I submitted a Mac application for a safari ad blocker extension about 15 hours ago and it's still in progress. Is it normal for notarization to take this long? It's my first time submitting something for notarization so maybe that's why it's taking longer than expected? ID: 8BDB3D5E-3A42-469F-9479-AC76229C6BB5

我们开发了一款SDK，并用自签名证书对SDK进行了签名，我们的证书会在2025年1月30日到期，到期后对已发布至appstore的app会有影响吗？ 用户在2025年1月31日打开app时，会因为自签名证书到期而闪退吗？有不少app集成了我们的SDK，这个问题对我们来说非常紧急和重要，麻烦尽快回复，谢谢！ 以下是我们的签名步骤： 自签名步骤：self-signed certificate xcframework 1、钥匙串创建：证书助理-创建证书-自签名根证书+代码签名 2、自行签名根证书修改信任设置 3、对已经打包好的xcframework进行签名 （官方命令示例）codesign --timestamp -v --sign "证书名字" ~/Desktop/MySDK.xcframework

Hi, I recently got a consistent delay from notary tool. I have viewed all your suggestions and understand that it "occasionally" will have further review and take longer time, but then it will be faster. However, in my case, my app although is accepted many times. It is still significantly delay. It is a native macOS app called ConniePad. Whenever I submit, it took me 2 days or more to finish notarise, which significantly affect my business. Could you please have a look on it. For log detail about the time, and the ids: -------------------------------------------------- createdDate: 2025-04-05T22:54:45.815Z id: 998b5aa8-fc9c-4469-98fe-950d815e734e name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-05T21:32:22.679Z id: c7b1ab49-6f46-4998-8d06-2ffe8a180c8f name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T08:39:52.594Z id: aa33d9d0-9d2f-4296-8fc3-d7e0b404596b name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:23:31.077Z id: b0333d78-497d-491c-b36c-bdfb64520296 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:17:20.925Z id: 83aa12f2-f1bb-457f-940a-4c2281cf8a5f name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:12:52.932Z id: 0a921069-fb37-469a-bfb0-6be82e9320ba name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T01:03:30.584Z id: a607fe3c-d10f-43d6-a184-e97df7b632fd name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T00:52:47.322Z id: c42d0ca0-db8a-4431-b5b4-646ccfcad003 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-03T00:28:18.626Z id: 7ef8777f-7add-4440-abb5-3c0b19cf92d4 name: ConniePad.app.zip status: Invalid -------------------------------------------------- createdDate: 2025-04-03T00:24:37.320Z id: 36bb1285-0aeb-4c48-b23c-fac737a3d93f name: ConniePad.app.zip status: Invalid -------------------------------------------------- createdDate: 2025-04-02T23:59:27.940Z id: bb4578a5-a67b-49e8-afd0-a9d707c10091 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T08:51:38.295Z id: 93ff89f4-98d3-45ac-9ee8-9483726a9666 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T08:19:13.762Z id: 9e4a62df-3d8a-4cfa-ae9e-56ff35ffe137 name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T04:15:34.508Z id: 7ee43b74-f73f-462a-bb3d-f6bc53b1cb80 name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T02:11:53.312Z id: d675e8f6-dc30-48e9-9269-9bc376f1b29e name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-02T01:30:32.768Z id: 9901f125-4355-4812-936b-97578ac2de2f name: ConniePad-ConverterTool.zip status: Accepted -------------------------------------------------- createdDate: 2025-04-01T20:47:26.035Z id: a79265bc-8ad3-4a4b-ae39-150801aa9da9 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T22:39:54.189Z id: b808b676-a41c-4536-b4fd-4b567701adcb name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T05:21:23.607Z id: 797f5d4f-cd94-4511-9217-11e57c2c7ac3 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-18T05:18:30.707Z id: c5b5c260-fb7f-4bda-9548-f5b7e57cb2f3 name: ConniePad.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:45:37.831Z id: f24c1017-9171-4796-bf97-ea47ef83f7ce name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:38:17.981Z id: 8dd0ea7e-e810-48f9-a48f-62dcc1406284 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:33:27.649Z id: 704e339a-4d99-4e5e-8414-deb8b26c57ac name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:32:06.925Z id: 8e9b09b6-e061-4361-abc1-0bbd8f33b599 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:26:52.444Z id: 2b564641-eb87-4de9-a59c-ff5362b8bf4a name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:22:04.790Z id: 1aa158bd-0afd-4c60-8e2f-3029388710ab name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T06:17:17.141Z id: 3bffcf1d-2fd7-41ba-b70c-f85837499736 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-17T02:38:47.102Z id: 2dd2fb47-7dff-4f30-b2e0-d8c2bfcf10f5 name: ConniePad.app.zip status: Accepted -------------------------------------------------- createdDate: 2025-03-14T03:23:54.671Z id: 5cafb2a9-03e3-468e-b918-ff24b17fceee name: ConniePad.app.zip status: Accepted

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

We are facing issue with resigning the app which is developed by 3rd party. In this app we have Sharing functionality feature for which we have enabled Associated Domains capability. When we are signing the app with our certificate and profile this functionality is not working i.e when we are clicking on shared link in the app it is redirecting to app store page instead of content link. However, when 3rd party is directly using our certificate & profile then that functionality is working as expected. Could you please help us with the above issue why it is not working when we are resigning with our certificate and profile?

Hi All. I'm having a notarization issue trying to get a product built. Starting around the beginning of April, I have a notarization process failing every time with an invalid server certificate. The returned error is: Error: HTTPError(statusCode: nil, error: Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “notary-artifacts-prod.s3.amazonaws.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x107810200) s: *.s3.amazonaws.com i: Amazon RSA 2048 M01>", "<cert(0x107810c00) s: Amazon RSA 2048 M01 i: Amazon Root CA 1>", "<cert(0x107811400) s: Amazon Root CA 1 i: Starfield Services Root Certificate Authority - G2>", "<cert(0x107811c00) s: Starfield Services Root Certificate Authority - G2 i: Starfield Class 2 Certification Authority>" The problem certificate appears to be "Amazon RSA 2048 M01" which appears to be expired. The error fires in response to an 'xcrun notarytool log' command. The initial ' xcrun notarytool submit' has already worked. The build server in this case is running Jenkins, with a Makefile driven notarization stage. It all worked perfectly until a build on April 3rd, all builds have failed since. I have tried using '--no-s3-acceleration'. But that fails even faster with: Conducting pre-submission checks for ICFA.zip and initiating connection to the Apple notary service... Submission ID received id: d50a2157-7acb-4bd6-b1d1-6d0b1d52d5c9 Error: The operation couldn’t be completed. (Network.NWError error 2.) Any help or suggestions would be appreciated. Right now I have folks needing a valid build. Thanks in advance.

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’ve been wrestling with this for nearly a week now and none of the proposed fixes have worked. I’m trying to resign an app via Jenkins and have done the following: Created a custom keychain Imported the required .p12 certificates Installed the Apple WWDR certificate in the System keychain Made the login keychain my default Added my development keychain, the login keychain and the System keychain to the user keychain list Unlocked my development keychain Confirmed my signing identity is present Granted the appropriate partition list access to the keychain "security set-key-partition-list -S apple-tool:,codesign: -k pwd /Users/ec2-user/Library/Keychains/development.keychain-db" Yet when I invoke Fastlane’s resign action, I still see: _floatsignTemp/Payload/EverMerge.app/Frameworks/AppLovinSDK.framework: replacing existing signature _floatsignTemp/Payload/EverMerge.app/Frameworks/AppLovinSDK.framework: errSecInternalComponent Encountered an error, aborting! Any guidance on what might be causing this errSecInternalComponent failure or how to get the resign step to succeed would be highly appreciated.

Hi, I know my swiftui, but I'm completely new to macOS development. Using Xcode 16.2 I wrote a backup app that fits my needs. I got it to use iCloud Documents in its own container. It runs beautifully on my developing Mac. When I copy it over to my other Mac and try to open it, I just get a message that macOS can't open the app ("Das Programm kann nicht geöffnet werden") In terminal I get this message: "embedded provisioning profile not valid: file:///Users/niko/FlexBackup.app/Contents/embedded.provisionprofile error: Error Domain=CPProfileManager Code=-212 "Provisioning profile does not allow this device." I have "automatically manage signing" turned on and a Xcode Managed Profile. How can I run my app on all of y Macs?

When building to macOS on GameMaker, I get the error "this identity cannot be used for signing code" when using the Developer ID Installer certificate. The certificate was neither expired nor revoked, but nonetheless I created new certificates to start fresh but am still getting that error. I don't get issues building to iOS via GameMaker, just to macOS. If it makes any difference, I only noticed this issue started happening after I converted my Apple Developer Program account from an individual account to an organizational account, although it was weeks to months before I built to macOS via GameMaker before then, so I don't know if it correlates with that.

Hi all, I've submitted multiple notarization requests for an Electron app using notarytool since (april 12) at 6:30. All are stuck in the "In Progress" state Successfully received submission history. history -------------------------------------------------- createdDate: 2025-04-13T12:38:56.866Z id: 51897340-9547-4172-bad4-ae15f78e1ab0 name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:38:55.790Z id: ebcd8a15-613c-41e0-b8cc-6895a0a6785a name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:14:33.553Z id: 59a078dc-e613-4933-b440-8695e2204eac name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:14:32.108Z id: 987879aa-db15-405b-bd1d-76db31218f49 name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-12T22:06:30.869Z id: b1f4231c-6d13-4292-88f0-e8ce53cb0141 name: theAIParalegal.zip status: In Progress nicolasserna@Mac ~ %

I use the 'notarytool' to notarize applications and .pkg installers for Developer ID distribution. When using the notary tool with a fresh Apple Developer account, the notarization process remains stuck in the 'In progress' state. However, if I try the same app with an older developer account (one that has notarized at least one app in the past), the notarization works. All agreements are accepted in developer portal and Appstore Connect.

I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts. Is it possible to write a script that automates the entire process of codesigning the app? To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution? Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning? If possible, I’d appreciate a step-by-step explanation and a sample command-line script to: Codesign the app properly Package it into a signed .dmg Remove the quarantine attribute for local testing or distribution Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?

Hello, For my macOS app, on Xcode version 15.4 (15F31d) on macOS 14.5 (23F79) I follow Organizer > Distribute App > Direct Distribution, and I get a Notary Error "The operation couldn't be completed. (SotoS3.S3ErrorType.multipart error 1.)" It's been happening since 3 days. In the IDEDistribution.verbose.log file I see: https://gist.github.com/atacan/5dec7a5e26dde0ec06a5bc4eb3607461