It has been 3 days and it is still in progress. As you can see in the history, I retried a few hours after the initial attempt, both are stuck. For what it's worth, this is my first notary attempt on this Apple Developer Account, I am aware that first-time submission can take longer. What should I do at this point? Wait another few days? Is there a human in the loop that needs to manually allow my submission? I have seen posts about this for the last 2 years. Seems like Apple is not going to do anything about it, xcrun notarytool history --keychain-profile '[redacted]' Successfully received submission history. history -------------------------------------------------- createdDate: 2024-11-30T01:59:08.408Z id: 3de4f35a-a950-4b34-8a74-21252b3e49a4 name: Notes.ai.zip status: In Progress -------------------------------------------------- createdDate: 2024-11-29T20:49:53.437Z id: 268e5416-640c-419f-b22a-efe55212b50a name: Notes.ai.zip status: In Progress

I am reaching out regarding a persistent issue I have been facing with code signing. Despite extensive troubleshooting, I am unable to resolve the problem, and I would greatly appreciate your assistance. When attempting to sign my electron application with codesign with the following command: codesign --keychain ~/Library/Keychains/login.keychain --sign “Developer ID Application: MYNAME (DEV-ID)” --force --timestamp --options runtime --verbose=4 dist/mac-arm64/my.app I receive the following error message: “Warning: unable to build chain to self-signed root for signer ‘Developer ID Application: MYNAME (DEV-ID)‘“. This prevents me from successfully completing the code signing and notarization process. To resolve this, I have meticulously tried to troubleshoot the problem. Here are the steps taken so far: Imported Certificates into Keychains: I imported all necessary certificates (including Developer ID Application, Developer ID Certification Authority, Apple Root CA and Apple Root CA - G2) into the keychain. I tested with both the System and Login keychains (one at a time to avoid errors due to duplicates) Checked Trust Settings: I confirmed that the trust settings for the certificates are properly configured to “Always Trust.” I verified the private key is present in Keychain Access and is properly linked to the public certificate. Ensured valid identity: I ensured that the correct Developer ID identity is valid and the associated private key is available (security find-identity -v -p codesigning and security find-key -t private | grep “MY NAME”) Ensured keychain access permissions: I ensured that the respective keychain has access permissions (security set-key-partition-list -S apple-tool:,apple: -s -k ~/Library/Keychains/login.keychain) Verified matching Issuer and Subject to build certificate chain: I verified that the Issuer and Subject fields in the certificates show the correct references to build the certificate chain. Deleted and Re-imported Certificates: I deleted and re-imported the certificates multiple times to ensure there were no import issues or corruption in the certificates. Tested simplified setup: I attempted to sign simple files, such as a plain .txt file, using the Developer ID Application certificate I also attempted signing with minimal flags to rule out any issues with the app structure or build configuration Updated Xcode Command Line Tools One potential factor is that I am signing the application on a different machine from the one where the certificates were originally generated. I included the private key when exporting the certificate as a .p12 file from the original computer and imported it into the second computer’s keychain. This second computer is not connected to iCloud, and I suspect this could potentially affect the signing process. Despite all these efforts, the issue persists, and I am unable to identify the root cause. I would greatly appreciate your guidance on resolving this matter so I can successfully complete the code signing and notarization process. Thank you for your time and support.

I want to distribute a macOS application created with Electron to third parties, but I am currently unable to do so because the code signing is not working correctly. From the following response, it appears that the code signing itself was successful: $ codesign -dvvv dist/mac-arm64/AnySticky.app Executable=/Users/myname/dev/electron-tutorial/dist/mac-arm64/AnySticky.app/Contents/MacOS/AnySticky Identifier=com.electron.electron-tutorial Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=778 flags=0x10000(runtime) hashes=13+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=e105ecd3c2051554239df404c185f00fca5900de CandidateCDHashFull sha256=e105ecd3c2051554239df404c185f00fca5900de742e572c154aa889e9929186 Hash choices=sha256 CMSDigest=e105ecd3c2051554239df404c185f00fca5900de742e572c154aa889e9929186 CMSDigestType=2 CDHash=e105ecd3c2051554239df404c185f00fca5900de Signature size=9083 Authority=Apple Development: MY NAME (66MDM239Z8) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Timestamp=Dec 18, 2024 at 20:26:03 Info.plist entries=30 TeamIdentifier=9C8S7XP2UN Runtime Version=14.0.0 Sealed Resources version=2 rules=13 files=11 Internal requirements count=1 size=192 However, when I attempt to notarize the app, I receive an error stating that the app is not signed with a valid Developer ID certificate: $ xcrun notarytool submit dist/mac-arm64/AnySticky.zip --keychain-profile "AnySticky" --wait Excerpt from the error message: { "severity": "error", "code": null, "path": "AnySticky.zip/AnySticky.app/Contents/MacOS/AnySticky", "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" }, { "severity": "error", "code": null, "path": "AnySticky.zip/AnySticky.app/Contents/Frameworks/AnySticky Helper (Renderer).app/Contents/MacOS/AnySticky Helper (Renderer)", "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" }, ... I would greatly appreciate any guidance on how to resolve this issue. Thanks.

When I submit my app for notarization, it takes more than 24 hours but still shows "In progress". Does anyone else experience the same issue? Here is the history records: Successfully received submission history. history -------------------------------------------------- createdDate: 2024-12-22T07:32:20.998Z id: 81f36df5-21a2-4101-a264-9ac62e7b85a5 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-22T04:00:29.496Z id: 6d99632c-7aef-4e46-bdef-d70845cd39b5 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T10:54:48.433Z id: 1fdcd6c6-d707-4521-9b4d-4a5f3e03959a name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T10:05:02.700Z id: 4237e15e-00e3-4884-9bdd-f7f900af2dc1 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T08:40:19.404Z id: 102039b9-4a16-4fbb-8371-f9b6cb0e1a80 name: Gatsbi.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-21T07:31:01.588Z id: b6f82941-1ac2-4f5d-99ed-c44141934a0d name: Gatsbi.zip status: Accepted

Hi Everyone, Just a quick, and what is probably a really simple question. Do I require a 'Paid' Apple Developer account if I just wish to notarise my application for use on my local network. I don't see myself needing to use the App Store in the near future. I know I can manually add the app and authorise it, but I'd like to avoid this. Kindly Ryn

We notarize all of our apps as part of our nightly build. Every few weeks Apple changes something in the developer agreement, and therefore require the primary account holder to accept the new terms. However, this means our nightly builds break until the terms are accepted, which is a true pain in the ass. Is there some way to tell notarytool to force the notarization? Or tell the lawyers to chill tf out? This seems to happen every 2-4 weeks.

Hello, I've developed an application using Electron with Javacript. I have managed to deploy to both Windows and the web but having trouble deploying the application to my Mac users. It's my first time deploying an application for Mac but feel like I'm stuck at the last hurdle and out of ideas so I'm reaching out for help. My application is successfully signing but during the build and when my Notarize.js is running it seems to get stuck indefinitely. I can check and see the status of the Notarize attempts but they seem to be stuck "In Progress". Here are the logs. Successfully received submission history. history -------------------------------------------------- createdDate: 2025-01-06T00:59:45.245Z id: 1dc39b5f-fdca-4bf2-a6f6-fa793de2786e name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-04T08:01:36.168Z id: c575b015-edd6-4e09-8da5-7ae09f4f67db name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-03T08:30:31.528Z id: 570ae540-8cce-4418-ab09-7f6be33dc245 name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-03T07:57:56.701Z id: 42748de8-026a-4663-9fd2-88c7608588d3 name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-03T06:30:19.569Z id: 5140caa0-df14-491a-b148-82015f9856da name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-03T05:56:28.916Z id: 535c6be1-4999-4b3e-9766-42512a8deb67 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-03T02:51:04.893Z id: ead2268c-62b2-4b4b-8850-c1cdb5313d6a name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-03T01:50:51.954Z id: d0c44281-a788-4704-a057-4620d284516d name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-03T00:48:54.445Z id: 3d13727c-06a3-49d7-902b-4001522107c3 name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-02T13:35:26.715Z id: 1823a550-a9ff-467a-8a60-dd3e42305258 name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-02T13:23:41.894Z id: cbc341a2-9a51-43d6-83ae-713443c84fec name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T12:21:44.561Z id: 1af34419-655f-49b8-bea0-05b4232c46a7 name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-02T11:34:03.732Z id: 8c4ab3b5-2ea9-4220-9667-94011bcf76fb name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T11:19:16.052Z id: 093dfb8a-9058-417d-acd3-8ea5d0bb654a name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T11:13:14.676Z id: 556b7c1c-d114-4717-b0f7-4f1614ada845 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T10:52:36.834Z id: ce3d3c8a-d218-4978-8757-2ca9d12aad76 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T09:27:13.535Z id: b65ec764-baab-444d-809b-e4242d70548b name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T09:27:01.176Z id: be228acc-e6a2-48f2-937b-5b2962275052 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T09:19:19.182Z id: d99fc10b-c424-4d0c-a2aa-37a9e9165d91 name: Popcorn-1.0.0.dmg status: In Progress -------------------------------------------------- createdDate: 2025-01-02T08:55:43.064Z id: 2e7f8df7-9c0b-4dd0-8df7-8f3428c0bfa0 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T08:19:48.676Z id: 678355da-e413-4b1a-92a8-776a6ff6a055 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T07:58:48.278Z id: 8591f8d7-1d57-4e80-af90-d77190160a20 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T07:54:41.193Z id: f029dfeb-3f14-4f65-83e2-d9356ef6ac00 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T07:27:50.613Z id: 574f2563-d533-4885-947a-2f57170196af name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T07:09:54.203Z id: 589f7f3a-d231-4911-8ad6-9d2c15a61ac0 name: popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T05:39:02.574Z id: 9edd43de-6d14-4743-87fc-ab570bee7399 name: Popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T04:36:12.342Z id: ba02116d-1aad-4521-8667-ad086b14c1cb name: Popcorn.zip status: In Progress -------------------------------------------------- createdDate: 2025-01-02T03:22:49.185Z id: b8585c81-b7f5-4c35-9bd6-62157c6ce4bc name: Popcorn.zip status: In Progress

We are developing a custom login service including custom PAM module. While it initially works correctly after installation on macOS, it becomes blocked by the system during privilege escalation (coreauthd) after unlocking the screensaver. The custom PAM module has been signed with a Developer ID certificate and submitted for notarization using notarytool. And passed staple check. spctl -at open --context context:primary-signature -v pam_custom.so: accepted source=Notarized Developer ID Here are the detail steps: Install the custom PAM file under /usr/local/lib/pam/. Ensure SIP (System Integrity Protection) is enabled. Log in to the Mac using the custom login service developed with the custom PAM module. Successfully log in. Open System Settings > Touch ID & Password. Click Add Fingerprint to trigger local authentication. This local authentication can be passed using Touch ID without invoking the custom PAM. Cancel adding fingerprints. Allow the Mac to idle until the screensaver is triggered. Unlock the screen using the custom PAM. Go to System Settings > Touch ID & Password and click Add Fingerprint again. This time, local authentication triggers the custom PAM, but it always fails. The system log shows that the custom PAM is not found. Related system logs at step 9: 2024-12-25 19:05:05.320264-0800 0x42f3 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'authorizationhos(941)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. 2024-12-25 19:05:05.320629-0800 0x42f3 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'authorizationhos(941)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. Related system logs at step 11: 2024-12-25 19:05:22.510658-0800 0x41a6 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'coreauthd(653)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. 2024-12-25 19:05:22.510953-0800 0x41a6 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) Library Validation failed: Rejecting '/usr/local/lib/pam/pam_custom.so' (Team ID: none, platform: no) for process 'coreauthd(653)' (Team ID: N/A, platform: yes), reason: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. 2024-12-25 19:05:22.511624-0800 0x41a6 Default 0x16b99 653 0 coreauthd: (libpam.2.dylib) in openpam_load_module(): no pam_custom.so found Why does local authentication call the custom PAM after unlocking from the screensaver? Could this issue also be related to a code signing configuration that needs adjustment?

Hi, Since about 2 weeks notarytool is not very reliable on our CI/CD server. The tool either exists without printing any reason (killed by a signal; not caused by timeout - we have 6h timeouts and the tool gets killed after about 30 mins) or the process takes a very long time e.g. 2h to complete. We use the same pipeline since at least 2 years and we did not have this problem before. Some problematic calls: createdDate: 2025-01-15T14:50:22.545Z id: ca0faad3-789a-4842-a8c9-14aa7c2297a9 name: xxxxxx status: In Progress -------------------------------------------------- createdDate: 2025-01-15T14:33:06.813Z id: 22df0da8-70de-4dd9-935d-a26055242014 name: xxxxxx status: In Progress -------------------------------------------------- createdDate: 2025-01-15T14:18:36.436Z id: 5729b836-69f0-4526-b1d2-7743bd4d57a6 name: xxxxxx status: In Progress -------------------------------------------------- createdDate: 2025-01-15T14:18:31.716Z id: 58f3c7a1-96bd-4f5d-8a3c-6860f925659e name: xxxxxx status: In Progress Can anyone check why the tool is taking now way more time than before to process a submission? The app that we are notarizing did not change that much.

Hello, I've been trying to notarize a Unity 2023.2 app since yesterday, but our submissions stay stuck in In Progress. The first one has been running for 18 hours now with no signs of stopping, and two more attempts have been made since with no results. Here are the submission IDs in case someone on the team wants to take a look: 00ef6def-601b-46f3-a94f-699d8956a28f d03f5748-2261-430c-934e-14fa9679afd9 a42d3b5c-3cdb-4bf2-9c86-c92320358ff3 Thank you!

I have built a flutter desktop app and I notarized it. I have to distribute it directly as I cannot turn on App Sandboxing due to the functions included in the application. I created a build of the app from Xcode and then uploaded it for notarization and it was successfully notarized. If I compress that app into a .zip and share it over the internet, it successfully opens on any computer. But when I create a dmg using appdmg from npm and I try to distribute it, it does not open and shows me the option to either move to bin or cancel. When I notarize the dmg using the command: xcrun notarytool submit "YourApp.dmg" --apple-id "email" --password "app-specific-password" --team-id "YOUR_TEAM_ID" --wait It notarizes successfully. I have also done: xcrun stapler staple "YourApp.dmg" And validated it but it does not seem to work when I distribute it over the internet by uploading on my website. It is a bit strange that when I distribute the notarized app, it does not show any error when distributed over the internet by uploading on my website and then downloading but for a notarized dmg, which is properly signed, it gives that error that wether move to bin or do nothing. Would love someone's help on this!

Hey everyone, I’m wondering if anyone has run into any issues with this. Before I uploaded, I guess maybe 20 assets of 1080 x 720, my notarization was taking around 2-3 minutes almost instant. Now I’m looking at 30 minutes. I have no idea when the notarization is going to end. I’m wondering if asset size has any impact on notarization speed, and if so, is this going to be a one-time thing or is this going to happen with all my following builds? Let me know if anyone has run into anything similar or if the notarization service is just down right now. ⁠

From time to time I see folks run into error 65 when stapling a ticket to their notarised Mac software. This post explains the two common causes of that error. If you have questions or comments, start a new thread here on the forums. Put it in the Code Signing > Notarization topic area so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Error 65 When Stapling If you directly distribute Mac software, you must sign and notarise your product so that it passes Gatekeeper. For information on how to do this, see: Notarizing macOS software before distribution, if you use Xcode Creating distribution-signed code for macOS, Packaging Mac software for distribution, and Customizing the notarization workflow otherwise The last step of that process is to staple a ticket to your notarised product. This can fail with error 65. There are two common causes of that failure: No appropriate ticket Trust issues The following sections explain how to recognise and resolve these issues. Note You are not absolutely required to staple your product. See The Pros and Cons of Stapling for more on that topic. No Appropriate Ticket Consider the following stapling error: % stapler staple "TestError65.dmg" Processing: /Users/quinn/Desktop/TestError65 2025-03-03 22-12-47/TestError65.dmg CloudKit query for TestError65.dmg (2/d812985247c75e94fd603f026991f96144a031af) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/d812985247c75e94fd603f026991f96144a031af The staple and validate action failed! Error 65. Note the Record not found message. This indicates that the stapling operation failed because there’s no appropriate ticket. To investigate this, look at the notary log: % notarytool-log b53042b6-4cbb-4cef-ade4-dae034a69947 { … "status": "Accepted", … "sha256": "f012735a6d53b17082c088627da4249c9988111d17e7a90c49aa64ebc6bae22e", "ticketContents": [ { "path": "TestError65.dmg/TestError65.app", "digestAlgorithm": "SHA-256", "cdhash": "abc27b0f2daee77b9316de3c6844fbd9e234621c", "arch": "x86_64" }, { "path": "TestError65.dmg/TestError65.app", "digestAlgorithm": "SHA-256", "cdhash": "9627c72e53d44ae77513613e2ce33314bd5ef41e", "arch": "arm64" }, { "path": "TestError65.dmg/TestError65.app/Contents/MacOS/TestError65", "digestAlgorithm": "SHA-256", "cdhash": "abc27b0f2daee77b9316de3c6844fbd9e234621c", "arch": "x86_64" }, { "path": "TestError65.dmg/TestError65.app/Contents/MacOS/TestError65", "digestAlgorithm": "SHA-256", "cdhash": "9627c72e53d44ae77513613e2ce33314bd5ef41e", "arch": "arm64" }, { "path": "TestError65.dmg", "digestAlgorithm": "SHA-256", "cdhash": "01a553c91ee389764971767f5082ab8c7dcece02" } ], "issues": null } First, make sure that the status field is Accepted. If there’s some other value, the notary service didn’t generate a ticket at all! To understand why, look at the rest of the notary log for errors and warnings. Assuming that your notarisation request was successful, look through the log for cdhash values. These represent the contents of the ticket generated by the notary service. Compare that list to the cdhash values of the code being signed: % hdiutil attach "TestError65.dmg" … … /Volumes/Install TestError65 % codesign -d -vvv --arch arm64 "/Volumes/Install TestError65/TestError65.app" … CDHash=9627c72e53d44ae77513613e2ce33314bd5ef41e … % codesign -d -vvv --arch x86_64 "/Volumes/Install TestError65/TestError65.app" … CDHash=abc27b0f2daee77b9316de3c6844fbd9e234621c … Those are all present in the ticket. However, consider the cdhash of the disk image itself: % codesign -d -vvv "TestError65.dmg" … CDHash=d812985247c75e94fd603f026991f96144a031af … That’s the cdhash that stapler is looking for: CloudKit query for TestError65.dmg (2/d812985247c75e94fd603f026991f96144a031af) failed due to "Record not found". But it’s not present in the notarised ticket. Note The term cdhash stands for code directory hash. If you’re curious what that’s about, see TN3126 Inside Code Signing: Hashes and the Notarisation Fundamentals DevForums post. What happened here is: I built the app. I signed it with my Developer ID code-signing identity. I created a disk image from that app. I signed that with my Developer ID code-signing identity. I notarised that. I then re-signed the disk image. This changes the cdhash in the code signature. Now the disk image’s cdhash doesn’t match the cdhash in the ticket, so stapling fails. To resolve this problem, make sure you’re stapling exactly the file that you submitted to the notary service. One good option is to compare the SHA-256 hash of the file you’re working on with the sha256 field in the notary log. Trust Issues Now consider this stapling error: % stapler staple "TestError65.dmg" Processing: /Users/quinn/TestError65.dmg Could not validate ticket for /Users/quinn/TestError65.dmg The staple and validate action failed! Error 65. Note how it’s different from the previous one. Rather than saying that the ticket was not found, it says Could not validate ticket. So, stapler found the ticket for the file and then tried to validate it before doing the staple operation. That validation failed, and thus this error. The most common cause of this problem is folks messing around with trust settings. Consider this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. Contrast it with this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d Number of trusted certs = 1 Cert 0: Apple Root CA - G3 Number of trust settings : 10 … Someone has tweaked the trust settings for the Apple Root CA - G3 anchor. In fact, I used Keychain Access to mark the certificate as Always Trust. You’d think that’d avoid problems, but you’d be wrong. Our code signing machinery expects Apple’s anchor and intermediate certificates to have the default trust settings. IMPORTANT Some trust settings overrides are fine. For example, on my main work Mac there are trust settings overrides for Apple internal anchors. This problem occurs when there are trust settings overrides for Apple’s standard anchor and intermediate certificates. To fix this: In Terminal, run the dump-trust-settings commands shown above and build a list of Apple certificates with trust settings overrides. In Keychain Access, find the first problematic certificate in your list. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, close the window and move on to step 8. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Repeat steps until 2 through 7 for each of the problematic certificates you found in step 1. When you’re done, run the dump-trust-settings commands again to confirm that your changes took effect.

I started the notarization process for my electron app (just a browser window loading a URL) yesterday (26/03/2025) at around 05:23 GMT. I noticed in a couple of posts here in the forum that it may sometimes take a day to notarize the first app submitted by a team, but it has been over 30 hours now. Here's the log from xcrun notarytool history. createdDate: 2025-03-26T05:23:11.102Z id: ddcb3fca-4667-4acb-8fd1-3298a7c244cc name: xolock-browser.zip status: In Progress Do help me out here, I have zero idea why this is taking so long. Thanks in advance!

I have app developed in electron.js and python and it works in ios 15 after codesigning but not in ios 14 or below I need to understand if theres a specific instruction that we need to while building the app or do I need to codesign in lower version? what can I do solve this issue??

I have been notarizing the same program for 3 years now and it's usually completed in minutes. I have not changed anything on my end, is there a reason it's taking 24+ hours all of a sudden? I have seen the posts regarding this issue for new applications where it has to "learn", but I have been notarizing the same apps for 3 years now.

Hello all, I am attempting to notarize my newly made Mac OS application using the notarization command in VS Code. "/Users/teejgotit/Desktop/Cursor Workspace/Rust CutContour v2/cutcontour-app/src-tauri/target/release/bundle/dmg/CC Studio_0.1.0_aarch64.dmg" \ --key "/Users/teejgotit/AppleCerts/AuthKey_MATVLX3.p8" \ --key-id "MATVLX9" \ --issuer "887ba428-aa39-4fb3-a3dc-f83b9145cab0" \ --wait Only to be met with a continual "Current State: In Progress.." for what has been about 1 day and 16 hours now. Current status: In Progress........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ My app and project are rather small and was curious if this is a normal thing for this to day takes for a first time notarization? Would love any help or feedback.

I am trying to notarize a simple app I made, but keep getting stuck on "In Progress". The app is a MacOS app, and I'm using XCode. I've tried all the steps listed in the links below: https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution https://developer.apple.com/documentation/security/resolving-common-notarization-issues I've had the same issue with another app, which got rejected after multiple hours. Never got to resolve this.

hey, trying to notarize my mac app rn. maybe servers are down. earlier today super fast but now slow and i need to ship. anyone having similar issue?

I haven't been able to notarize my macOS app for the past two days. Now, I believe this is an issue with the notarization process because I've tried notarizing the default app that's provided whenever you open a new Swift application, but that completely failed as well. And I've been waiting for the past two days and it's been stuck on in progress. This is the second time this has happened to me in the past two months and oftentimes I have to wait more than a day or two for the notarization to occur. I just, I don't understand why it's deadlocked like this. I've done nothing. I haven't changed my certificates. I haven't done any different configurations within my Mac. The last time that this happened, the issue went away after two days, but my biggest concern right now is that if this happens whenever we need to urgently push updates, we can't. I have absolutely no idea what to do and I'm just extremely frustrated because this is happening right before our launch day. I've been stuck on notarizing again for the past two days and I've seen no progress, I've seen no responses from support emails and the ones that do aren't even applicable to my current scenario. ⁠