You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

We have a complete iPadOS DriverKit USB extension for a Stripe Reader M2 (USB-C, M-series iPad). Development builds sign and run. We cannot ship Ad Hoc, App Store, or Enterprise builds because the distribution DriverKit entitlements are either not granted or not present in the provisioning profile Apple generates. Stripe’s iOS USB instructions say to request the entitlement at developer.apple.com/system-extensions: select HID and USB Transport, and enter USB vendor ID 11369. Platform is iPadOS. The extension also needs com.apple.developer.driverkit. The host app uses com.apple.developer.driverkit.communicates-with-drivers. We have two teams. The driver bundle ID is prefixed with the host app bundle ID and signed with the same team. Inc — Team ID HPL6Q4V5TF (Development, Ad Hoc, App Store) Host app Driver extension com.atxinnovation.union.development com.atxinnovation.union.development.usbDriver com.atxinnovation.union.qa com.atxinnovation.union.qa.usbDriver com.atxinnovation.union.production com.atxinnovation.union.production.usbDriver These are not granted. Latest submission is system-extensions request 39WL64S3LR (September 3, 2026). That form has no status page, and we have received no email. LLC — Team ID 3MAPQA4NZ6 (Enterprise in-house) Host app Driver extension com.atxinnovation.union.enterprise com.atxinnovation.union.enterprise.usbDriver Capability request ACL9VQ3BA4. The portal shows DriverKit and DriverKit USB Transport – VendorID granted and enabled on com.atxinnovation.union.enterprise.usbDriver. The Universal Distribution profile POS Prod USB Driver (platform iOS, active, expires 2027/01/22, UUID a3627c1e-451d-4d62-b871-1cb6fe21431e, created 2026-09-02 16:05:20 UTC) lists those capabilities as enabled on the Review Provisioning Profile page. The downloaded profile does not contain them. Decoding it yields only: application-identifier com.apple.developer.team-identifier get-task-allow keychain-access-groups The string driverkit does not appear in the profile. We regenerated it five times, including deleting and recreating the profile, with the same result. DriverKit development profiles for the corresponding development App ID do contain com.apple.developer.driverkit and com.apple.developer.driverkit.transport.usb. Xcode then fails the archive: Provisioning profile "POS Prod USB Driver" doesn't include the com.apple.developer.driverkit entitlement. We also do not know which idVendor values the VendorID grant assigned. The extension must match them exactly. We need 11369. What we already tried July 30: Account Holder submitted DriverKit and DriverKit USB Transport for both teams through the system-extension Contact Us form. No confirmation email. That form does not collect bundle IDs. Those July requests later showed up on the host App ID com.atxinnovation.union.enterprise, not on the usbDriver App IDs. August 12: Resubmitted on each usbDriver App ID under Certificates, Identifiers & Profiles → Capability Requests. Enterprise request ACL9VQ3BA4. August 27: Developer Support case 20000149322724. The reply pointed us back at the capability status page. September 2: Enterprise grant appeared. Enabling it on the App ID and regenerating the distribution profile still produced a profile with no DriverKit entitlements. Developer Support case 102951939894. No resolution. September 3: Resubmitted the Inc team via the system-extensions form (39WL64S3LR). The form would not accept another LLC submission because that App ID is already granted. No status since. What we are Requesting Grant DriverKit, HID, and USB Transport (vendor ID 11369) for iPadOS — Development, Ad Hoc, and App Store — on the three Inc driver App IDs above. Assistance debugging the issue of failing to embed the already-granted DriverKit entitlements in the LLC Enterprise distribution profile for com.atxinnovation.union.enterprise.usbDriver, and confirmation of the assigned idVendor values.

Hi, I am working on a personal HIDDriverKit project. The documentation suggests that you do not need the entitlements from Apple to do local development - that all you need to do is turn of SIP, enable developer mode, and turn signing to "Sign to Run Locally". However, I have followed all of these steps, and am still running into the error that to build, I need to have a provisioning profile with the DriverKit (development) feature (MacOS 15.2 Xcode 16.2). Am I missing something here regarding the steps for local development? Does one need to request a development version of the entitlements even for local development? Do I need a paid developer account to do this? Thank-you in advance.

Our app Newton Mail (App ID com.CloudMagic.Mail, App Store app 721677994, Team 53X8EK4BSQ) held the com.apple.developer.mail-client entitlement for years. Newton shipped as a default-mail-capable app starting with iOS 14, and our January 2024 App Store distribution profile (release_appstore_com.CloudMagic.Mail) still contains the entitlement. The grant is no longer active. Automatic signing now fails with: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. The Default Mail App capability does not appear on our App ID in Certificates, Identifiers & Profiles, nor in the Capability Requests tab. This looks like the same migration issue described in these threads: https://developer.apple.com/forums/thread/821303 (same error on a years-old grant, fixed server-side by Apple) https://developer.apple.com/forums/thread/806537 (grant only "partially migrated" to the managed capability) What we have tried since July 2026: July 9: emailed the entitlement team. No response. August 31 and September 5: submitted the Default Mail Client request form. No confirmation page or reference number either time. September 13: resubmitted the form and received Request ID L8JM288VBQ. Support case 102959495479: support confirmed we are not currently granted the entitlement. Our follow-ups on September 18 and September 23 got no reply. Phone case 102973381060: the callback was marked "no answer" 44 seconds after we requested it, and the phone never rang. The current App Store version (10.0.94) meets all four published requirements: mailto: is declared in Info.plist, the app sends to any recipient, the mailto handler opens a compose view with To: pre-filled, and the app receives from any sender. Could someone from DTS take a look, or tell us the right channel to get the migrated grant restored? Thank you.

xcrun notarytool submit crashes with a SIGBUS during upload, every time, for one specific build of our app. Filing this as its own post since it is a distinct, reproducible crash with a clear crash report, separate from general In Progress slowness. The exact exception, from the macOS crash reporter, is EXC_BAD_ACCESS (SIGBUS), subtype KERN_PROTECTION_FAILURE, with the message "Could not determine thread index for stack guard region." It happens on a background thread named nio.nioTransportServices.connectionchannel, which is the SwiftNIO Network.framework transport thread handling the upload connection. The faulting stack is inside notarytool's own code, going through String.init(format:), then Foundation's NSString formatting, then CoreFoundation's CFString formatting functions, almost certainly while it is trying to format a log or progress line during the upload. The same small set of return addresses repeats many times in a row right before the crash, which looks like unbounded or very deep recursion in that logging path. Reproduction: run xcrun notarytool submit yourbuild.zip --apple-id ... --password ... --team-id ... --wait against a roughly 180 MB zip of a signed .app. The tool prints Submission ID received, starts the S3 multipart upload, and crashes within about a second, before any upload progress is shown, with no error message. The submission is left behind on Apple's side, stuck at status In Progress, and disappears entirely about 11 to 12 hours later, at which point notarytool info for that id returns Submission does not exist or does not belong to your team. This is completely reproducible for us: it has now happened on five separate submissions of our x64 (Intel) build, and zero times submitting our arm64 (Apple Silicon) build of the exact same app, same machine, same credentials, same day. We also tried setting the upload timeout higher with defaults write com.apple.gke.notary.tool nt-upload-connection-timeout 300, which did not help, same crash. We have full macOS crash reports (.ips files) for two separate occurrences of this and are happy to attach or send them, along with the zip that triggers it.

App Store Connect rejects my iOS Flutter app with error 90035: “Code failed to satisfy specified code requirement(s).” The error affects the main app executable, App.framework, and Flutter.framework. Environment: macOS 26.5.2 Xcode 26.6 Flutter 3.44.8 Individual Apple Developer Program membership The Release archive and App Store IPA build successfully. The exported IPA is signed with an Apple Distribution certificate and contains the correct TeamIdentifier. However, verification reports: Runner.app: valid on disk Runner.app: does not satisfy its designated Requirement The certificate Common Name contains a non-ASCII character: “Ç”. The generated designated requirement appears to represent this character using a decomposed Unicode form. I suspect a Unicode-normalization mismatch between the certificate Common Name and the embedded designated requirement. I am also unable to create a local Apple Distribution certificate: Xcode Manage Certificates reports: “The data couldn’t be read because it isn’t in the correct format.” The Apple Developer certificate portal reports “An unexpected error occurred” after I upload a valid CSR. Has anyone encountered this issue when an Apple Distribution certificate Common Name contains a non-ASCII character? Is there a supported way to regenerate the cloud-managed certificate or have Apple repair the team’s certificate state? I can provide sanitized codesign output if an Apple engineer needs additional diagnostic information.

Hello, I’m seeing what appears to be a system-wide code-signing / trust issue on a MacBook Pro running macOS Tahoe 26.7 (25G229). I originally discovered the issue while preparing to build a local Swift command-line tool. However, the problem is not limited to my own code or to Xcode. Apple system apps fail strict code-signature verification as well. Environment: MacBook Pro, Apple Silicon macOS Tahoe 26.7 (25G229) Xcode 26.6 (17F113) /usr/bin/codesign /usr/sbin/spctl Observed behavior: Strict code-signature verification of Terminal.app fails with: CSSMERR_TP_NOT_TRUSTED Strict code-signature verification of TextEdit.app also fails with: CSSMERR_TP_NOT_TRUSTED Xcode 26.6 fails strict code-signature verification with the same error: CSSMERR_TP_NOT_TRUSTED A Gatekeeper assessment of Xcode fails with: internal error in Code Signing subsystem Reading trust settings for both the user and admin scopes fails with: SecTrustSettingsCopyCertificates: No keychain is available. You may need to restart your computer. /System/Library/Keychains/SystemRootCertificates.keychain exists, but read-only certificate queries through the security command did not return an accessible certificate record. The following services are registered and running: trustd securityd syspolicyd Troubleshooting already performed: Restarted the Mac: no change. Updated macOS from Tahoe 26.6.2 to Tahoe 26.7: no change. Repeated the checks after the 26.7 update: Terminal.app, TextEdit.app and Xcode still fail as described above. I have intentionally NOT performed any of the following: Resetting any keychain Deleting or importing certificates Changing trust settings Disabling Gatekeeper Disabling or changing SIP Re-signing Xcode or Apple system applications Erasing or reinstalling macOS Apple Developer Support reviewed my description but explained that their support channel is primarily for App Store Connect, app distribution, and Developer account management, and suggested posting the issue here. My main concern is that this does not appear to be an ordinary Developer ID or signing-certificate issue because Apple system applications such as Terminal.app and TextEdit.app also fail trust verification, while trust-settings queries report that no keychain is available. Questions: What additional read-only diagnostics would you recommend to determine why the macOS trust/keychain subsystem cannot establish trust even for Apple system applications? Is there an Apple-supported way to verify the integrity and accessibility of SystemRootCertificates.keychain and the system trust store without modifying or resetting the keychains? Does the combination of CSSMERR_TP_NOT_TRUSTED for Apple system apps and “No keychain is available” from SecTrustSettingsCopyCertificates indicate a known trust-store/keychain problem? Before considering a non-destructive macOS reinstall from Recovery, are there additional safe diagnostics I should perform? I would prefer not to reset keychains or manually modify certificates unless there is evidence that doing so is appropriate. I can provide the exact commands and full outputs from the read-only diagnostics if that would help. Thank you.

Notarization submissions stuck In Progress then disappear, x64 only Team ID CJLCWP5NP3, app Write (com.connerkennedy.write), Xcode Command Line Tools notarytool 1.1.3 (42), macOS 26.6.2 build 25G83. Every x64 (Intel) notarization submission for this app gets stuck at status In Progress and never resolves. After roughly 11 to 12 hours, the submission disappears entirely: notarytool info with that submission id starts returning "Submission does not exist or does not belong to your team," and the submission no longer appears in notarytool history at all, not as Accepted, Invalid, or Rejected, just gone. This has happened identically on three consecutive x64 submissions. The submission ids and creation times, in UTC, are: b532a8a4-1dab-4eab-b37c-81b53b3573bb, created 2026-09-20 20:25:48 3a1ea67f-f88d-43e6-9ef5-62a6de1aa5d2, created 2026-09-20 21:22:16 8bc19842-e93a-4ea7-b3cc-3c1aeb20b423, created 2026-09-21 11:28:53 All three followed the same pattern: stuck in progress, then vanished roughly 11 to 12 hours later. In sharp contrast, every arm64 (Apple Silicon) submission from the same team, same day, same build pipeline, succeeded normally, typically within a few minutes. Five separate arm64 submissions across September 8 through September 20 all came back Accepted with no issues. This is the first time this team has ever submitted an x64 build for notarization. Every prior successful submission was arm64. That is the only meaningful difference we can find between the submissions that succeed and the ones that get stuck. Before concluding this is server side, we ruled out several things on our end. It is not a local network or VPN issue, since we reproduced it with a VPN active, after fully disconnecting the VPN, and after a full machine reboot. It is not local resource pressure, since we reproduced it with over 18 GB of free RAM after a reboot, the same conditions under which arm64 succeeds instantly. It is not the specific file, since we reproduced it with a completely fresh rebuild of the app and also when submitting a dmg instead of a zip. It is not our build tooling, since we bypassed electron-builder's built in notarize step entirely and submitted directly with xcrun notarytool submit and info, with the same result. And it is not a one off blip, since it reproduced three times in a row over about 36 hours, always the same stuck then vanished pattern, with arm64 unaffected the whole time. We would appreciate help understanding why x64 submissions under this team are getting stuck and then disappearing after 11 to 12 hours, while arm64 submissions from the same team notarize normally. Either an explanation of what is happening so future x64 submissions process normally, or confirmation that this is a first time x64 review hold that needs manual clearing on Apple's side, would be very helpful. Happy to provide the actual zip we submitted, full notarytool logs, or anything else that would help investigate

I’m trying to distribute a macOS application outside the Mac App Store using Developer ID signing and notarization. The Sensitive Content Analysis capability is enabled for this App ID in Certificates, Identifiers & Profiles. My application requires the following entitlement: com.apple.developer.sensitivecontentanalysis.client However, when I create and download a new Developer ID provisioning profile for this App ID, the generated profile does not contain this entitlement. I have regenerated and downloaded the profile after confirming that Sensitive Content Analysis is enabled. I also decoded the newly generated .provisionprofile to inspect its entitlements. It contains the application identifier, team identifier, and keychain access groups, but does not contain com.apple.developer.sensitivecontentanalysis.client. As a result, Xcode will not export the Developer ID build because the application requests the Sensitive Content Analysis entitlement but the provisioning profile does not authorize it. Does anyone know the answers to these questions: Is com.apple.developer.sensitivecontentanalysis.client supported for macOS applications distributed outside the Mac App Store using Developer ID? If it is supported, why is the entitlement not being included in newly generated Developer ID provisioning profiles for this App ID? Is there an additional approval, agreement, or configuration required for this entitlement to be included in a Developer ID profile? Sensitive Content Analysis is a required feature of this application, so removing the entitlement is not an option for our distribution build.

I’m seeing a reproducible code-signing failure on macOS 26.6.2 with Xcode 26.6 while building an iOS XCTest bundle for a physical device. A newly created Apple Development identity is valid and can successfully sign and verify a standalone test binary using /usr/bin/codesign. However, xcodebuild build-for-testing reaches the first XCTest re-sign operation and the macOS Keychain authorization dialog for the same development private key becomes unresponsive after entering the login Keychain password and clicking “Always Allow.” The failing command is effectively: /usr/bin/codesign --force --sign -o runtime --timestamp=none ... libXCTestSwiftSupport.dylib and returns: errSecInternalComponent The exact same development certificate successfully signs a standalone binary immediately beforehand. The build is running from an ordinary logged-in Terminal session, not SSH or CI. After aborting the build, inspection showed the XCTest artifacts retained Apple’s original Software Signing certificate rather than the Development certificate, confirming the re-sign did not complete. I have already recreated the login Keychain once and recreated the Apple Development identity. I do not want to make further Keychain ACL/partition changes without understanding the underlying cause. Question: What diagnostic should I collect to determine why SecurityAgent/codesign cannot complete private-key authorization for the XCTest re-sign operation when direct signing with the same identity succeeds?

I have a narrow follow-up question about file-based Keychain partition lists, this time specifically for Developer ID Installer signing with productbuild. I’ve reviewed the existing guidance around Keychain ACLs and partition lists. For codesign, the security documentation explicitly calls out the apple: partition requirement. I haven’t been able to find an equivalent supported statement for productbuild. My setup uses separate private keys for the two roles: Developer ID Application → /usr/bin/codesign Developer ID Installer → /usr/bin/productbuild The trusted-application ACL is also role-specific. I’m trying to determine the corresponding partition constraint for the Installer key without inferring it from a configuration that merely happens to work. So my question is: When /usr/bin/productbuild uses a Developer ID Installer private key from a file-based Keychain, what partition-list requirement should that key use according to the supported macOS contract? In particular, should the Installer key use apple:, apple-tool:, some combination of partitions, or something else? I’m not looking for a broad CI workaround or an “Allow all applications” configuration. I’m trying to keep the Application and Installer roles separate and use only the partition constraint actually required by the Apple signing tool. If there is no documented/supported partition value for productbuild, knowing that limitation would also answer the question. Thanks.

I’m evaluating whether Apple cloud signing can replace locally managed Developer ID private keys in a macOS distribution pipeline. I’ve read the documentation on cloud-managed certificates and the Xcode cloud-signing workflow. I understand the supported Developer ID Application flow through Xcode’s archive/export distribution process, but I haven’t been able to find an equivalent documented workflow for Developer ID Installer. I’m also checking this against the current Xcode 27 / macOS 27 toolchain, in case the supported cloud-signing scope has recently expanded. My distribution pipeline produces custom flat installer packages using productbuild. It uses separate Developer ID Application and Developer ID Installer identities, as expected. So my main question is: Can a custom macOS .pkg be signed with a cloud-managed Developer ID Installer identity using a currently supported Apple workflow? More specifically, is there a supported cloud-signing equivalent of using a local Developer ID Installer identity with productbuild / productsign, or are Developer ID Installer package signatures still expected to use a locally or externally available signing identity? I’m specifically asking about custom Developer ID packages distributed outside the Mac App Store, rather than an App Store or Xcode-managed installer workflow. If cloud-managed Developer ID Installer signing isn’t currently supported, knowing that limitation would answer my question as well. Thanks.

Hi, My NEURL Filter configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was approved on August 5, 2026, but it turned out to be attached to the wrong Apple Developer Team — an old individual account (S5VDH23BBZ) I no longer have access to, instead of my actual organization team, KRKJ76BC7W (SCOTTO), which owns and signs the app (bundle ID com.dropbet.DropBet). I contacted Developer Support, who said they couldn't transfer it and suggested replying to the original approval email — I did (on 08/08, then several times) with no response. I then tried resubmitting the same configuration under the correct team (KRKJ76BC7W), but the portal rejected it with: "A configuration with the same PIR Server Domain already exists." So a fresh submission is technically impossible while the original stays attached to the wrong account — the only real fix is transferring or re-attaching the existing approved configuration to KRKJ76BC7W. Has anyone dealt with this kind of Team ID mix-up before, or know who on the Network Extension / NEURL Filter team could help reassign an approved configuration? Happy to provide any additional details. Thanks in advance.

I'm seeing a problem with custom Installer plugins on macOS 27 beta 5 and beta 6. I have a .pkg containing a custom Installer plugin. The plugin is properly signed, and if I check it manually from Terminal, codesign is happy with it and doesn't report any errors. However, when I install the package by double-clicking the .pkg in Finder, the plugin is not loaded. I see this in the logs: amfid: /private/tmp/com.apple.installer.../KLNagentInstallPlugin.bundle/Contents/MacOS/KLNagentInstallPlugin not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" So apparently the plugin fails signature validation after Installer extracts it into /private/tmp, even though the same plugin passes codesign validation. This package/plugin worked on earlier macOS versions. So far, I've reproduced the issue on macOS 27 beta 5 and beta 6. Has anyone else run into this? Did anything change in macOS 27 regarding signing or validation of custom Installer plugins? I've also filed this via Feedback Assistant - FB24415432.

Title: Notarization submissions stuck "In Progress" for 4 days (new Team ID) Every notarization submission from my team has been stuck "In Progress" since 11 September 2026. The first one went through; everything submitted after it has never reached a verdict. Team ID: T36RPB6Z2G Tool: xcrun notarytool (Xcode command line tools), app-specific password App: a Tauri desktop app, Developer ID distribution outside the Mac App Store Submissions (UTC): 2026-09-11 11:17:19 76bd3fd2-657c-4c3c-9c6b-6e7bc789fb4e In Progress (~92 h) 2026-09-11 11:18:30 1becd424-2ede-4044-b432-7f3afc646270 Accepted (minutes) 2026-09-11 14:39:38 3058ba57-d546-4e82-a781-02a1494eef71 In Progress 2026-09-12 07:24:20 b9568de2-6504-4d83-adc6-40e44f08ba44 In Progress 2026-09-12 09:29:07 572cff54-0e90-4e0d-9908-4ad82759dc9a In Progress (control test) What I have ruled out: Credentials and signing are fine — 1becd424 was accepted within minutes with the same certificate, the same password and the same tooling. It is not my app: as a control I signed a 14 KB Mach-O (a copy of /bin/echo) with the same Developer ID Application identity, hardened runtime and a secure timestamp, submitted it on its own, and it has been "In Progress" for ~70 hours as well. xcrun notarytool log <id> returns "Submission log is not yet available" for all four, so processing appears to have never started. codesign --verify --deep --strict passes on the app bundle; the certificate chains to the Developer ID G2 intermediate and shows as valid in Keychain. The Developer System Status page reports the Notary Service as operational. This looks like the documented behaviour where an upload is held for in-depth analysis and every later submission queues behind it — but four days with no movement, including on a 14 KB binary, seems beyond the usual delay. I have deliberately stopped submitting so as not to lengthen the queue. Could someone from Apple check whether 76bd3fd2 is being held, and release it? This is blocking the first signed release of the app.

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.

One of our notarization submissions has been In Progress since Sep 11 and hasn't moved. Submission ID: 5069b140-08dd-4113-bd13-6bc632b4200d Created: 2026-09-11T19:58:35Z Team ID: 9R8Q4GQCR8 notarytool info still shows In Progress, and notarytool log says the log isn't available yet. Our pipeline had five submissions Accepted on Sep 10 with the same certificates. We moved from an Individual to an Organization account on Sep 9, in case that matters. I haven't resubmitted the same binary. Could you check whether this one is held for deeper analysis, and whether it's holding up new submissions from our team?

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. xcrun notarytool info no longer shows any meaningful state for them. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress (~2.5h): CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict → "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers + ~180 PyInstaller backend binaries) signed inside-out. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck looks like an account-level backend issue, not a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.

Hello everyone, My Mac is Intell-powered macOS 15.7.7 (24G720) $ clang --version Apple clang version 17.0.0 (clang-1700.0.13.5) Target: x86_64-apple-darwin24.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin I am a long-lasting developper on MacOS. For a few days, and probably since I have upgraded to MacOS Sequoia, all my C (or C++, etc) programs, even the simplest ever, fail to launch, once compiled with Apple's command line tools : $ clang simplest_ever_c_program.c $ ./a.out Killed: 9 The program is killed by MacOS before it launches. This occurs no matter with terminal I use (Zsh, bash, sh...). Removing / reinstalling command line tools did not fix the issue. There is no information printed in the Console. For some reason while investigating, I have come at some point to suspect a codesigning issue. **Indeed, signing the code after compilation seems to fix the problem : ** $ clang simplest_ever_c_program.c $ codesign -s - a.out Hello World ! Gratz : this progam could be run from the Terminal ! My questions : Why does MacOS suddenly started to kill my own executables compiled with clang ? Would you know how to fix the issue ? (may be an obscure new setting in MacOS preferences ?) Thanks much for your attention and in advance, Nicolas

My Apple Developer Program team cannot complete Developer ID notarization. Team ID: 8786B65DT4 Both submissions initially uploaded successfully and returned “In Progress,” but later disappeared completely. notarytool info returns: “Submission does not exist or does not belong to your team.” And: xcrun notarytool history --keychain-profile BELLE_EPOQUE_NOTARY returns: “No submission history.” Affected submissions: 9d235d80-01d1-4db7-81ed-112fc8bc97d2 Submitted 2026-08-16T15:28:42.805Z bd49caa9-0f30-4f72-80e4-f1e72ee6f6c9 Submitted 2026-08-22T17:32:43.457Z The app is a universal Unity macOS app distributed outside the Mac App Store via Steam. It is signed with a valid Developer ID Application certificate, Hardened Runtime, and secure timestamp. ZIP integrity and all nested Mach-O signatures pass local verification. Can Apple DTS / the notary service team investigate why submissions for this team disappear rather than reaching Accepted or Invalid?