As part of an assignment, I have to develop an iOS app and hand it in, but with one catch. I have to hand in a physical device and it gets marked weeks after I hand it in. Whenever I simply run the app from Xcode, the app only lasts a week before preventing me from opening it and instead prompting me to delete it. I believe it's an issue where my free Apple Developer account can only sign apps for a week, is this correct? If so, is there any way to get around this without paying $200 for a paid developer account or an Apple Enterprise account (to use MDM to install the app) without breaching the terms of service? I know there's other ways of getting an app onto a phone than the App Store and TestFlight, such as a third party app store, but I believe these can also only install an app for a week before it expires. I've heard in the EU Apple has been forced to allow third party app stores, so is it possible to set my region to there and then use such a store? Will it last longer than a week? Any help greatly appreciated. Thanks!

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

Two Developer ID submissions for the same app have been stuck in In Progress with no resolution one for 20+ hours, a second for 2+ hours. Neither has ever transitioned to Accepted/Invalid, and notarytool log reports the log is not yet available for either. Apple's System Status shows Developer ID Notary Service as operational. Signing is verified correct (Developer ID Application, full chain, hardened runtime, secure timestamp details below), so I don't believe this is a client-side configuration issue. This is a newly enrolled account, Is this a known issue for new accounts, and is there a way to get these submissions looked at? Is there a known server-side backlog / in-depth-analysis hold affecting Developer ID notarization right now? Is it expected that a large, first-time app can sit in In Progress for 20+ hours with no log generated? Does submitting a second time (rather than waiting on the first) create an independent in-depth-analysis job and make things worse? Should I stop resubmitting and wait on the oldest one? Submission IDs and Team ID (982R8LP4Q7) above. Happy to provide more detail. Thanks.

Every notarytool submit from my team is rejected with: "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support…", "statusCode": 7000 This has persisted for 10+ days across many submissions (most recent job ID 00042820-f5d8-4c6b-a178-9b98d247170d, 2026-07-09). I distribute a macOS app outside the Mac App Store via Developer ID, so there is intentionally no App Store Connect app record. Everything on my side is verified correct: Apple Developer Program membership is active (Individual), team ID 5JDP238JFX. Valid Developer ID Application certificate; codesign --verify --strict passes with hardened runtime + secure timestamp; the signature chains cleanly to Apple Root CA. notarytool authenticates successfully — notarytool history returns my submission list — so credentials and team are correct; only notarization eligibility appears not to be enabled. I've signed in as Account Holder and see no pending agreements to accept. (← edit this line to match what you actually find — see note below.) My trader information was recently approved (received Apple's confirmation email). I've filed a Developer Program Support request but have had no response in over a week. The statusSummary reads like a team-level provisioning flag that hasn't been enabled. Ask: Can a DTS/forums engineer help get the notary service provisioned/enabled for team 5JDP238JFX, or point me to what account-side step is still outstanding? Happy to provide additional submission IDs or logs.

We have been using notarization for a long time without failure. Today, we are trying to do a release and we are getting this failure: 13:11:30 Conducting pre-submission checks for Dictionary-App-Builder-14.3-amd64.dmg and initiating connection to the Apple notary service... 13:11:31 Submission ID received 13:11:31 id: d7aeafcd-3ad8-459a-b46f-26eea6a50dff 13:13:32 Error: abortedUpload(resumeRequest: SotoS3.S3.ResumeMultipartUploadRequest(uploadRequest: SotoS3.S3.CreateMultipartUploadRequest(acl: nil, bucket: "notary-submissions-prod", bucketKeyEnabled: nil, cacheControl: nil, contentDisposition: nil, contentEncoding: nil, contentLanguage: nil, contentType: nil, 13:13:32 expectedBucketOwner: nil, _expires: SotoCore.OptionalCustomCoding<SotoCore.HTTPHeaderDateCoder>(value: nil), grantFullControl: nil, grantRead: nil, grantReadACP: nil, grantWriteACP: nil, key: "prod/AROARQRX7CZS3PRF6ZA5L:d7aeafcd-3ad8-459a-b46f-26eea6a50dff", metadata: nil, objectLockLegalHoldStatus: nil, objectLockMode: nil, _objectLockRetainUntilDate: SotoCore.OptionalCustomCoding<SotoCore.ISO8601DateCoder>(value: nil), requestPayer: nil, serverSideEncryption: nil, sSECustomerAlgorithm: nil, sSECustomerKey: nil, sSECustomerKeyMD5: nil, sSEKMSEncryptionContext: nil, sSEKMSKeyId: nil, storageClass: nil, tagging: nil, websiteRedirectLocation: nil), uploadId: "FpPG5uT2KfARISbYk2HKKB6iMm2dy5KeveNbOmIAoU0hCStokISxOS9.EG8.UXWLe.z8cC_X4kt2u0181.xJGA68EIkbSGq_jErYizapfmQNhTHmadbdSCgC8ErQL7jZcBdZGcGDYTgUbvUE3WYMzN.4AXgVGgUAxEV5idGoBBg.5t1.ZG.CHEFSvJJ3HH4G", completedParts: [SotoS3.S3.CompletedPart(eTag: Optional(""ac99c7fbb27adc503e084c6e06996576""), partNumber: Optional(1)), SotoS3.S3.CompletedPart(eTag: Optional(""97177a00dc53964afaa32172adb7de85""), partNumber: Optional(2))]), error: The operation couldn’t be completed. (Network.NWError error 54 - Connection reset by peer))

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

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).