Error 7000 "Team is not yet configured for notarization" - Cannot notarize any apps
I'm trying to notarize macOS apps for Developer ID distribution and consistently getting error 7000 on every submission.
Error Details:
{
"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
}
What I've tried:
Completed enrollment verification
Created new App Store Connect API key with Admin access
Created fresh App-Specific Password
Submitted via both API key and App-Specific Password authentication
All submissions are accepted and uploaded successfully, but after processing they're rejected with error 7000
Technical Details:
Active Developer ID Application certificate
Hardened runtime enabled
Apps are properly code-signed (codesign -vvv passes)
Behavior:
Over 15 submissions since December 2nd - ALL rejected with the same error 7000. The submissions upload successfully and show "In Progress" for extended periods (sometimes hours) before eventually being rejected.
Questions:
Has anyone encountered error 7000 and resolved it? What was the fix?
Are there any account settings or agreements required specifically for notarization that aren't obvious in the developer portal?
Should I contact Apple Developer Support directly, or is there a self-service solution?
Any guidance would be greatly appreciated.
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Good afternoon,
Our team is currently developing a mobile application that includes video call functionality, and we are seeking the optimal approach to enable incoming calls on iOS devices.
Ideally, we would like calls to be delivered even when the app is completely closed or after the device is restarted. As I understand it, this may require obtaining VoIP permissions; otherwise, calls may only work when the app is open or running in the background.
I would appreciate it if you could confirm my understanding and advise me on the steps or requirements for obtaining the appropriate permissions.
Currently, when I try to launch the app in XCode, I see an error (screenshot).
I am facing an issue while trying to staple a notarization ticket to my signed macOS installer package.
Details of my setup:
The .pkg file is signed using my Developer ID Installer certificate.
The app inside the package is signed using my Developer ID Application certificate.
Notarization via xcrun notarytool completes successfully with status: Accepted.
However, the stapler command fails with the following error:
xcrun stapler staple -v /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg
Processing: /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg
Could not validate ticket for /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg
The staple and validate action failed! Error 65.
I verified that all other Apple notarization-related servers (api.apple-cloudkit.com, gs.apple.com, ocsp.apple.com, ocsp2.apple.com, crl.apple.com, developer.apple.com) are reachable.
However, the domain cdn-apple-cloudkit.apple.com cannot be resolved from any network, including mobile or public Wi-Fi.
Both dig and nslookup return “No answer” even when using external DNS servers like 8.8.8.8 or 1.1.1.1.
It appears that cdn-apple-cloudkit.apple.com might be required during the stapler validation process, but the DNS for this domain is not resolving.
Could you please confirm whether this CDN endpoint is required for stapling, and if there is currently an outage or configuration issue with cdn-apple-cloudkit.apple.com?
Hi support,
Currently we are in a process of migrating our Qt application for MAC OS - ventura -v13.4.
There is a specific feature in our application in which client tries to communicate with server (Socket communication) using Qt's QsslSocket Apis . To achieve this we are using self signed Ca certificate (.pem ) generated by using openSSl commands which uses IP address of the server.
We are manually installing the certificate inside MAC OS - keychain and trusting it manually as well after installing .
This is working fine in XCode environment in debug mode in MAC OS and client -server handshake is happening successfully. How ever after creating .dmg file (installer) the same handshake is not happening and we are getting error -Connection time out.
Upon investigating this online, we got to know there has to be codesigning (both app bundle and the dmg file )along with notarization of the .dmg file in order to access keychain of MAC OS at runtime to access the self signed certificate installed.
Now we have 2 queries here.
Is code signing mandatory if we want to verify our app through keychain with .dmg file ?
If yes, whats the best way to achieve this ?
We have tried 2 options without any luck.
option1 - Trying to build our specific target among 'ALL_BUILD' with signing key settings inside xcode where we are providing developer provisional certificate with apple team ID . After that we are trying to archive to generate dmg file which is code signed.
We are failing here as the signed dmg is not getting installed due to other app related dependencies are missing .
option 2- Code signing the dmg and the app bundle manually outside the environment of xcode with developer certificate and team ID.
We are failing here as notarization needs to be done it seems to access keychain for certificate verification
If Code signing is not mandatory then whats the best possible way to achieve this considering manually installation of certificate inside keychain with adding trust option is not working at the moment.
Please specify the best solution if possible.
Topic:
Code Signing
SubTopic:
General
Hi everyone,
After I recently changed my Apple ID (iCloud) password, my Developer ID certificate stopped working for signing macOS apps.
Symptoms:
Signing fails with the Developer ID certificate that was previously working fine.
I tried re-downloading the certificate from my Apple Developer account and importing it into the Keychain, but the issue persists.
It seems that the Developer ID identity is no longer trusted or properly linked to my system since the password change.
Attempts:
Re-downloaded and installed the certificate from the developer portal.
Verified that the private key is present and linked.
Checked keychain access and code-signing identity — everything appears normal, but the signed apps are rejected or the signing process fails.
Blocking issue:
I am unable to delete or revoke the Developer ID certificate on my account (Apple Support says it's not possible).
Also, I can't create a new one due to the certificate limit.
Questions:
Is it expected for a Developer ID certificate to become invalid after changing the Apple ID password?
Is there a recommended way to refresh or restore the certificate trust on macOS?
How can I invalidate the current certificate and generate a new one if I'm stuck?
Any insights or official guidance would be really appreciated.
Thanks in advance!
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Signing Certificates
Code Signing
Developer ID
Hi,
I got the error:
/usr/bin/codesign exited with code 1:
Warning: unable to build chain to self-signed root for signer "Apple Distribution: Q.A.C.F. - Quality Academy Consultoria E Formacao, Unipessoal, Lda (xxxxxx)"
/Users/pedroramalho/Library/Caches/Xamarin/mtbs/builds/drBoxSaude.iOS/3bed3d51415af2e100a4d2bc57e1d36fb42d76ceb190de1db1c4d0dbccbff863/bin/iPhone/Release/drBoxSaude.iOS.app: errSecInternalComponent
and
/usr/bin/codesign exited with code 1:
/Users/pedroramalho/Library/Caches/Xamarin/mtbs/builds/drBoxSaude.iOS/3bed3d51415af2e100a4d2bc57e1d36fb42d76ceb190de1db1c4d0dbccbff863/bin/iPhone/Release/drBoxSaude.iOS.app/Frameworks/libSkiaSharp.framework: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Distribution: Q.A.C.F. - Quality Academy Consultoria E Formacao, Unipessoal, Lda (xxxxx)"
/Users/pedroramalho/Library/Caches/Xamarin/mtbs/builds/drBoxSaude.iOS/3bed3d51415af2e100a4d2bc57e1d36fb42d76ceb190de1db1c4d0dbccbff863/bin/iPhone/Release/drBoxSaude.iOS.app/Frameworks/libSkiaSharp.framework: errSecInternalComponent
Some one can help please
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Sign in with Apple
Signing Certificates
I've developed a Mac app distributed through the App Store that uses NSAppleScript to control Spotify and Apple Music. I'm experiencing inconsistent behavior with automation permission prompts that's affecting user experience.
Expected Behavior:
When my app first attempts to send Apple Events to Spotify or Apple Music, macOS should display the automation permission prompt, and upon user approval, the app should appear in System Preferences > Security & Privacy > Privacy > Automation.
Actual Behavior:
Initial permission prompts work correctly when both apps are actively used after my app download. If a user hasn't launched Spotify/Apple Music for an extended period, the permission prompt fails to appear when they later open the music app. The music app doesn't appear in the Automation privacy pane too. Once this happens, permission prompts never trigger again for that app
Steps to Reproduce:
Fresh install of my app
Don't use Spotify for several days/weeks
Launch Spotify
Trigger Apple Events from my app to Spotify
No permission prompt appears, app doesn't show in Automation settings
If you're using Apple Music during this time it runs without any problems.
Troubleshooting Attempted:
Used tccutil reset AppleEvents [bundle-identifier] - no effect
Verified target apps are fully launched before sending Apple Events
Tried different AppleScript commands to trigger permissions
Problem occurs inconsistently across different Macs
Technical Details:
macOS 13+ support
Using standard NSAppleScript with simple commands like "tell application 'Spotify' to playpause"
App Store distribution (no private APIs)
Issue affects both Spotify and Apple Music but seems more prevalent with Apple Music
Questions:
Is there a reliable way to programmatically trigger the automation permission prompt?
Are there timing dependencies for when macOS decides to show permission prompts?
Could app priority/usage patterns affect permission prompt behavior?
I use MediaManager to run the functions and initialize it on AppDidFinishLaunching method and start monitoring there.
Any insights or workarounds would be greatly appreciated. This inconsistency is affecting user onboarding and app functionality.
Validation failed (409)
Missing Code Signing Entitlements. No entitlements found in bundle 'com.seeyon.yiboyun.child' for executable 'Payload/M3.app/PlugIns/CMPSharePublish.appex/CMPSharePublish'." (ID: 6e5429ed-b896-45a0-ab23-bb8fcb472072)
Topic:
Code Signing
SubTopic:
Entitlements
Unable to notarize Electron-based application. All notarization attempts fail with
"The signature of the binary is invalid" for main executable and Electron Framework,
despite passing local codesign verification.
ENVIRONMENT:
macOS: 24.6.0 (Sequoia)
Hardware: Apple M4 Max (arm64)
electron-builder: 26.0.12
Electron: 36.9.5 (also tested 37.10.2, 38.2.0)
Certificate: Developer ID Application: AS LIVE MEDIA SP Z O O
Team ID: 2KJ532SU3G
Certificate validity: Oct 7 2025 - Oct 8 2030
PROBLEM:
Every notarization submission fails with identical error for two binaries:
Contents/MacOS/PresentClic Desktop
Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
Error message: "The signature of the binary is invalid."
Architectures affected: Both x86_64 and arm64
CRITICAL CONTRADICTION:
✅ Local verification PASSES:
$ codesign --verify --deep --strict "PresentClic Desktop.app"
Result: valid on disk, satisfies Designated Requirement
❌ Apple notarization service FAILS:
Error: "The signature of the binary is invalid"
LATEST SUBMISSION ID: 11e1a452-4ea7-4562-ac8e-5e76c39eeb6c
Local verification output shows all components validated:
Electron Framework: validated ✅
All helper apps: validated ✅
All frameworks: validated ✅
Main executable: valid on disk ✅
Authority chain: Developer ID Application → Developer ID CA → Apple Root CA ✅
Timestamp: Present ✅
Runtime Version: 15.4.0 ✅
CONFIGURATION:
Entitlements (build/entitlements.mac.plist):
com.apple.security.cs.allow-jit: true
com.apple.security.cs.allow-unsigned-executable-memory: true
com.apple.security.cs.disable-library-validation: true
com.apple.security.cs.allow-dyld-environment-variables: true
com.apple.security.automation.apple-events: true
Standard device/network/file entitlements
Build configuration:
hardenedRuntime: true
gatekeeperAssess: false (tested both true and false)
entitlements and entitlementsInherit: properly configured
TROUBLESHOOTING STEPS ATTEMPTED (ALL FAILED):
✅ Updated electron-builder from 24.13.3 to 26.0.12
✅ Downgraded Electron 38 → 37 → 36
✅ Tested x86_64 and arm64 separately
✅ Regenerated certificate via Xcode (new cert generated 23/11/2025)
✅ Configured App Store Connect API for notarization
✅ Tested multiple entitlements combinations
✅ Manual component-by-component re-signing
✅ Removed all metadata files (._ files)
✅ Tested both ZIP and DMG formats
✅ Automatic electron-builder notarization
✅ Manual notarization via xcrun notarytool
✅ Custom afterSign hooks for re-signing
✅ gatekeeperAssess true and false
✅ Clean builds (removed dist/ directory)
ALL attempts result in identical failure. Local codesign verification ALWAYS passes.
QUESTIONS:
Why does local codesign --verify pass but Apple notarization service fails?
Is there a known issue with Electron Framework notarization on macOS Sequoia +
Apple Silicon?
3. Are there undocumented requirements for Electron apps that could cause this?
4. Could this be a bug in the notarization service for this specific configuration?
ADDITIONAL CONTEXT:
Multiple notarization attempts over 24+ hours
Different certificates, configurations, architectures - all fail identically
No similar reports found in forums or GitHub issues
Application functions correctly when Gatekeeper is bypassed
This is blocking production distribution to macOS users
This appears to be either:
A bug in Apple notarization service for Electron apps
An incompatibility between electron-builder 26 + Electron 36/37 + macOS Sequoia +
Apple Silicon
The fact that local verification passes but notarization fails suggests the issue is
with the notarization service validation logic, not the actual code signatures.
REQUEST:
Need guidance on resolving this issue. Standard documentation and troubleshooting
steps have not resolved the problem.
Thank you for any assistance. Staszek Pliszko
Topic:
Code Signing
SubTopic:
Notarization
Hi,
I am experiencing an issue where Xcode displays a "Provisioning profile doesn't support the capability" error for the User Assigned Device Name capability, despite it being approved by Apple and visible in our provisioning profile on the Developer Portal.
Background
We have completed and submitted the required capability request form to Apple for the User Assigned Device Name capability and received approval. The capability appears correctly in our provisioning profile on the Apple Developer Portal and shows among the enabled capabilities alongside other standard capabilities like In-App Purchase and Push Notifications.
Issue
However, Xcode consistently displays the error message when trying to enable the User Assigned Device Name capability in our project settings, preventing successful builds with this functionality.
Troubleshooting Steps Attempted
We have tried multiple troubleshooting steps including:
Regenerating provisioning profiles
Performing clean builds
Clearing DerivedData
Manually installing profiles
Adding the com.apple.developer.device-information.user-assigned-device-name entitlement manually to our entitlements file
Toggling automatic signing on and off
Environment Details
Xcode Version: 16.4 (16F6)
iOS Deployment Target: iOS 13
Profile Type: Distribution provisioning profile
Capability: User Assigned Device Name
Despite the capability being approved by Apple and visible in our provisioning profile, Xcode does not recognize it. This appears to be a synchronization issue between the Apple Developer Portal and Xcode's capability validation system.
Has anyone encountered similar issues with recently approved capabilities, specifically the User Assigned Device Name capability? Could you please provide guidance on how to resolve this capability recognition issue? Any suggestions for resolving this discrepancy between the Developer Portal and Xcode would be greatly appreciated.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Xcode
Provisioning Profiles
I am trying to notarize a simple app I made, but keep getting stuck on "In Progress".
The app is a MacOS app, and I'm using XCode. I've tried all the steps listed in the links below:
https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution
https://developer.apple.com/documentation/security/resolving-common-notarization-issues
I've had the same issue with another app, which got rejected after multiple hours. Never got to resolve this.
Hi everyone,
I am trying to generate an .ipa file for my .NET MAUI (net9.0-ios) application, but every attempt fails with the same codesigning error. I have tried multiple approaches, including building from Windows paired to macOS, and directly building through the macOS terminal, but nothing is working.
Below are the exact steps I followed:
Steps I Performed
1.>Generated the Apple Development certificate using Keychain Access on macOS.
2.>Added that certificate into my developer account and created the corresponding provisioning profile.
3.>Created an App ID, attached the App ID to the provisioning profile, and downloaded it.
4.>Added the provisioning profile into Xcode.
Verified that the certificate is correctly visible in Keychain Access (private key available).
Attempted to build/publish the MAUI app to generate the .ipa file.
Issue
Whenever I run the publish command or build via Windows/macOS, codesigning fails with the following error:
/usr/bin/codesign exited with code 1:
Frameworks/libSkiaSharp.framework: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development: Created via API (8388XAA3RT)"
Frameworks/libSkiaSharp.framework: errSecInternalComponent
Failed to codesign 'PCS_EmpApp.app/Frameworks/libSkiaSharp.framework':
Warning: unable to build chain to self-signed root for signer "Apple Development: Created via API (8388XAA3RT)"
PCS_EmpApp.app: errSecInternalComponent
Build failed with 4 error(s) and 509 warning(s)
Environment
.NET: 9.0
MAUI: latest tools
Xcode: 26.0.1
macOS: 26.0.1
Building for ios-arm64 (device)
What I suspect
It looks like the signer certificate might not be trusted, or the certificate chain cannot connect to an Apple root CA. But the certificate was created using the Developer website and appears valid.
Need Help With
Why is codesign unable to build the certificate chain?
Do I need a different type of certificate? (App Store / Distribution vs Development?)
How can I successfully generate the .ipa file?
Any guidance will be greatly appreciated. Thank you!
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Hi everyone,
My app notarization has been stuck in the “In Progress” state for the past 4 days. Here are the details:
createdDate: 2025-10-12T07:56:46.228Z
id: 8f8c9a33-1c72-489e-a189-74c797a12fbc
name: DevScribe.zip
status: In Progress
I checked the Apple System Status
page and noticed that the Developer Notarization service has been showing an outage since October 8th.
Could this ongoing outage be the reason my notarization is stuck? Is anyone else experiencing the same issue?
Any guidance or workaround would be greatly appreciated.
Anyone know how long it takes to get Apple to respond to a request for provisioning for endpoint security?
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
Provisioning Profiles
Endpoint Security
我是一名开发人员。除了App Store,我们公司的官方网站也是软件下载的一种方式。DMG签名提交后,通过网站下载安装软件时,仍然有提示说来自身份不明的开发者。您能告诉我如何解决这个问题吗?如果你能用中文回复就最好了。
Topic:
Code Signing
SubTopic:
Notarization
Hi the best community! When I try to submit the app to Testflight I receive the following error:
"codesign command failed (/var/folders/j9/yh_rkh114rbgvmglf4gycj8w0000gn/T/XcodeDistPipeline.~~~OW0Dwk/Root/Payload/Application.app/Frameworks/Alamofire.framework: replacing existing signature
/var/folders/j9/yh_rkh114rbgvmglf4gycj8w0000gn/T/XcodeDistPipeline.~~~OW0Dwk/Root/Payload/Application.app/Frameworks/Alamofire.framework: invalid or corrupted code requirement(s)
Requirement syntax error(s):
line 1:155: unexpected token: NPH
)"
I have never stuck with this issue before.
Xcode Version 16.0
I assume that there is something related to code signing and our company name in App Store connect: Medical Institution “NPH” (The company name has been anonymized for privacy purposes.)
Appreciate any help.
Thank you!
Hello,
Unable to see the App Sandbox entitlement while creating a new App ID. Have tried to recreate APP ID multiple times. Don't see the option in Developer portal.
Hi, I have some doubts about certificates expiration given this "new" requirement around signing for some common third party SDKs:
https://developer.apple.com/support/third-party-SDK-requirements/
Use case:
I build an SDK that will be distributed as an XCFramework and will be used in AppStore apps from different people.
My SDK internally uses some other third party libraries that are integrated as binaries
Let's assume some of those third party libraries are from the list above and therefore seem to be required to be signed.
I distribute my SDK with all in order (third party SDKs from that list with valid signatures)
People using my SDK over the time provide an update to their apps on the AppStore but by then some of the third party libraries of my SDK has an expired certificate.
What would happen?
People using my SDK won't have any issues as far as my SDK has a valid signature (despite third party libraries from the list have expired signatures)
People using my SDK will get a warning about it but still will be able to submit to the AppStore. In that case, would AppStore Review process decline the update?
People using my SDK will get an error, not being able to submit to the AppStore and will require me an update version of the SDK with those third party libraries re-signed.
My understanding is that all would work as far as my SDK has a valid signature (after all is the one taking responsibility of the code inside), independently of what happens with the signature of those libraries themselves, am I correct?.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
App Store
Frameworks
App Review
Xcode
Hi Apple Developer Relations / Notary Service Team,
CRITICAL: All notarization submissions stuck "In Progress" since Feb 1, 2026 (5+ days). Blocking product release.
Latest (PRIORITY):
9bf1e3ca-33ed-4185-816c-2e06ff539f25
Stuck submissions:
a9f1abf6-04a1-462c-b7d1-91e834b44c1a
94a172f8-4aa6-475c-a7ec-fd83c8cfc49a
e2c033da-a1d0-480c-a3b5-5401a8dd3d03
eecefd87-8bf9-496c-86c8-c6f0d6a550e0
b1d27d30-7111-4cc7-9f0e-3f44aac43a97
Details: Team ID: JA8C8B5W34 App: 323MB DMG (codesign verified) notarytool log: "not available" (In Progress) Status page: Green
Requests:
Process 9bf1e3ca-33ed-4185-816c-2e06ff539f25
Queue status / ETA?
@Quinn or Notary team - production blocker!
Topic:
Code Signing
SubTopic:
Notarization
I'm experiencing an issue when exporting an Enterprise distribution certificate where the certificate and private key won't export together - the private key keeps getting left out.
I'm running macOS Tahoe. Has anyone encountered the same issue or know of a solution? Any help would be appreciated.
Topic:
Code Signing
SubTopic:
General