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

For years, I've been shipping my apps with a Perl script that now invokes notarytool to get the notarization, using this command /usr/bin/xcrun notarytool submit --apple-id jerry@sheepsystems.com --keychain-profile SSYShipProduct --team-id 4MAMECY9VS --output-format json /Users/jk/blah/blah/MyApp.zip --wait I used this script with this command several times during September 2024 to ship my apps, and it worked. But now, the above command fails with: Error: No Keychain password item found for profile: SSYShipProduct Run 'notarytool store-credentials' to create another credential profile. Of course, I am now running later versions of macOS beta and Xcode than I was in September. Does anyone know the problem? Screenshots from Terminal and Keychain Access are attached. Thank you.

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!

Context: large platform-agnostic CLI tool built as a handcrafted bundle (not via an Xcode project) that has been successfully codesigned, stapled, and zipped; macOS 14.7.5 syspolicy_check reports App passed all pre-distribution checks and is ready for distribution. However, running the executable in the Terminal produces a "cannot be opened because the developer cannot be verified" popup. The executable does succeed after manually clearing its quarantine attribute. Having worked through Resolving Gatekeeper Problems, the only detail logged in the Console is Adding Gatekeeper denial breadcrumb (direct): ... bundle_id: NOT_A_BUNDLE. Experimental observations: a minimized trivial CLI executable with a similar bundle layout and name successfully executes without being rejected, and oddly, renaming the original bundle from "name" to "name.suffix" allows it to be successfully executed. It's unclear why the bundle name would affect Gatekeeper only in some circumstances, and we'd greatly prefer not to rename the bundle for compatibility reasons, so it would be good if there were some way to get further diagnostic detail leading to a workaround - thank you.

I'm trying to get an app notarized, which fails with this error: The signature of the binary is invalid. However, locally checking the signature does succeed: $ codesign -vvv --deep --strict TheApp.app […] TheApp.app: valid on disk TheApp.app: satisfies its Designated Requirement Performing this check on every single item in the app's MacOS folder also succeeds. Context: embedded prebuilt binaries Now, the app has something unusual about it: it embeds prebuilt binaries, arranged in various nested folders. So, the app bundle's MacOS folder actually contains another folder with a whole tree of executables and libraries: Removing these (before building) does fix the notarization issue, but obviously I'd like to keep them in. I did my best to properly sign these items: At build time, they're copied into the product by a Copy Files phase (but not signed), then signed by a script phase That signing uses the same signing identity as the running Xcode build, and enables the hardened runtime The app builds and runs correctly, even as a release build The app has runtime hardening and app sandbox enabled How should I go about diagnosing the notarization issue?

I have built my application for arm and x64 so I have two files called DeepSkyStacker.app in different directories. I have followed the instructions to notarise the arm version of the app, but an concerned about what I should do to notarise the other one - do I just zip that up and then run: xcrun notarytool submit "DeepSkyStacker.zip" --keychain-profile "Notary Profile for DeepSkyStacker" --wait xcrun stapler staple DeepSkyStacker.app again or will that mess everything up? Related to that can I use the Notary Profile I created for DeepSkyStacker to notarise other apps that are part of the same product (DeepSkyStackerLive and DeepSkyStackerCL)?? Thanks David

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

Hi, Out app is approved on app store, however we want to distribute outside apps tore as well. But notarization always fails with error: 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, Any help to address this issue is highly appreciated.

Dear Apple support, Since the last couple of days, we have some (very) long running notarization requests. Similar requests were done normally under 1 minute. This behavior is unexpected to us, and we did not see it before. The issue occurs for a small CLI tool submitted as a ZIP archive. Checking the documentation, I come across the section about "Avoid long notarization response times and size limits" (https://developer.apple.com/documentation/security/customizing-the-notarization-workflow#Avoid-long-notarization-response-times-and-size-limits). One fact is mentioned “Limit notarizations to 75 per day.” What is behavior if that limitation is reached? Is that limitation per Apple ID or per team ID? Are there some known issues about Notarization Service? Best regards, Stefan

Hi all, I’m trying to notarize a Flutter macOS app built in CI (GitHub Actions). The app builds and signs fine locally—codesign --verify --deep --strict and spctl --assess both pass. However, Apple’s notarization service consistently rejects the app with errors like: The binary is not signed with a valid Developer ID certificate: file_picker.framework The binary is not signed with a valid Developer ID certificate: file_saver.framework The binary is not signed with a valid Developer ID certificate: url_launcher_macos.framework What I’ve tried: Explicitly re-signing all frameworks with my Developer ID Application certificate and --timestamp Removing existing signatures before re-signing Ensuring correct entitlements and bundle identifier Matching the app bundle name and identifier in all places Using both codesign --deep and manual signing of each binary Local validation always passes, but notarization fails in CI Certificate: I am using a “Developer ID Application” certificate (not a “Mac Developer” or “Apple Development” certificate). The output of codesign -dvv for the problematic frameworks shows: Authority=Developer ID Application: [My Name/Team] ([Team ID]) So I believe I am not making the common mistake of using the wrong certificate type. CI Environment: GitHub Actions, macos-latest runner Flutter 3.27.2, stable channel All secrets (cert, Apple ID, app-specific password, team ID) are set up Questions: Has anyone encountered this with Flutter plugins or CI builds? Are there known issues with signing Flutter plugin frameworks for notarization? Is there a way to get more detailed feedback from Apple’s notarization service? Any advice or pointers would be greatly appreciated. I’m happy to provide logs, scripts, or a minimal project if needed. Thanks!

Product: macOS, Notarization Tool: notarytool, Stapler Tool: xcrun stapler, Application: master-billing.app, DMG: master-billing.dmg I'm attempting to notarize and staple a macOS .dmg file containing a signed .app. Notarization completes successfully, but the stapling step fails with Error 65. All tools are up-to-date and I'm following the official Apple process. #!/bin/bash set -e APP="dist/mac-arm64/master-billing.app" DMG="dist/mac-arm64/master-billing.dmg" IDENTITY="Developer ID Application: NAME (TEAM ID)" PROFILE="notarysiva" VOLUME_NAME="MasterBilling" Sign binaries and frameworks find "$APP" -type f ( -name ".dylib" -or -name ".so" -or -name "*.node" -or -perm -u+x ) -exec codesign --force --options runtime --timestamp --sign "$IDENTITY" {} ; find "$APP" -type d ( -name ".app" -or -name ".framework" ) -exec codesign --force --options runtime --timestamp --sign "$IDENTITY" {} ; codesign --deep --force --options runtime --timestamp --sign "$IDENTITY" "$APP" Create DMG hdiutil create -volname "$VOLUME_NAME" -srcfolder "$APP" -ov -format UDZO "$DMG" Sign DMG codesign --sign "$IDENTITY" --timestamp "$DMG" Verify DMG signature codesign --verify --verbose=2 "$DMG" Submit for notarization xcrun notarytool submit "$DMG" --keychain-profile "$PROFILE" --wait Staple ticket xcrun stapler staple -v "$DMG" Signing all binaries, dylibs, and frameworks... . . ✅ App signing complete. 💽 Creating DMG... ...................................................................................... created: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg 🔏 Signing the DMG... ✅ Verifying DMG signature... dist/mac-arm64/master-billing.dmg: valid on disk dist/mac-arm64/master-billing.dmg: satisfies its Designated Requirement 📤 Submitting DMG for notarization... Conducting pre-submission checks for master-billing.dmg and initiating connection to the Apple notary service... Submission ID received id: 32927c3c-7459-42b4-a90c Upload progress: 100.00% (123 MB of 123 MB) Successfully uploaded file id: 32927c3c-7459-42b4-a90c path: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg Waiting for processing to complete. Current status: Accepted............ Processing complete id: 32927c3c-7459-42b4-a90c status: Accepted 📌 Stapling notarization ticket to DMG... Processing: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg . . . Downloaded ticket has been stored at file:///var/folders/1l/ht34h5y11mv3rhv8dlxy_g4c0000gp/T/5bb9e667-dfe1-4390-8354-56ced7f48fa0.ticket. Could not validate ticket for /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg The staple and validate action failed! Error 65.

Dear Apple Support, for better understanding to use the Notary Service, I would like to ask when and what have to be notarized. I am absolutely aware of using the Notary Service and which packages can be submitted and how to get the status. Scenario: We have one library which is developed by a specific team and other teams develop and deliver to customer MacOS apps which packages this library for the shipment. So, the library will be produced internally and will be shipped in different products. The library will be code signed before we make available internally. When should we notarize (and staple) this library? Directly after the code is signed or when it will be packaged in each product when it will be delivered to customer? Best regards, Stefan

Once I have built my macOS .app and signed it I run notarytool using this simple shell script: #!/bin/sh ditto -c -k --keepParent "$1.app" "$1.zip" xcrun notarytool submit "$1.zip" --keychain-profile "Notary Profile for DeepSkyStacker" --wait xcrun stapler staple $1.app rm -f $1.zip How can I export that "keychain-profile" (notary profile) so I can use it in CI/CD actions? Clearly I don't wish to expose the full invocation of xcrun notarytool store-credentials.

I have attempted all upgrades: updated xcode to 16.4 downloaded and installed Command Line Tools for Xcode 16.4 I have no issues with the installs, however when I run: > xcrun notarytool --version 1.0.0 (38) I need to be running v2.x How can I resolve this issue.

Command failed: codesign --sign 142DA07B8371F5C9BCE0FFEC6B23CDEB84F48E52 --force --timestamp --options runtime --entitlements /Users/mymac/Desktop/ElectronApp/node_modules/app-builder-lib/node_modules/@electron/osx-sign/entitlements/default.darwin.plist /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper: replacing existing signature /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/Contents/Library/LoginItems/electron Login Helper.app/Contents/MacOS/electron Login Helper: resource fork, Finder information, or similar detritus not allowed failedTask=build stackTrace=Error: Command failed: codesign --sign 142DA07B8371F5C9BCE0FFEC6B23CDEB84F48E52 --force --timestamp --options runtime --entitlements /Users/mymac/Desktop/ElectronApp/node_modules/app-builder-lib/node_modules/@electron/osx-sign/entitlements/default.darwin.plist /Users/mymac/Desktop/ElectronApp/dist/mas-arm64/electron.app/ I'm not entirely sure what's causing this issue. Has anyone else encountered this error while signing their macOS app? I’d really appreciate any guidance or solutions you can share.

Yesterday there were reported outages on the Developer ID Notary Service, but it was reported pretty late and we were able to notice the outages in real time. It says resolved now, however an error still persists: Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired. Is there an ongoing outage at this moment that is not being reported again? Our pipelines have been working flawlessly for months without intervention nor changes until the most recent outages

I'm building a custom macOS installer for my software, primarily using the builtin tools of codesign, pkgbuild, productbuild and xcrun. My product consist of a list of plugins and a CEP extension for the Adobe After Effect app. All of my bundles and binaries are properly signed using a trusted Apple Developer certificate I've generated, of type Developer ID Application. My installer is a "distribution" pkg, and has this structure(expanding it using pkgutil --expand): SceneTools-3.4.4-osx-installer ├── Distribution ├── miscellaneous.pkg ├── plugins.aftereffects2022.pkg ├── plugins.aftereffects2023.pkg ├── plugins.aftereffects2024.pkg ├── plugins.aftereffects2025.pkg ├── preinstall.pkg ├── Resources ├── scenebuilder.pkg └── uninstaller.pkg Each "child" pkg would install parts of my product in different locations in the target macOS disk(this is why I'm using that kind of style of building the custom installer). Signing each and every bundle or binary of my product, signing the "child" pkg's, then notarizing them works well with no issues, in addition signing the "final" "distribution" using productbuild --sign option also works well, but when trying to notarize the "final" pkg, the notary service fails with this error: { "logFormatVersion": 1, "jobId": "5fb38df9-ef97-4bd3-955e-7783c37ac4a8", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "SceneTools-3.4.4-osx-installer.pkg", "uploadDate": "2025-06-26T14:14:41.507Z", "sha256": "621de5d887b06ad11214255c6e91ebd9eeffb18ad8f940365f4539bd1902fe9a", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "SceneTools-3.4.4-osx-installer.pkg", "message": "Package SceneTools-3.4.4-osx-installer.pkg has no signed executables or bundles. No tickets can be generated.", "docUrl": null, "architecture": null }, { "severity": "warning", "code": null, "path": "SceneTools-3.4.4-osx-installer.pkg", "message": "The contents of the package at SceneTools-3.4.4-osx-installer.pkg could not be extracted.", "docUrl": null, "architecture": null } ] } My final pkg indeed doesn't contain any bundles or binaries directly, but that's how it should be - a container of "child" pkg. I tried various ways of working-around this issue, like: Notarizing the dmg that contains this final pkg - worked, but when opening the pkg, GateKeeper blocks the users from opening it. Wrapping the pkg inside an .app and notarizing the .app - same as above. What am I doing wrong? Does those kind of pkg like my "final" pkg aren't meant to be notarized? if so - how can I solve this GateKeeper blocks? Should I build my final pkg in a different way?

Dear Apple Developer Technical Support, I am encountering an issue with notarizing and stapling both PKG and DMG installers for our Electron-based macOS application COSGrid. Despite receiving successful notarization submission responses via notarytool, the stapling process fails with Error 65. Environment: App Name: COSGrid Bundle Identifier: com.cosgrid.pkg.COSGrid Developer ID Team ID: YB8S2XZ98K macOS Version: macOS [15.1] Xcode Version: [16.0 (16A242d)] Workflow Summary: For PKG: Build via yarn build (Vite + Electron Builder) Package with pkgbuild Sign using productsign Submit for notarization: xcrun notarytool submit COSGridMZA-2.1.10-arm64.pkg --apple-id "..." --team-id YB8S2XZ98K --password "..." --wait Conducting pre-submission checks for COSGridMZA-2.1.10-arm64.pkg and initiating connection to the Apple notary service... Submission ID received id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a Upload progress: 100.00% (235 MB of 235 MB) Successfully uploaded file id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a path: /Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGridMZA-2.1.10-arm64.pkg Waiting for processing to complete. Current status: Accepted..................... Processing complete id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a status: Accepted Receive notarization success Stapling fails: xcrun stapler staple COSGridMZA-2.1.10-arm64.pkg Could not validate ticket... The staple and validate action failed! Error 65. For DMG: Sign via codesign Submit to notarization — success Attempt to staple: xcrun stapler staple -v COSGrid-2.1.10-arm64.dmg Could not validate ticket... The staple and validate action failed! Error 65. Additional Verification: I verified the DMG’s code signature integrity: Command: codesign --verify --verbose=4 COSGrid-2.1.10-arm64.dmg Output: COSGrid-2.1.10-arm64.dmg: valid on disk COSGrid-2.1.10-arm64.dmg: satisfies its Designated Requirement Command: codesign -dvv COSGrid-2.1.10-arm64.dmg Output: Executable=/Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGrid-2.1.10-arm64.dmg Identifier=COSGrid-2.1.10-arm64 Format=disk image CodeDirectory v=20200 size=308 flags=0x0(none) hashes=1+6 location=embedded Signature size=9013 Authority=Developer ID Application: COSGrid Systems Private Limited (YB8S2XZ98K) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=1 Jul 2025 at 11:34:05 AM Info.plist=not bound TeamIdentifier=YB8S2XZ98K Sealed Resources=none Internal requirements count=1 size=180 **Verified Signature for .pkg ** pkgutil --check-signature COSGridMZA-2.1.10-arm64.pkg Package "COSGridMZA-2.1.10-arm64.pkg": Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2025-06-30 13:57:19 +0000 Certificate Chain: 1. Developer ID Installer: COSGrid Systems Private Limited (teamID) Expires: 2027-02-01 22:12:15 +0000 2. Developer ID Certification Authority Expires: 2027-02-01 22:12:15 +0000 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 Diagnostic Logs Attached: Stapler verbose logs for both PKG and DMG codesign verification output for both PKG and DMG Notarytool submission logs Ticket JSON response from Apple API API request/response headers Effective electron-builder.yaml config Key Observations: codesign verification passes successfully for both artifacts Notarization submission reports success via notarytool Stapler fails with Error 65 for both PKG and DMG Ticket JSON fetched from CloudKit API appears valid No provisioning profile used (Developer ID distribution only) Request: Could you please help investigate: Why is the stapler unable to validate or attach the ticket even though notarization completes successfully? Are there any known issues, entitlements, or workflow adjustments recommended in this case? Is any special handling required for Electron apps’ PKG/DMG packages or Hardened Runtime configurations during stapling? I can provide the signed DMG/PKG and full notarization logs upon request. Thank you very much for your assistance — looking forward to your guidance. Best regards, Murugavel COSGrid Systems Private Limited

I submitted a mac app for Notarization. For the first few tries the Notarization failed with an error "Team is not yet configured for Notarization" but few days after my account started to show "ENROLL" option again even though my membership was set to expire on 2026. I am doubting my account has been suspended. I have not received any emails from apple regarding the suspension. I have contacted support but no help yet ! This was the second year, i was paying for the membership. Could you please help me to - Help me get the account unsuspended (if it is, as there is no notification or information regarding this) If the account is suspended due to my app being submitted for Notarization then help me identify the reason so that i can fix them. Mac App is Time Tracking application that runs in background and capture periodic screenshot backlsh.com (NOTE - I am doing this after taking user consent)

I submitted a mac app for Notarization. For the first few tries the Notarization failed with an error "Team is not yet configured for Notarization" but few days after my account started to show "ENROLL" option again even though my membership was set to expire on 2026. I am doubting my account has been suspended. I have not received any emails from apple regarding the suspension. I have contacted support but no help yet ! This was the second year, i was paying for the membership. Could you please help me to - Help me get the account unsuspended (if it is, as there is no notification or information regarding this) If the account is suspended due to my app being submitted for Notarization then help me identify the reason so that i can fix them. Mac App is Time Tracking application that runs in background and capture periodic screenshot(NOTE - I am doing this after taking user consent)