Two months ago we got approval for using the Notification Filtering entitlement. We rushed out to implement it in our app, only to find out that the permission was set for the wrong bundle identifier. We expected to get the permission for the notification extension's bundle identifier, yet it is added for the main app's bundle identifier. Per the official docs, the entitlement permission should be in the notification service extension target: After you receive permission to use the entitlement, add com.apple.developer.usernotifications.filtering to the entitlements file in the Notification Service Extension target. However, this fails to get signed when compiling for non-simulator targets because of the bundle mismatch issue. Simulator perfectly filters notifications. Adding the entitlement to the main app does compile, but filtering does not work (as expected). We reached out to Apple twice (Case-ID: 14330583) but we have yet to receive any response. Could there be something else wrong instead of the identifier mismatch?

Hi — multiple notarytool submissions from my account have been stuck "In Progress" for 60+ hours and never reach Accepted/Invalid. Apple's Developer System Status shows "Developer ID Notary Service" as operational, so this appears to be a backend/account processing stall rather than a public outage. This is blocking a product launch. Team ID: Q7FF775479 ("Developer ID Application: JUNSEN LIU", individual account). Submissions (all still In Progress): e9d00de6-074c-4818-a452-f765fa178a4e — 2026-06-19 06:07 UTC (current build) f02a0398-b6db-4ba0-8429-86a797bdc153 — 2026-06-18 23:21 UTC 8aa72d28-642a-466a-be85-181db125596b — 2026-06-18 04:40 UTC App: "Dollar Desktop Pet" 1.0.0 — a signed .dmg of a hardened-runtime, Developer ID-signed Universal (arm64 + x86_64) Electron app. Tooling: notarytool 1.1.2, Xcode 26.5, macOS 26.5. notarytool submit/history/info all work and list the submissions; status simply never completes, and notarytool log returns nothing. Could you please investigate why these aren't processing? I can provide the .dmg or any additional logs. Thank you.

Just started learning SWIFT. How come this code (in a separate file): // // indexLoader.swift // PhotoViewer // // Created by Bruce Quimby on 7/3/26. // import SwiftUI import SwiftData struct LoadIndex { let indexURL = "https://Some URL"; func getIndex() { print("The next step will be to get the index from this URL:" + indexURL); } } makes my build fail with: Cannot create a iOS App Development provisioning profile for "Just-Me.PhotoViewer.Retrieve-Index". Personal development teams, including "ME", do not support the Accessory Setup Extension capability.

This post is a ‘child’ of Resolving errSecInternalComponent errors during code signing. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Fixing an untrusted code-signing certificate If your code-signing identity is set up correctly, selecting its certificate in Keychain Access should display a green checkmark with the text “This certificate is valid”. If it does not, you need to fix that before trying to sign code. There are three common causes of an untrusted certificate: Expired Missing issuer Trust settings overrides IMPORTANT When investigating code signing problems, don’t use sudo to run commands as root. This is a common source of confusion. I explain why in Resolving errSecInternalComponent errors during code signing. Check for an expired certificate If your code-signing identity’s certificate has expired, Keychain Access shows a red cross with the text “… certificate is expired”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" error: The specified item could not be found in the keychain. If you use security to list your code-signing identities, it will show the CSSMERR_TP_CERT_EXPIRED status: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" (CSSMERR_TP_CERT_EXPIRED) 1 identities found Valid identities only 0 valid identities found The most likely cause of this problem is that… yep… your certificate has expired. To confirm that, select the certificate in Keychain Access and look at the Expires field. Or double click the certificate, expand the Details section, and look at the Not Valid Before and Not Valid After fields. If your code-signing identity’s certificate has expired, you’ll need to renew it. For information on how to do that, see Developer Account Help. If your certificate hasn’t expired, check that your Mac’s clock is set correctly. Check for a missing issuer In the X.509 public key infrastructure (PKI), every certificate has an issuer, who signed the certificate with their private key. These issuers form a chain of trust from the certificate to a trusted anchor. In most cases the trusted anchor is a root certificate, a certificate that’s self signed. Certificates between the leaf and the root are known as intermediate certificates, or intermediates for short. Your code-signing identity’s certificate is issued by Apple. The exact chain of trust depends on the type of certificate and the date that it was issued. For example, in 2022 Apple Development certificates are issued by the Apple Worldwide Developer Relations Certification Authority — G3 intermediate, which in turn was issued by the Apple Root CA certificate authority. If there’s a missing issuer in the chain of trust between your code-signing identity’s certificate and a trusted anchor, Keychain Access shows a red cross with the text “… certificate is not trusted”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Apple Development: …" MyTrue: errSecInternalComponent The message unable to build chain to self-signed root for signer is key. If you use security to list your identities, it will not show up in the Valid identities only list but there’s no explanation as to why: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 0 valid identities found IMPORTANT These symptoms can have multiple potential causes. The most common cause is a missing issuer, as discussed in this section. Another potential cause is a trust settings override, as discussed in the next section. There are steps you can take to investigate this further but, because this problem is most commonly caused by a missing intermediate, try taking a shortcut by assuming that’s the problem. If that fixes things, you’re all set. If not, you have at least ruled out this problem. Apple publishes its intermediates on the Apple PKI page. The simplest way to resolve this problem is to download all of the certificates in the Apple Intermediate Certificates list and use Keychain Access to add them to your keychain. Having extra intermediates installed is generally not a problem. If you want to apply a more targeted fix: In Keychain Access, find your code-signing identity’s certificate and double click it. If the Details section is collapsed, expand it. Look at the Issuer Name section. Note the value in the Common Name field and, if present, the Organizational Unit field. For example, for an Apple Development certificate that’s likely to be Apple Worldwide Developer Relations Certification Authority and G3, respectively. Go to the Apple PKI and download the corresponding intermediate. To continue the above example, the right intermediate is labelled Worldwide Developer Relations - G3. Use Keychain Access to add the intermediate to your keychain. Sometimes it’s not obvious which intermediate to choose in step 4. If you’re uncertain, download all the intermediates and preview each one using Quick Look in the Finder. Look in the Subject Name section for a certificate whose Common Name and Organizational Unit field matches the values from step 3. Finally, double check the chain of trust: In Keychain Access, select your code-signing identity’s certificate and choose Keychain Access > Certificate Assistant > Evaluate. In the resulting Certificate Assistant window, make sure that Generic (certificate chain validation only) is selected and click Continue. It might seem like selecting Code Signing here would make more sense. If you do that, however, things don’t work as you might expect. Specifically, in this case Certificate Assistant is smart enough to temporarily download a missing intermediate certificate in order to resolve the chain of trust, and that’ll prevent you from seeing any problems with your chain of trust. The resulting UI shows a list of certificates that form the chain of trust. The first item is your code-signing identity’s certificate and the last is an Apple root certificate. Double click the first item. Keychain Access presents the standard the certificate trust sheet, showing the chain of trust from the root to the leaf. You should expect to see three items in that list: An Apple root certificate An Apple intermediate Your code-signing identity’s certificate If so, that’s your chain of trust built correctly. Select each certificate in that list. The UI should show a green checkmark with the text “This certificate is valid”. If you see anything else, check your trust settings as described in the next section. Check for a trust settings override macOS allows you to customise trust settings. For example, you might tell the system to trust a particular certificate when verifying a signed email but not when connecting to a TLS server. The code-signing certificates issued by Apple are trusted by default. They don’t require you to customise any trust settings. Moreover, customising trust settings might cause problems. If code signing fails with the message unable to build chain to self-signed root for signer, first determine the chain of trust per the previous section then make sure that none of these certificates have customised trust settings. Specifically, for each certificate in the chain: Find the certificate in Keychain Access. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, move on to the next certificate. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Another way to explore trust settings is with the dump-trust-settings subcommand of the security tool. On a stock macOS system you should see this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. That is, there are no user or admin trust settings overrides. If you run these commands and see custom trust settings, investigate their origins. IMPORTANT If you’re working in a managed environment, you might see custom trust settings associated with that environment. For example, on my personal Mac I see this: % security dump-trust-settings -d Number of trusted certs = 1 Cert 2: QuinnNetCA Number of trust settings : 10 … because my home network infrastructure uses a custom certificate authority and I’ve configured my Mac to trust its root certificate (QuinnNetCA). Critically, this custom trust settings are nothing to do with code signing. If you dump trust settings and see an override you can’t explain, and specifically one related to code-signing certificate, use Keychain Access to remove it. Revision History 2026-07-02 Added a warning not to run tests using sudo. 2025-09-29 Added information about the dump-trust-settings command to Check for a trust settings override. Made other minor editorial changes. 2022-08-10 First posted.

One code signing issue I commonly see, both here on DevForums and in my Day Job™ with DTS, is that the codesign command fails with errSecInternalComponent. This issue crops up in a wide variety of circumstances and the correct fix depends on the specific problem. This post is my attempt to clarify the potential causes of this error and help folks resolve it. If you have any questions or comments about this, please start a new thread, tagging it with Code Signing so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving errSecInternalComponent errors during code signing In some circumstances the codesign command might fail with the error errSecInternalComponent. For example: % codesign -s "Apple Development" "MyTrue" MyTrue: errSecInternalComponent This typically affects folks who are signing code in a nonstandard environment, for example, when logged into a Mac via SSH or when signing code on a continuous integration (CI) server. This post explains how to resolve such issues, starting in the simplest case, signing from Terminal app, and then going on to discuss SSH and other contexts. IMPORTANT Before going further, make sure you understand the difference between a digital identity and a certificate. See TN3161 Inside Code Signing: Certificates for the details. Test from Terminal Code signing makes extensive use of the keychain, and that’s sensitive to the execution context in which it’s running. So, the first step in resolving this problem is to test your code signing from Terminal. To start, log in to the Mac using the GUI. Note If you don’t have access to the GUI, see Working without the GUI, below. Check that Keychain Access shows that your code signing identity’s certificate is trusted. Select the certificate and look for a green checkmark with the text “This certificate is valid”. If you see a red cross with an explanatory text like “… certificate is not trusted”, follow the instructions in Fixing an untrusted code signing certificate. Note macOS 15 moved Keychain Access out of the Utilities folder. The easiest way to find and launch Keychain Access is to use Spotlight. In Terminal, run the security tool to check that your code signing identity is available: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 valid identities found If the identity is missing from the Matching identities list, you don’t have a code signing identity to sign with. If you see your code signing identity’s certificate in the keychain, it’s possible that you’re missing its private key. See Certificate Signing Requests Explained for more about that issue. If the identity is shown in the Matching identities list but not in the Valid identities only list, see Fixing an untrusted code signing certificate. This example assumes that you’re testing with an Apple Development signing identity. If you’re using something else, you’ll see a different identity name in this list. Use that identity name in the codesign command below. Still in Terminal, make a copy of the true tool to use for this test: % cp "/usr/bin/true" "MyTrue" Try to sign it: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature The -f flag tells codesign to replace the existing signature. This command may display one or more keychain dialogs but, once you respond to those, it should correctly sign MyTrue. If it doesn’t, skip down to the Terminal failure section at the end of this post. Eliminate keychain alerts When you signed your code in the previous section, you may have seen one of two different types of keychain alerts: Keychain unlock dialog Access control list (ACL) dialog The keychain unlock dialog looks like this: codesign wants to use the … keychain. Please enter the keychain password. Password: [ ] [Cancel] [[OK]] The keychain containing your code signing identity is locked, and you must enter the keychain password to unlock it. You rarely see this dialog when logged in via the GUI because the system automatically unlocks the login keychain when you log in. However, the underlying cause of this alert will become relevant in the next section, when you log in via SSH. The ACL dialog looks like this: codesign wants to sign using key … in your keychain. To allow this, enter the … keychain password. Password: [ ] [Always Allow] [Deny] [[Allow]] The ACL for the your code signing identity’s private key prevents codesign from using the private key without your explicit approval. If you enter your password and click Allow, codesign can use the private key once. If you click Always Allow, the system adds codesign to the private key’s ACL so that it doesn’t have to ask again. To avoid this alert in the future, enter your keychain password and click Always Allow. Now repeat the codesign command from the previous section. It will sign the code without presenting any dialogs. Test over SSH Once you can sign your code in Terminal without seeing any dialogs, it’s time to repeat that process over SSH. To start, log out of the GUI and then log in via SSH. If you’re testing on a CI system, log in to that system by running ssh from Terminal on your Mac. If you want to test on your local Mac, choose one of these options If you have a second Mac, log in to that second Mac using the GUI, launch Terminal, and then run ssh to log in to your main Mac from there. If you have an iPad, use a third-party iPad SSH app to log in to your main Mac over SSH. Use a virtualisation app to run a macOS guest that you can treat like your CI system. Once you’re logged in over SSH, repeat the signing command from the earlier section: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature MyTrue: errSecInternalComponent This fails because: The system locked the keychain when you logged out of the GUI. Logging in via SSH does not unlock the keychain. When codesign tries to use your code signing identity, the system attempts to present the keychain unlock dialog. That fails because you’re logged in via SSH and thus don’t have access to the GUI. The system returns the errSecInternalComponent error to codesign, which reports it to you. To fix this, unlock your keychain using the security tool: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature IMPORTANT This assumes that your code signing identity is in your login keychain. If it’s in some other keychain, read the security man page to learn how to unlock a specific keychain. Best practice is to store both parts of your code signing identity (the certificate and the private key) in the same keychain. If you split the identity across two keychains, unlock the keychain that contains the private key. Test your CI job Once you have everything working on your CI system over SSH, try running exactly the same commands in your CI job. If your CI system manages user contexts correctly, those commands should just work. If they don’t, discuss this with your CI vendor. Note macOS has a complex execution context model. For background on this, see the Execution Contexts section of Technote 2083 Daemons and Agents. Some CI systems don’t correctly establish a user context when running jobs. For example, they might switch the traditional Unix execution context — the EUID, RUID, and so on — but not the security context. This mixed execution context causes problems for the keychain, which relies on the security context. Avoid doing code signing work as root. Some folks run everything as root because they think it’ll avoid problems. When working with the keychain the opposite is true: Running as root often causes more problems than it solves. These problems are most likely to show up when you use sudo, which creates a mixed execution context. Working without the GUI The instructions above assume you have access to the GUI so that you can test and resolve issues using GUI tools like Keychain Access. However, many CI systems don’t give you access to the GUI; at best you might have interactive access using SSH. Note If you CI system allows remote access using a screen sharing protocol, use that rather than messing around with the instructions here. If you don’t have access to the GUI of the machine on which you’re signing code, there are three issues to deal with: Avoiding the keychain unlock dialog Avoiding the ACL dialog Investigating an untrusted code signing certificate issue To unlock the keychain, use the unlock-keychain subcommand of the security tool, discussed in the Test over SSH section earlier. When logged in with the GUI, you can respond to ACL dialog by clicking Always Allow. This prevents that dialog showing up again. However, if you don’t have GUI access there’s no way to click that button. To get around this, import your signing identity and set its ACL to allow codesign to use it without extra authorisation. To do this, first unlock the keychain: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD Then use the security tool to import the PKCS#12 file: % security import IDENTITY.p12 -T /usr/bin/codesign -P P12_PASSWORD 1 identity imported. Note the -T option, which adds codesign to the private key’s ACL. Finally, modify the partition list to allow access by Apple code: % security set-key-partition-list -S "apple:" -l "Apple Development: …" This example assumes you’re using an Apple Development signing identity to test with. If you’re using something else, replace Apple Development: … with that identity name. Finally, investigating an untrusted code signing certificate issue remotely is quite challenging. Your best option here is to set up a local test environment, run your investigation in that environment, and then apply the results to your CI environment. There are two good choices for your local test environment: Use a virtualisation app to create a ‘clean’ macOS guest, one that’s never seen your code signing setup before. Use System Settings > Users & Groups to create a new local user account and do your testing there. The first option is best because you can easily restore your VM to a clean state between tests. When running through the process described in Fixing an untrusted code signing certificate, you might end up performing two different remedial actions: Importing an intermediate Reseting trust settings. Once you understand these remediations, you need to apply them to your CI system. The first one is easy: To import an intermediate, run security with the import subcommand: % security import INTERMEDIATE.cer 1 certificate imported. Resetting trust settings is more of a challenge. It’s probably possible to do this with the security tool but, honestly, if you think that your CI system has messed up trust settings it’s easiest to throw it away and start again from scratch. Terminal failure The bulk of this post assumes that the process described in the Test from Terminal section works. If it doesn’t, something weird is happening and you should apply the following diagnostic suggestions. The first is to create a new local user account on your Mac — using System Settings > Users & Groups — and then retry there. The goal of this test is to isolate: A problem that affects your Mac as a whole From a problem that’s tied to your user account If the problem is with your user account, switch back to your original account and run: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. In most cases this should report that no trust settings were found. If it report trust setting overrides, remove them. See Check for a trust settings override in Fixing an untrusted code signing certificate. If that doesn’t resolve the issue, something else is afoot and I recommend that you seek dedicated help per the start of this post. Revision History 2026-07-06 Fixed the breakage from last week’s update. 2026-07-02 Broke the post completely O-: 2024-10-05 Added the Terminal failure section. Made other minor editorial changes. 2022-08-12 Extended the unlock-keychain explanation to cover the split identity issue. 2022-08-11 First posted.

Hello Apple Developer Support, I need help with several macOS notarization submissions for my app "Dollar Desktop Pet" 1.0.0. Team ID: Q7FF775479 Developer ID: Developer ID Application: JUNSEN LIU (Q7FF775479) Bundle ID: com.dollar.desktoppet App type: Universal Electron macOS app, Developer ID signed, hardened runtime enabled Update as of 2026-07-05T21:23Z: The same keychain profile still works for a control/probe submission: 626063b7-643e-4b3d-aeb0-430532fa4ca9 Name: DollarNotaryProbe.zip Created: 2026-07-01T04:58:19.608Z Status: Accepted However, xcrun notarytool history --keychain-profile dollar-notary now only returns that probe submission. It no longer lists any Dollar Desktop Pet submissions. When queried directly, these Dollar submission IDs now return: "Submission does not exist or does not belong to your team." Affected submission IDs: 4e3c96b2-19fc-4b8b-844e-c95ca9242f11 Signed DMG submitted 2026-07-04T02:31:10.690Z 26f558b5-ea70-4196-8923-a77beb9fdc70 App-only ZIP submitted 2026-07-04T02:39:21.525Z f36faef2-14b8-4edb-b7e5-5db1bd3e1e17 Older DMG submitted 2026-06-26T22:28:21.305Z Local verification: The signed DMG verifies locally with Developer ID and timestamp. The app bundle verifies with: codesign --verify --deep --strict --verbose=4 The app is universal, hardened runtime, and uses Electron-standard entitlements. The local signed DMG still has no stapled ticket. Gatekeeper still rejects it only as: source=Unnotarized Developer ID origin=Developer ID Application: JUNSEN LIU (Q7FF775479) This is not an Accepted or Invalid result. It looks like the Dollar submissions either disappeared from the team view or are in a backend state that notarytool can no longer address, while the same profile can still read the accepted probe submission. Can Apple confirm what happened to these submission IDs, and whether I should wait, resubmit, or change packaging? Thank you.

Hello, I recently enrolled in the Apple Developer Program (Program License Agreement accepted 2026-07-03) and this is my first-ever notarization. All submissions have been stuck at status "In Progress" for over 48 hours and never reach Accepted or Invalid. "xcrun notarytool log" returns "Submission log is not yet available". I have verified everything on my side is correct: Signed with Developer ID Application (Team ID AXGBW2496Q) Hardened runtime enabled (flags=0x10000 runtime) Secure timestamp present codesign --verify --deep --strict passes ("satisfies its Designated Requirement") No get-task-allow entitlement notarytool credentials validate successfully All account agreements are accepted; none pending Could you please look into why these submissions are not completing? Team ID: AXGBW2496Q Submission IDs (all stuck In Progress): 3667a654-bd7e-40a9-927c-c919875aaf61 ffd1fcbf-ebf4-47cb-9a15-29731f973a86 98082a85-19d4-4efe-8119-36400dd1560c The app is a small (~360 KB) macOS utility. Thank you for any help.

Am on Mac Tahoe, and have the WWDR G4 cert in my login keychain, however, all the certificates am generating are coming out as not trusted. what else should I do? I have tried all the troubleshooting tips to delete all WWDRs if it exists. Any helpful suggestions will be appreciated.

Hi Apple Developer Support, My Developer ID notarization submissions are stuck in “In Progress” for over 24 hours with no terminal state. Team ID: KYM5Q9Y394 Stuck submissions: e3bedb66-3821-4737-8e9c-c1620e06ffea (2026-06-30T10:54:50.954Z) 5127868d-1953-4ab1-9be7-f26fc14804d9 (2026-06-30T10:45:54.870Z) 830069c1-037f-4bd8-a79a-0f445839603c (2026-06-30T10:38:54.060Z) All were uploaded via notarytool and remain “In Progress”. Codesign verification passes locally, and earlier submissions were accepted (e.g. 6e1617c3-b612-4fce-9165-286c71dce56d). Could you please check whether these submissions are stuck in backend processing and advise next steps? Thank you.

submission ID (e3bedb66-3821-4737-8e9c-c1620e06ffea) and createdDate (2026-06-30T10:54:50.954Z)

Hi — I'm trying to notarize a Developer ID–signed macOS app (a small menu-bar .dmg, ~1.4 MB) and every submission has been stuck at status: In Progress for 7+ hours without ever reaching Accepted or Invalid. The Developer System Status page shows the Notary Service as green/operational. This is a recently enrolled account (Individual) and these are its first notarization submissions, so I suspect a first-time-on-new-account hang, but wanted to get it looked at. Team ID: C4GLRN98Q7 Submission IDs (all still In Progress): a206d94b-c0e7-4901-a35e-daaf69c8ec65 — created 2026-06-25 19:02 UTC (oldest, ~7h+) 71d08fb3-0ae0-413a-8004-e3fb99721403 — 2026-06-25 19:32 UTC a6687302-d7b2-43be-8098-1442f0b1d4ab — 2026-06-25 19:45 UTC a8428002-0cd0-4d46-bc6d-8e95b9df409b — 2026-06-25 19:58 UTC cb8602bf-386e-4d98-9d1a-ad7e5308e629 — 2026-06-26 02:16 UTC (newest) What I'm doing: Signing with codesign --options runtime --timestamp using a Developer ID Application cert, then submitting the .dmg with xcrun notarytool submit … --keychain-profile … --wait. codesign --verify --strict passes locally. xcrun notarytool info returns valid submission metadata, just perpetually In Progress. The very first --wait died on a local network drop, but the submission had already uploaded 100% and kept processing server-side; I have not been spamming — the repeats above were a handful of retries before I realized they were all hanging. I've stopped submitting new ones. Could someone check why these submissions aren't completing? Happy to provide a notarytool log once any of them finishes. Thanks!

Hi. How can I change to an Individual Membership? Or when the time comes to notarize the app I will distribute from my website can I do that as an individual?

I'm trying to register the App ID ai.mycompany.app under our company Apple Developer account, but the portal says: "An App ID with Identifier 'ai.mycompany.app' is not available. Please enter a different string." We own the domain mycompany.ai, and no app is published with this identifier (an App Store lookup by bundle ID returns no results). I believe it was auto-registered earlier by Xcode's automatic signing under my personal Apple ID while testing a build, not under our company team. So it's now holding the identifier globally but isn't in use. I have access to both accounts — my free personal Apple ID and our paid company Developer account. The problem: under the free personal account, the Identifiers list (Certificates, IDs & Profiles) is restricted — free accounts can't access it on the portal, so I can't see or remove the Bundle ID there myself. And from the company account it doesn't appear, since it's owned by the personal team. What I want: release/remove this Bundle ID so I can register it under our company Developer account. Questions: If a Bundle ID was auto-created under a free personal team, how can it be removed when free accounts can't access the Identifiers list? Is contacting Developer Support the only way to release it in this case? Once released, does the identifier become available immediately, or is there a hold period before another team can register it? Any guidance appreciated.

I'm hitting what looks like the same service-side notarisation issue reported recently (e.g. the "submissions stuck In Progress for days" thread / FB22939442), and would appreciate having my submissions looked at on the backend. Since 2026-06-25 ~12:00 UTC, every notarytool submission from my team goes to "In Progress" and never reaches a terminal state — no Accepted, no Invalid, no log (Submission log is not yet available, though info resolves the ID fine). The oldest is ~15 hours. Signing checks out: codesign --verify --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, Developer ID Application. My builds notarised normally yesterday (e.g. 1ad9878b, Accepted 2026-06-24) — but those were on my previous Developer ID certificate. That cert's private key was lost (orphaned login keychain after a reboot), so I re-issued the Developer ID cert on 2026-06-25, and every submission on the new cert has been stuck since. Key data point: a trivial 5.8 KB signed "hello world" CLI binary (8c138308 below) also hangs "In Progress", so this is account/team-level, not app content. This lines up with the new-Developer-ID evaluation described in the Notarisation Resources Q&A, but several of mine are now past the usual window. Team: Creative Machines Limited (V95N2B8X7A) Feedback: FB23407538 Stuck submission UUIDs (oldest first): ef4af6d3-5750-4213-a108-584c75a861cc – 2026-06-25 ~11:59 UTC (oldest) 2d435abc-af77-4447-b2c8-94572b723f34 404a7d9d-9713-42df-99b6-1f144bc27ba1 8c138308-f23f-4df1-85f9-29095587f42b – the 5.8 KB hello-world This is the only blocker before I can distribute. Is there any way to get these specific IDs cross-referenced against the notary backend queue? Happy to share signed artifacts or the full notarytool poll log. Environment: macOS 26.4.1 (25E253), Xcode 26.5, notarytool 1.1.2 (41).

We are facing following message "A timestamp was expected but was not found" during codesign for following .dylib and .pkg and it cause notarization process failed. We are facing this issue for last 3 days and we have access for timestamp.apple.com and 17.0.0.0/8 and we didn't change firewall settings. We are facing this issue randomly and not for all time(scenario is 3:1). We tried the below command to sign the package, codesign --verbose --deep --force --timestamp --options=runtime --sign "<CODE SIGN IDENTITY>" <TO BE SIGNED PACAKGE> Kindly let us know how to fix this probelm.

Hi, I am trying to build an installer package of an usual(?) format: it contains a binary that I am developing code signing and notarization is straightforward here. it contains a 3rd-party binary that is open source, code signed and notarized by this third party code signing and notarization is also straightforward here as it's already been done. it also contains a 3rd-party binary that is also open source, however, it is not code signed or notarized This last one is the subject of my question. It is a well-established project with thousands of stars on GitHub, however their own "installation method" is a shell script that downloads the binary, checks its checksum and just places it in the right location. When building an installer package (it's an installer package of these three binaries packaged - productbuild with --distribution flag) this binary needs to be code signed and notarized for Developer ID distribution. I trust this binary, however the chance of supply chain attacks is never zero. My questions are: How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple? Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing. I really don't want to risk termination of my Apple Developer account because it has many high-value applications available. I am doing some basics - matching the intended checksum before packaging, signing with the hardened runtime entitlement - but I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation. Thanks in advance!

Hello, I submitted a .pkg installer for notarization on 2026-06-23 at 05:26 UTC, and more than 24 hours later the status is still In Progress. This is the first time I notarize this particular software — a small, lightweight Adobe Premiere Pro plugin — so I have no previous turnaround time to compare against. From what I understand, notarization usually completes within minutes to an hour, so a delay of this length feels abnormal and I'm not sure whether it's expected. Submission details Submission ID: 28b6be07-6bf0-4456-b6f1-6c2f7da27409 Submitted (UTC): 2026-06-23 05:26:37 Tool: xcrun notarytool (authenticated via a stored keychain profile) Package: .pkg installer for a small Premiere Pro plugin Status: In Progress (never moves past this state) The build was submitted successfully with no error and returned a valid submission ID. Running notarytool log does not yet return a log, since processing hasn't completed. Questions Is there currently a known notarization backlog or service delay on Apple's side? Can a first-time submission for a given product take noticeably longer than usual (e.g. an initial review)? What is a realistic maximum processing time before a submission should be considered stuck rather than simply slow? Should I wait, or cancel and resubmit? I'd rather not create duplicate submissions if it won't help. Thanks in advance for any guidance. Best regards, Robin

Subject: Developer ID Notarization submissions stuck in “In Progress” for over 24 hours Developer Team ID: R6KKTZV8SL Environment: macOS 26.2 (Build 25C56) notarytool version: 1.0.0 (38) I am unable to complete notarization of any submissions. Affected submission IDs: 53fb3f5e-45e1-4435-9b46-6420d3fc1c98 Created: 2026-06-22T17:17:47.385Z Status: In Progress 37e99554-376f-419f-8648-cf8ba39ea1ff Created: 2026-06-22T18:13:35.034Z Status: In Progress 0af4a2be-aa8d-4bed-ab0b-173bd1b62538 Created: 2026-06-23T02:29:35.134Z Status: In Progress To rule out issues with my application bundle, I also submitted a minimal test archive (test.zip). That submission is also stuck in “In Progress”. The issue affects every notarization submission I have attempted. Commands used: xcrun notarytool submit … xcrun notarytool history –keychain-profile breather-notary xcrun notarytool info –keychain-profile breather-notary The submissions appear in history and info and remain in “In Progress”. Additionally, attempting to retrieve logs returns: “Submission log is not yet available or submissionId does not exist” Could you please investigate whether there is an issue with notarization processing for my team/account or a backend service issue affecting these submissions?

First-time notarization stuck 'In Progress' ~12h and appears to be blocking my account's queue. Submission ID: dc257767-a693-4382-88db-8ecf82994a0b Team ID: 83B3GJVFAS

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 If your notary requests are stuck in the In Progress state, see my reply here. If your notary requests are failing with Team is not yet configured for notarization, see my reply here and also the follow-up here. 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"