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 have a misterous problem with checking DMG notarization. It fails: bash-3.2$ spctl -a -t open --context context:primary-signature -v MyApp.dmg MyApp: rejected source=no usable signature However this DMG installs fine on Big Sur 11.2.2, macOS allows to run this app, and checking of notarization for installed app was passed: bash-3.2$ spctl -a -v '/Applications/MyApp.app' /Applications/MyApp.app: accepted source=Notarized Developer ID I checked other downloaded apps (Intel or Universal). Some DMG files pass DMG notarization (for example, Audacity), and some fails (PerfectTablePlan). Why? For my app (Universal) I use the following code to codesign and notarize: codesign --timestamp --options runtime --force --deep -s "Developer ID Application: MYCOMPANY" "My.app" // Creating DMG with EULA license xcrun altool --notarize-app --primary-bundle-id MyApp -u "my@email.com" -p "abc123" --file MyApp.dmg xcrun stapler staple MyApp.dmg

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?

Notarization step fails: New AppID and password created: xcrun notarytool submit “.dmg” --apple-id “” --team-id “” --password “” --verbose --wait 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. I have reset app password many times, not result. Codesigning completes normally: Mac OS 11.5.2 Xcode 13.2.1

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

Keys can vary; an account is not necessary, as only Team Keys are suitable for notarization. It seems that Developer role is sufficient for notarization. We have tried both keys and roles of Developer and Account Manager - the behavior is the same. Multiline There are two types of API keys: Team Access to all apps, with varying levels of access based on selected roles. Individual Access and roles of the associated user. Individual kevs aren't able to use Provisioning endpoints, access Sales and Finance, or notaryTool. BlockQuote Here are the parameters used for notarization via API key: `-k, --key key-path    App Store Connect API key. File system path to the private key. -d, --key-id key-id    App Store Connect API Key ID. For most teams this will be a 10 character alphanumeric string. -i, --issuer issuer    App Store Connect API Issuer ID. The issuer ID is a UUID format string.` The notarization result shows as successful, and on the same machine, the package appears as notarized. However, when the package is transferred to another system, it is displayed as not notarized.

Hello! I've been facing an issue with notarizing a macOS app with an Enterprise API Key. Due to some misunderstanding setting up the project some years ago, the notarization step was using a developer's accounts API Key. I am looking to fix it to have everything centralized in the Enterprise account we work with, but I get "Debug [JWT] Generating new JWT for key ID" with the new key. This is using the xcrun notarytool directly to get more input. Using Fastlane it fails as: Error polling for notarization info: [11:29:25]: unexpected token at '' The project is deployed via MDM, so we need it to prevent the security warning. I used this documentation to create the key: https://developer.apple.com/documentation/enterpriseprogramapi/creating-api-keys-for-enterprise-program-api I have tried a Developer and an Admin access key, and the Account Holder has also created an Admin key but the errors keep the same. I just updated my Fastlane script to use the new key with the updated values. The old developer account key still works. I am not sure if I am missing any steps in the documentation or if this is not achievable. Important to add that all the profiles and certificates were already set up properly in the Enterprise account, the only error was using an App Store Connect Key instead of an Enterprise Key. Thanks in advance for the help.

After sending the app archive to apple notarization services, I received the following error: "The signature of the binary is invalid". This error is shown for both the arm64 and x86_64 builds of the app. Some details about the project: I have been able to notarize the app in the past, with the latest successful notarization at the start of October. The organization does have a valid developer membership. The app has no new dependencies since the last successful notarization. The project uses automatic managed signing (no visible errors in xcode). What has changed in app and development environment since the last notarization: Updated macOS to macOS 15. Updated to use new Xcode version (16) The organizations membership did expire for a bit, but is now valid. Changed apps target macOS version from 12.3 -> 13.5. What I've tried to debug / resolve this issue: Clean build folder and re-create archive. Waiting a period of time and retrying the notarization. Toggling 'automatic managed signing' off and on. Tried to look through profiles, provisions, certs to see any issues. Debug the issue with 'codesign -vvv --deep --strict /path/to/binary/or/bundle' CLI command (output said binary was valid). (https://developer.apple.com/documentation/security/resolving-common-notarization-issues) Going back to last successful notarized commit and re-notarizing from that point, but that failed as well (changed version number). Reverted a change of increasing the target macOS version (12.3 -> 13.5). Compare failed notarization app's info.plist to previous info.plist for any obvious errors. I tried to install the previous Xcode version, but it seems to be incompatible with macOS 15. Tried looking online for any other options, but only found a couple similar issues and the suggestions I already tried. I can provide further information if needed.

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.

My app has been attempting to notarize for almost 3 hours now. The status page shows everything is ok: https://developer.apple.com/system-status/ Anyone else experiencing this? Anything I can do to expedite the process? xcrun notarytool history Successfully received submission history. history -------------------------------------------------- createdDate: 2024-12-29T01:20:45.358Z id: 449ebcdd-60eb-41e3-87a7-8107fe6276c3 name: Scourhead.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-29T00:51:10.641Z id: 0054eebd-ddcc-4eb3-928f-86ce2182dbfe name: Scourhead.zip status: In Progress

I'm having issues with notarizing my Electron app using electron-builder. The build process works, but notarization gets hung up on submitting to Apple. Versions electron: 33.2.1 electron-builder: 24.9.1 @electron/notarize: 2.3.2 macOS runner: macos-latest Current Setup Using GitHub Actions for CI/CD Developer ID Application certificate is properly installed and verified Apple ID credentials are confirmed working (verified via altool) Notarization is configured in both package.json and build arguments Logs 2024-12-29T18:56:37.198Z electron-notarize:spawn spawning cmd: xcrun args: [ '--find', 'notarytool' ] opts: {} 2024-12-29T18:56:38.652Z electron-notarize:spawn cmd xcrun terminated with code: 0 2024-12-29T18:56:38.653Z electron-notarize:notarytool starting notarize process for app: /Users/runner/work/***/***/dist/mac-arm64/***.app 2024-12-29T18:56:38.653Z electron-notarize:helpers doing work inside temp dir: /var/folders/95/0ydz4d79163427j3k5crp3fh0000gn/T/electron-notarize-KxNa7e 2024-12-29T18:56:38.653Z electron-notarize:notarytool zipping application to: /var/folders/95/0ydz4d79163427j3k5crp3fh0000gn/T/electron-notarize-KxNa7e/***.zip 2024-12-29T18:56:38.654Z electron-notarize:spawn spawning cmd: ditto args: [ '-c', '-k', '--sequesterRsrc', '--keepParent', '***.app', '/var/folders/95/0ydz4d79163427j3k5crp3fh0000gn/T/electron-notarize-KxNa7e/***.zip' ] opts: { cwd: '/Users/runner/work/***/***/dist/mac-arm64' } 2024-12-29T18:56:47.906Z electron-notarize:spawn cmd ditto terminated with code: 0 2024-12-29T18:56:47.906Z electron-notarize:notarytool zip succeeded, attempting to upload to Apple 2024-12-29T18:56:47.906Z electron-notarize:spawn spawning cmd: xcrun args: [ 'notarytool', 'submit', '/var/folders/95/0ydz4d79163427j3k5crp3fh0000gn/T/electron-notarize-KxNa7e/***.zip', '--apple-id', '*********', '--password', '*********', '--team-id', '*********', '--wait', '--output-format', 'json' ] opts: {} This is the farthest I've been able to get after pushing through many errors.. I set a timeout of 3 hours and this will now be my 4th time attempting I believe. Configuration package.json json "mac": { "hardenedRuntime": true, "gatekeeperAssess": false, "entitlements": "build/entitlements.mac.plist", "entitlementsInherit": "build/entitlements.mac.plist", "notarize": { "teamId": "APPLE_TEAM_ID WAS MANUALLY PUT HERE AFTER ISSUES WITH SECRETS" } } GitHub Actions Workflow Using samuelmeuli/action-electron-builder@v1 with proper environment variables for APPLE_ID, APPLE_TEAM_ID, and APPLE_APP_SPECIFIC_PASSWORD. What I've Tried Verified Apple Developer account access and Team ID Confirmed certificate installation works Tested credentials using altool (successfully lists providers) Added explicit notarization environment variables Any help would be appreciated!

Hello Team, I am building an Electron app and building platform-related installers line exe, appimage and dmg. To build an installer, I am using the electron builder library. When I do code signing and notarization, the signing process gets stuck without any error. I have verified certificate and other information are correct. Below are more details. Versions @electron/notarize": "^2.5.0 @electron/rebuild": "3.3.0 electron": "26.2.1 electron-builder": "^25.1.8 electron-devtools-installer": "3.2.0 Current Setup CircleCI pipeline Developer ID Application certificate is properly installed and verified Notarization is configured in both package.json and build arguments I see the last log as below where it gets stuck without any error. • selecting signing options file=release/build/mac-arm64/xxxx Assistant.app entitlements=assets/entitlements.mac.plist hardenedRuntime=true timestamp=http://timestamp.apple.com/ts01 requirements=undefined additionalArguments=[] Package.json "build": { "productName": "xxxxx - Your AI Work xxxxx", "executableName": "xxxx xxxxx", "artifactName": "xxxxx-Assistant-${version}-${arch}.${ext}", "appId": "org.erb.xxxx", "asar": true, "asarUnpack": "**\\*.{node,dll}", "files": [ "dist", "node_modules", "package.json", "assets/tray.ico", "!**/*.lproj/**/*", "!**/locale.pak", "!locales/**/*" ], "afterSign": ".erb/scripts/notarize.js", "mac": { "timestamp": "http://timestamp.apple.com/ts01", "identity": "xxxxx Technology Inc (xxxxxxxx)", "target": [ "dmg", "zip" ], "electronLanguages": [ "en-US" ], "icon": "build/mac-icon/Logo512x512.icns", "type": "distribution", "hardenedRuntime": true, "entitlements": "assets/entitlements.mac.plist", "entitlementsInherit": "assets/entitlements.mac.plist", "gatekeeperAssess": false }, "dmg": { "icon": "build/mac-icon/xxxxxxLogo512x512.icns", "contents": [ { "x": 130, "y": 220 }, { "x": 410, "y": 220, "type": "link", "path": "/Applications" } ] }, "directories": { "app": "release/app", "buildResources": "assets", "output": "release/build" }, "extraResources": [ "./assets/**" ] } Entitlement <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <!-- Required for Electron/Chromium JIT --> <key>com.apple.security.cs.allow-jit</key> <true/> <!-- Required for basic Electron functionality --> <key>com.apple.security.inherit</key> <true/> <!-- Required for network communication (REST APIs) --> <key>com.apple.security.network.client</key> <true/> </dict> </plist> I have made the following verification. I already tried on multiple macos with different processors. Verified on a high-speed network. Certificate is exported to .p12 and verified. All Env Variables are set with the correct value. (APPLE_APP_SPECIFIC_PASSWORD+APPLE_ID+APPLE_TEAM_ID ) I have tried with CSC_LINK/CSC_KEY_PASSWORD + Keystore as well. Appriciate any help.

Hi there, I've developed a macOS app in Swift and SwiftUI. I'm planning to distribute the app outside of the App Store, so I'm currently getting it notarized. This is my first time notarizing an application. My application is signed correctly during the build / archive process, but whether I try to notarize the .app via Xcode's organizer or a .dmg via notarytool, it seems to get stuck. The status of Notarization attempts have been been stuck "In Progress", with the earliest attempt approaching 4 days. Below is the output of xcrun notary tool history Successfully received submission history. history -------------------------------------------------- createdDate: 2025-01-01T08:25:21.033Z id: be860d89-9edd-4330-9358-aa3766772041 name: Sidekick.zip status: In Progress -------------------------------------------------- createdDate: 2024-12-31T17:08:37.493Z id: 9cbd609e-d287-4217-afe3-362386159805 name: Sidekick-beta.dmg status: In Progress -------------------------------------------------- createdDate: 2024-12-31T15:35:11.609Z id: 3e22c207-e156-410d-a0d1-24a587bfdca6 name: Sidekick.zip status: In Progress I've been searching for similar issues on the developer forums, and while others have warned about long wait times for first-time notarization requests, I've never come across anyone else who had to wait 4 days.

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