I had submitted my app for notarization and it shows the below error -
"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,
I have raised a ticket in the support but no reply yet.
Kindly help ASAP
Notarization
RSS for tagNotarization is the process of scanning Developer ID-signed software for malicious components before distribution outside of the Mac App Store.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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
This afternoon notarization started throwing an error in terminal. I confirmed that the NOTARIZE_APP_LOG was created, but empty. I have been notarizing our apps on this machine (intel-12.7) with Xcode 13.4.1 for over a year without issue. Any suggestions would be greatly appreciated
9192 Bus error: 10 xcrun notarytool submit --apple-id "$ASC_USERNAME" --password "$ASC_PASSWORD" --team-id "$ASC_TEAM" "$ZIP_PATH" > "$NOTARIZE_APP_LOG" 2>&1
Translated Report (Full Report Below)
Process: notarytool [9192]
Path: /Library/Developer/CommandLineTools/usr/bin/notarytool
Identifier: notarytool
Version: ???
Code Type: X86-64 (Native)
Parent Process: bash [2167]
Responsible: Terminal [2142]
User ID: 501
Date/Time: 2024-07-02 16:29:33.5256 -0600
OS Version: macOS 12.7 (21G816)
Report Version: 12
Bridge OS Version: 8.0 (21P365)
Anonymous UUID: 9AFB52C6-5CA1-7AE0-C249-9D090ABDFD28
Time Awake Since Boot: 820 seconds
System Integrity Protection: enabled
Crashed Thread: 1 Dispatch queue: nio.nioTransportServices.connectionchannel
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000700009d77ff0
Exception Codes: 0x0000000000000002, 0x0000700009d77ff0
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process: exc handler [9192]
Topic:
Code Signing
SubTopic:
Notarization
...and some more simple command line utilities. I've code signed all executables and binary libraries I could find. This has got rid of most errors already.
Now I'm struggling with the "hardened runtime" requirements. I understand I can somehow add entitlements - but have no clue how to do that, and what to add. Somewhere there was reference to PCRE - I don't think Perl uses that itself, but certainly does deal with regexes a lot. How would I add eg. the JIT entitlement (if that was required)? Most documents refer to .mobileprovision files or similar - but I'm dealing with a desktop application.
And as all of this is rather non-standard, we don't use Xcode at all. So I wouldn't even know how to use Xcode to create a profile for an an app which is managed completely "outside" of a normal macOS development environment.
Topic:
Code Signing
SubTopic:
Notarization
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.
Hello everyone,
I'm encountering significant delays with the notarization process for our Electron application using a newly created developer account. The process is taking an unusually long time (1-2 days), which is disrupting our workflow.
Details:
We've attempted notarization multiple times over the past 2 weeks.
The process consistently takes 8+ hours before I typically abort it. (due going offline etc)
Interestingly, when I check the notary history later, it shows the notarization was actually successful.
Our application package is relatively large, which might be contributing to the delay (archive: 226 mb, app:800mb)
Recent Examples:
Current submission (still in progress): 52db12c3-4a54-4e14-9d77-e141d7f28227
Previous successful submission: 49273be6-3e13-4f3f-83a4-945114d899b9
Has anyone else experienced similar issues with notarizing applications? Are there any optimizations or best practices I should implement to reduce these processing times? I'm using the default notarization feature that comes with electron forge.
Any suggestions or insights would be greatly appreciated!
Doing it multiple times (even hours apart) doesn't help.
createdDate: 2025-03-14T13:58:40.397Z
id: eb49f8a4-bee6-432b-87de-6b11ca9d392a
name: panda-app-1.0.0-arm64.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-03-14T13:23:31.444Z
id: f6f3c938-5356-434c-aba1-c425f18cb4a7
name: panda-app-1.0.0-arm64.dmg
status: In Progress
Topic:
Code Signing
SubTopic:
Notarization
Hello everyone,
I’m trying to notarize my macOS app (DockIt.zip) using the new notarytool CLI, but every submission remains in In Progress status forever, it never moves to Accepted or Rejected. I’ve tried multiple rebuilds, credential resets, and even the Xcode GUI method, but the result is the same.
Environment
• macOS 14.x
• Xcode 15.x / Command-Line Tools 15.x
• Apple ID: afonsocruz.dev@icloud.com (Team ID: 264Z9XKCT6)
• Keychain profile: DockItCreds
Steps taken
1. zip -r DockIt.zip DockIt.app
2. xcrun notarytool store-credentials DockItCreds --apple-id ... --team-id 264Z9XKCT6
3. xcrun notarytool submit DockIt.zip --keychain-profile DockItCreds --wait
4. xcrun notarytool history --keychain-profile DockItCreds
History snapshot
167a9600-5c7c-4bc4-b984-dd967d30e161 (2025-05-19T11:37:59Z) – In Progress
7167f7c8-d448-4b35-9817-055009f2730a (2025-05-19T04:59:34Z) – In Progress
6ef0610a-595f-4c57-b0f2-f5fe783e8679 (2025-05-18T22:04:10Z) – In Progress
bddde388-a34a-42c4-afb8-f06f2b0fe8fa (2025-05-17T10:24:07Z) – In Progress
Questions
Is it normal to stay “In Progress” for so long?
Any recent service changes or outages?
How can I get more detailed logs?
Also, I'm still learning about macOS development and these steps! If there's something obvious and I was not able to see, please, take into consideration!
Thanks!
Topic:
Code Signing
SubTopic:
Notarization
I've been successfully notarizing my apps for a year or so now, with intermittent releases every so often, usually succeeding with notarization in a couple of minutes.
These apps are all written in Python, but I worked through all the jank required to get them to notarize cleanly a while ago and have no issues since.
Today I submitted a couple of builds which have been stuck for hours. They're just "in progress", so no logs I can look at, no emails or anything on my developer account page.
How can I begin to debug this?
Successfully received submission info
createdDate: 2025-06-24T18:43:37.140Z
id: 8d1a1ca9-f0ad-426f-a714-89aaf9e01a07
name: pinpal-2025.6.25.for-notarizing.app.zip
status: In Progress
I should note that in addition to the comment added within 10 minutes of creation of this issue, within the last day, we also have:
https://developer.apple.com/forums/thread/789389
https://developer.apple.com/forums/thread/789599
https://developer.apple.com/forums/thread/789995
So it seems pretty likely something is going on on the backend.
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?
Topic:
Code Signing
SubTopic:
Notarization
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.
Hi,
Since about 2 weeks notarytool is not very reliable on our CI/CD server. The tool either exists without printing any reason (killed by a signal; not caused by timeout - we have 6h timeouts and the tool gets killed after about 30 mins) or the process takes a very long time e.g. 2h to complete.
We use the same pipeline since at least 2 years and we did not have this problem before.
Some problematic calls:
createdDate: 2025-01-15T14:50:22.545Z
id: ca0faad3-789a-4842-a8c9-14aa7c2297a9
name: xxxxxx
status: In Progress
--------------------------------------------------
createdDate: 2025-01-15T14:33:06.813Z
id: 22df0da8-70de-4dd9-935d-a26055242014
name: xxxxxx
status: In Progress
--------------------------------------------------
createdDate: 2025-01-15T14:18:36.436Z
id: 5729b836-69f0-4526-b1d2-7743bd4d57a6
name: xxxxxx
status: In Progress
--------------------------------------------------
createdDate: 2025-01-15T14:18:31.716Z
id: 58f3c7a1-96bd-4f5d-8a3c-6860f925659e
name: xxxxxx
status: In Progress
Can anyone check why the tool is taking now way more time than before to process a submission? The app that we are notarizing did not change that much.
I've tried to sign/notarize/staple my Electron app via electron-builder, using electron-notarize. I tried it as well in cmd line - both times, same result.
Code signing runs without a problem.
Notarize (I did wait two days first time, now it's couple of minutes)
Stapling - failure
`Downloaded ticket has been stored at file:///var/folders/....
Could not validate ticket for....
The staple and validate action failed! Error 65.
`
I've checked, and the tickets are downloaded to said folder.
My process:
`codesign --deep --force --options runtime \
--entitlements build/entitlements.mac.plist \
--sign "Developer ID Application: Pete..." \
dist/mac-arm64/Modelist.app`
ditto -c -k --sequesterRsrc --keepParent dist/mac-arm64/Modelist.app dist/mac-arm64/Modelist.zip
xcrun notarytool submit dist/mac-arm64/Modelist.zip \
--apple-id "email" \
--password "app_specific_pass" \
--team-id "team_id" \
--wait
Conducting pre-submission checks for Modelist.zip and initiating connection to the Apple notary service...
Submission ID received
id: 8fa0b3d3-291...
Upload progress: 100,00% (98,1 MB of 98,1 MB)
Successfully uploaded file
id: 8fa0b3d3-291...
path: /Users/pete/projects/modelist2/dist/mac-arm64/Modelist.zip
Waiting for processing to complete.
Current status: Accepted.............
Processing complete
id: 8fa0b3d3-291...
status: Accepted
xcrun stapler staple dist/mac-arm64/Modelist.app
Processing: /Users/pete/projects/modelist2/dist/mac-arm64/Modelist.app
Could not validate ticket for /Users/pete/projects/modelist2/dist/mac-arm64/Modelist.app
The staple and validate action failed! Error 65.
The certs were installed via XCode.
Variables are all exported in env.
I followed the instructions for electron-builder from here: https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/
I'm sure I made a stupid little mistake, but after hours of arguing with ChatGPT we are going in circles and after clicking on almost every link in Google, I'm kindda lost.
Topic:
Code Signing
SubTopic:
Notarization
Hi everyone,
Native Instruments is encountering a critical issue with the notarization process. The xcrun notary submit command appears to be stuck and is not completing, preventing us from notarizing our apps.
Specifically, the command hangs indefinitely.
This issue started today. We've already tried the following troubleshooting steps:
Cancelling and re-running the command
Checking my internet connection
Checking the Apple System Status page
Cleaning the build folder
using a different machine
This is a major blocker for our company, as it's preventing from from us from testing and releasing some of our products.
It seems to be a similar issue as reported in https://developer.apple.com/forums/thread/772542?page=2.
Has anyone else experienced xcrun notary submit getting stuck like this? Any insights or suggestions would be greatly appreciated. I'm particularly interested in knowing if there are any known issues with the notarization service currently.
Details about my setup:
Xcode Version: 16.1
macOS Version: 14.7.1
App Type: macOS app
Thanks in advance for your help!
Topic:
Code Signing
SubTopic:
Notarization
Hi everyone!
I've send my .dmg file for notarization, it has been accepted on March 5. Since then there weren't any updates, it hasn't changed its status. What might be the problem?
Info about submission:
createdDate: 2025-03-05T12:13:18.802Z
id: 202d877d-d0c4-4211-bba4-6ebdb169a843
status: Accepted
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.
Topic:
Code Signing
SubTopic:
Notarization
Hi,
we have .pkg install package consisting of various sub packages. One of them contains presets and needs to be installed the the default preset location /Library/Audio/Presets. If this non-binary preset package is the only one in a .pkg choice notarization fails with:
"logFormatVersion": 1,
"jobId": "*",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "mypackage.pkg.zip",
"uploadDate": "2024-08-22T21:24:03.251Z",
"sha256": "*",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "mypackage.pkg.zip",
"message": "Package mypackage.pkg.zip has no signed executables or bundles. No tickets can be generated.",
"docUrl": null,
"architecture": null
},
{
"severity": "warning",
"code": null,
"path": "mypackage.pkg.zip/mypackage.pkg",
"message": "b\"Invalid component package: mypackage_vstpreset Distribution file's value: #com.mycompany.mypackage.vstpreset.pkg\\n\"",
"docUrl": null,
"architecture": null
}
]
}
Not sure, but maybe its worth noting that the causing sub packge only generates a warning, but the parent package seems to escalate this into an error.
How can a non-binary sub package be included in a notarized parent package?
Any hints or thoughts are highly appreciated, Thanks!
I am packaging an app with QtWebEngine in it, after codesign the app and the QtWebEngine Framework, the app can run properly.
The codesign result is:
valid on disk
staisfies its Designated requirements
Then I notarized and stapled the dmg file, after the dmg installed on Mac, gatekeeper still failed the check.
Here is the result for spctl:
spctl -a -t open -vvv --context context:primary-signatue Remote\ Graphics\ Workstation_.dmg
Remote Graphics Workstation_.dmg: rejected
source=Insufficient Context
Need help to identify the codesign process and the root cause why gatekeeper fail here, thanks.
Hi all,
Occasionally, our systems grind to a halt because an agreement needs signed. As you can imagine this always happens at an inconvenient time. Is there a programmatic way we can know about this, before it happens? How is everyone else handling this?
From a search through threads here and documentation, I don't see anything and thus I don't think this is possible to script, but wanted to double check.
If not possible, what kind of grace period is there between when developer.apple.com mentions something will need signed, and when it stops working? I'm not the one who can sign, so can a non-signer see this? This part is basically asking: How often does someone have to log on to "poll" for this and can this be me or does it have to be the person with access to sign the agreements.
Does the system maybe send out an email to the signer about these (in advance), that he's maybe not seeing?
Thanks!
Topic:
Code Signing
SubTopic:
Notarization
I'm trying to distribute my macOS application (a .dmg file) to customers, and I've followed all the steps to sign and notarize the application. However, when I try to install the .dmg containing the app, Gatekeeper rejects it with the error "AppName cannot be opened because developer is not verified". Even though I’ve signed the app with my Developer ID, notarized it, and verified the signature using codesign, I am still encountering issues when attempting to install or open the app on a clean macOS environment. Here’s the error I see when using spctl to check the .dmg:
spctl --assess --type open --verbose=4 output/App.dmg
output/App.dmg: rejected
source=Insufficient Context
When trying:
spctl -a -t open -vvv --context context:primary-signature output/App.dmg
output/Unbounded.dmg: accepted
source=Notarized Developer ID
origin=Developer ID Application:
My .app is signed and notarised by electron builder and I explicitly signed and notarised dmg too but still not working
Topic:
Code Signing
SubTopic:
Notarization