General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums post Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've tried to notarize my app recently and got the error:{ "logFormatVersion": 1, "jobId": "...", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization", "statusCode": 7000, "archiveFilename": "myapp.dmg", "uploadDate": "2019-06-20T06:24:53Z", "sha256": "...", "ticketContents": null, "issues": null }I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.

The notary service requires that all Mach-O images be linked against the macOS 10.9 SDK or later. This isn’t an arbitrary limitation. The hardened runtime, another notarisation requirement, relies on code signing features that were introduced along with macOS 10.9 and it uses the SDK version to check for their presence. Specifically, it checks the SDK version using the sdk field in the LC_BUILD_VERSION Mach-O load command (or the older LC_VERSION_MIN_MACOSX command). There are three common symptoms of this problem: When notarising your product, the notary service rejects a Mach-O image with the error The binary uses an SDK older than the 10.9 SDK. When loading a dynamic library, the system fails with the error mapped file has no cdhash, completely unsigned?. When displaying the code signature of a library, codesign prints this warning: % codesign -d vvv /path/to/your.dylib … Library validation warning=OS X SDK version before 10.9 does not support Library Validation … If you see any of these errors, read on… The best way to avoid this problem is to rebuild your code with modern tools. However, in some cases that’s not possible. Imagine if your app relies on the closed source libDodo.dylib library. That library’s vendor went out of business 10 years ago, and so the library hasn’t been updated since then. Indeed, the library was linked against the macOS 10.6 SDK. What can you do? The first thing to do is come up with a medium-term plan for breaking your dependency on libDodo.dylib. Relying on an unmaintained library is not something that’s sustainable in the long term. The history of the Mac is one of architecture transitions — 68K to PowerPC to Intel, 32- to 64-bit, and so on — and this unmaintained library will make it much harder to deal with the next transition. IMPORTANT I wrote the above prior to the announcement of the latest Apple architecture transition, Apple silicon. When you update your product to a universal binary, you might as well fix this problem on the Intel side as well. Do not delay that any further: While Apple silicon Macs are currently able to run Intel code using Rosetta 2, that’s not something you want to rely on in the long term. Heed this advice from About the Rosetta Translation Environment: Rosetta is meant to ease the transition to Apple silicon, giving you time to create a universal binary for your app. It is not a substitute for creating a native version of your app. But what about the short term? Historically I wasn’t able to offer any help on that front, but this has changed recently. Xcode 11 ships with a command-line tool, vtool, that can change the LC_BUILD_VERSION and LC_VERSION_MIN_MACOSX commands in a Mach-O. You can use this to change the sdk field of these commands, and thus make your Mach-O image ‘compatible’ with notarisation and the hardened runtime. Before doing this, consider these caveats: Any given Mach-O image has only a limited amount of space for load commands. When you use vtool to set or modify the SDK version, the Mach-O could run out of load command space. The tool will fail cleanly in this case but, if it that happens, this technique simply won’t work. Changing a Mach-O image’s load commands will break the seal on its code signature. If the image is signed, remove the signature before doing that. To do this run codesign with the --remove-signature argument. You must then re-sign the library as part of your normal development and distribution process. Remember that a Mach-O image might contain multiple architectures. All of the tools discussed here have an option to work with a specific architecture (usually -arch or --architecture). Keep in mind, however, that macOS 10.7 and later do not run on 32-bit Macs, so if your deployment target is 10.7 or later then it’s safe to drop any 32-bit code. If you’re dealing with a Mach-O image that includes 32-bit Intel code, or indeed PowerPC code, make your life simpler by removing it from the image. Use lipo for this; see its man page for details. It’s possible that changing a Mach-O image’s SDK version could break something. Indeed, many system components use the main executable’s SDK version as part of their backwards compatibility story. If you change a main executable’s SDK version, you might run into hard-to-debug compatibility problems. Test such a change extensively. It’s also possible, but much less likely, that changing the SDK version of a non-main executable Mach-O image might break something. Again, this is something you should test extensively. This list of caveats should make it clear that this is a technique of last resort. I strongly recommend that you build your code with modern tools, and work with your vendors to ensure that they do the same. Only use this technique as part of a short-term compatibility measure while you implement a proper solution in the medium term. For more details on vtool, read its man page. Also familiarise yourself with otool, and specifically the -l option which dumps a Mach-O image’s load commands. Read its man page for details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2025-04-03 — Added a discussion of common symptoms. Made other minor editorial changes. 2022-05-09 — Updated with a note about Apple silicon. 2020-09-11 — First posted.

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Put it in the Code Signing > General subtopic and tag it with relevant tags like Gatekeeper, Code Signing, and Notarization — so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing content in a bundle Embedding nonstandard code structures in a bundle Embedding a command-line tool in a sandboxed app Creating distribution-signed code for macOS Packaging Mac software for distribution Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. Later sections of this post address the most common ones. But first, let’s see if there’s an easy answer. Run a System Policy Check macOS has a syspolicy_check tool that can diagnose many common trusted execution issues. To check an app, run the distribution subcommand against it: % syspolicy_check distribution MyApp.app App passed all pre-distribution checks and is ready for distribution. If there’s a problem, the tool prints information about that problem. For example, here’s what you’ll see if you run it against an app that’s notarised but not stapled: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: MyApp.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error … Note In reality, stapling isn’t always required, so this error isn’t really Fatal (r. 151446728 ). For more about that, see The Pros and Cons of Stapling forums. And here’s what you’ll see if there’s a problem with the app’s code signature: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Codesign Error File: MyApp.app/Contents/Resources/added.txt Severity: Fatal Full Error: File added after outer app bundle was codesigned. Type: Notary Error … The syspolicy_check isn’t perfect. There are a few issues it can’t diagnose (r. 136954554, 151446550). However, it should always be your first step because, if it does work, it’ll save you a lot of time. Note syspolicy_check was introduced in macOS 14. If you’re seeing a problem on an older system, first check your app with syspolicy_check on macOS 14 or later. If you can’t run the syspolicy_check tool, or it doesn’t report anything actionable, continue your investigation using the instructions in the following sections. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code on systems prior to macOS 26 beta. macOS 26 beta supports arm64e apps directly. Prior to that, third-party products (except kernel extensions) were limited to arm64, except for the purposes of testing. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running App Store distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2025-08-06 Added the Run a System Policy Check section, which talks about the syspolicy_check tool (finally!). Clarified the discussion of arm64e. Made other editorial changes. 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

I started a notarization run a few hours ago. (and used --wait) Conducting pre-submission checks for Metrix Installer.dmg and initiating connection to the Apple notary service... Submission ID received   id: dd77be4c-0cb6-4913-a846-d4025ede37fd Successfully uploaded file   id: dd77be4c-0cb6-4913-a846-d4025ede37fd   path: /Users/johnluss/Work/Metrix Installer.dmg Waiting for processing to complete. Current status: In Progress................................................................................................................................. I finally ctrl-c out of it (PAGES of ....) and tried getting the log Submission log is not yet available or submissionId does not exist   id: dd77be4c-0cb6-4913-a846-d4025ede37fd The Apple System Status page shows all servers up and running. Any suggestions on what might be going wrong?

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

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

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 have been trying to notarize my application for about a month via this command - xcrun notarytool submit "Backlsh.zip" --apple-id "" --password "" --team-id "" but it throws error - { "logFormatVersion": 1, "jobId": "c8173ee6-edd2-4c51-a86b-8f3b8dea0a84", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, "archiveFilename": "Backlsh.zip", "uploadDate": "2025-03-06T05:33:56.287Z", "sha256": "b45e579f0c47070b55d74ac49e49c81d32f2315bd290ca5592f71f314018c44d", "ticketContents": null, "issues": null } I have raised ticket to apple support but i havent received any help yet ! I have tried to submit 5 times. Kindly help !

We have a macOS application packaged as a .pkg file. To notarize it, we first code-sign individual library folders and the .app bundle using the following command: codesign --force --deep --sign "Developer ID Application: <Our Account Name>, LLC (Team ID)" "Our_product.app" Code Sign result for .app file: Our_prodcut.app: valid on disk Our_product.app: satisfies its Designated Requirement We are using packages tool to create .pkg file with code signed .app file. Steps followed once .pkg file is ready: 1. Product Sign: productsign -sign "Developer ID Installer: <Our Account Name>" output.pkg signed-output.pkg 2. Submit for notorization: `xcrun notarytool submit signed-outout.pkg --keychain-profile "notarytool-password" --wait Received following output: Current status: Accepted................................. Processing complete id: 2d5c450f-5b22-4b4d-9579-ef21c0356548 status: Accepted Transferred Notarization log: xcrun notarytool log 10169892-b28c-407c-b348-edab0b34ef34 --keychain-profile "notarytool-password" Desktop/developer_log_6.json We have observed log with "Accepted" status with issues as "null". 3. Stapler: stapler staple signed-output.pkg stapler validate signed-output.pkg Processing: signed-output.pkg The validate action worked! 4. Checking status of .pkg file: Command: spctl --assess --verbose=4 signed-output.pkg Output: signed-output.pkg: rejected source=no usable signaturess Warning During Installation: While installing the .pkg file, a security warning appears as follows. Please help us to resolve this.

Hey there, I'm experiencing an issue with notarization of my macOS application, which is blocking a release. We have signing/notarization hooked up to our CI process, both for prior releases as well as development builds (at the trunk tip). The notarization process has typically taken anywhere from a few minutes to a few tens of minutes, but for our most recent release, it's taking an unreasonably long time. I've compiled the submission info for each build (+ reattempted notarizations) below. What's interesting is that the oldest one was accepted- however, it timed out our CI process, so we never actually released it. Subsequent builds are more or less identical in terms of their content, however, they've been stewing in the notarization process for over 13 hours in some cases. % xcrun notarytool info 67413dae-64f5-4372-972d-e0ac158e18e3 Successfully received submission info createdDate: 2025-04-02T16:28:25.999Z id: 67413dae-64f5-4372-972d-e0ac158e18e3 name: Warp Vault.app.zip status: In Progress % xcrun notarytool info 0c72b243-4a8d-4976-a97b-75689d7e2497 Successfully received submission info createdDate: 2025-04-02T05:49:05.861Z id: 0c72b243-4a8d-4976-a97b-75689d7e2497 name: Warp Vault.app.zip status: In Progress % xcrun notarytool info 8e2edfc2-58bc-4b33-bc8e-078155759a81 Successfully received submission info createdDate: 2025-04-02T05:23:28.870Z id: 8e2edfc2-58bc-4b33-bc8e-078155759a81 name: Warp Vault.app.zip status: In Progress % xcrun notarytool info 8fb17b0c-ace4-4b6f-bef8-68d22696814d Successfully received submission info createdDate: 2025-04-02T05:07:48.187Z id: 8fb17b0c-ace4-4b6f-bef8-68d22696814d name: Warp Vault.app.zip status: Accepted At the time of checking, the UTC date was: % TZ="UTC" date Wed Apr 2 18:42:14 UTC 2025 It's interesting to me that the notarization process is taking this long. We've notarized many development builds (with debugging flags enabled) in the time between our last public release and our attempt to notarize this one. What's more, the original build for this release was notarized within the span of about 15 minutes, but subsequent submissions of the same build have hung for tens of hours. My two questions are: How can I get our pending notarizations "unstuck"?, and To prevent these types of hangs in the future, should I also routinely build/sign/notarize non-debug builds of my application during the development process? Best regards and many thanks, Charlton

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

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 ~ %

Hello, I recently had my Electron app notarized by Apple and then performed the following steps: Stapling the Notarization Ticket: xcrun stapler staple "appPath/Aiparalegal.app" Zipping the App for Distribution: ditto -c -k --keepParent "appPath/Aiparalegal.app" theAIParalegal.zip However, after unzipping and attempting to launch the app, macOS displays the following message: Apple could not verify "theAIParalegal" is free of malware that may harm your Mac or compromise your privacy. Yet, when I run validation using: xcrun stapler validate "theAIParalegal.app" I receive confirmation: The validate action worked! I then tried restarting my computer but the problem persist Could you help me understand why the notarization validation appears successful, yet macOS still displays this security warning? Any advice on how to resolve this would be greatly appreciated. Thank you!

Hello, I recently had my Electron app notarized by Apple and then performed the following steps: Stapling the Notarization Ticket: xcrun stapler staple "appPath/Aiparalegal.app" Zipping the App for Distribution: ditto -c -k --keepParent "appPath/Aiparalegal.app" theAIParalegal.zip However, after unzipping and attempting to launch the app, macOS displays the following message: Apple could not verify "theAIParalegal" is free of malware that may harm your Mac or compromise your privacy. Yet, when I run validation using: xcrun stapler validate "theAIParalegal.app" I receive confirmation: The validate action worked! spctl -a -vvv -t install "theAIParalegal.app" theAIParalegal.app: accepted source=Notarized Developer ID origin=Developer ID Application: NIPartnership LLC (M92N2796Q9) Could you help me understand why the notarization validation appears successful, yet macOS still displays this security warning? Any advice on how to resolve this would be greatly appreciated. Thank you!

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.

Thanks in advance for any hint to solve the following account problem: I tried to store credentials for notarizing. Presumably with the wrong combination of entries (similar to signing) – using the name of my university instead of my Apple Account. xcrun notarytool store-credentials "notarytool-password" --apple-id "Berliner Hochschule fuer Technik" --team-id "8YAW3HL2QP" --password "my Apple-Account-pw" .. retried assuming a syntax error (like missing "). Got the error message: This process stores your credentials securely in the Keychain. You reference these credentials later using a profile name. Validating your credentials... `Error: HTTP status code: 401. Your Apple ID has been locked. Visit iForgot to reset your account (https://iforgot.apple.com), then generate a new app-specific password. Ensure that all authentication arguments are correct.` Happy to see: Signing is not affected and I still an can log in to my account on developer.apple.com. So notarizing “only” seems to be affected. But how to reset the account to resolve the issue? The iforgot.apple.com link does not help - I provided my iPhone-number but did not receive further messages – neither on the iPhone nor on my “developer” macbook. Many thanks in advance All the best Florian

I’m having trouble with the notary step of our electron app. It sometimes says “In progress” for days on end, where other times, it only takes 15-20 minutes. For the last few weeks, I’ve noticed that it will take longer than the 20 minutes if our app was using a not latest version of the electron module -- https://www.npmjs.com/package/electron. I would then update our codebase to build using the latest version, and then try to sign and notarize the app again, and it would work till a new version was released. This was the first time that that process didn’t work. Everything is on latest, and we’re still getting stuck “in progress” for days on end. We have been signing and Notarizing this app for years now, so it's not the first time we're trying to do this process To make matters stranger, I have two branches of the same exact code base – same dependencies, same source code, same everything – there is no difference. One sign and notarize works 100% of the time where the other one hasn’t worked yet. Any ideas would be helpful. I'm not really sure where to begin to debug this. Thanks!

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.

Hi everyone, I’m Jaswanth. My friends and I are students working on a project where we’ve developed a website and a companion app. Here’s the key functionality: When two users enter a virtual room, one of them is prompted to download a desktop app. The app is built with Python and uses psutil to check for certain running processes. It does not send any data over the internet. It has a GUI that clearly shows the system is being monitored , it’s not hidden or running in the background silently. We want to sign and notarize the app to make sure it runs on macOS without warning users. However, we’re concerned that since the app accesses system process information, it might be flagged as malicious. Before we pay for the Apple Developer Program, we wanted to ask: Will an app like this (which only reads running processes and does not exfiltrate or hide activity) be eligible for notarization? Thanks in advance for any insights. We'd appreciate any clarity before moving forward. Best, Jaswanth