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"

When updating our Developer ID Application certificate, we encountered an issue where the Apple Developer portal consistently returns the exact same certificate file, regardless of the CSR submitted. Observed Behavior & Test Steps: We generated multiple new CSRs using both OpenSSL in the command line and Keychain Access (Certificate Assistant) on macOS following Apple's official guide: https://developer.apple.com/help/account/certificates/create-a-certificate-signing-request We uploaded these distinct CSRs to the Developer Portal (Certificates -> Add New -> Developer ID Application) on separate attempts. After downloading the issued .cer files, we performed a binary comparison (diff/checksum) across all of them. The comparison confirmed that the downloaded certificate files are 100% binary identical across all attempts. Key Pairing Verification: To further verify the key pairing, we checked the public key modulus hashes of the local Private Key and the downloaded .cer file via OpenSSL: Check local Private Key Modulus Hash: openssl rsa -noout -modulus -in new_developer_id.key | openssl md5 Check downloaded Certificate Modulus Hash: openssl x509 -noout -modulus -in developer_identity.cer -inform DER | openssl md5 The resulting MD5 hashes do not match. Attempting to export them to PKCS#12 (.p12) consistently fails with the error: no certificate matches private key. Question: Could this be related to a profile caching or binding issue on our team account, or is there a recommended way to clear this state and obtain a newly issued certificate? Any guidance or advice would be greatly appreciated.

Hi Apple Developer Support, The ARM64 build of our macOS app, has remained In Progress for over five days. The x64 build of the same release, submitted shortly afterward, has been accepted. Pending ARM64 submission: Submission ID: f2aa218e-680c-4497-a977-17b7f3d85ae1 Submitted: September 23, 2026, at 12:57:14 UTC Archive: signed-arm64.zip Status: In Progress Accepted x64 submission: Submission ID: bbae43b0-3846-46d0-a160-3b3af3aede9b Submitted: September 23, 2026, at 12:59:28 UTC Archive: signed-x64.zip Status: Accepted I checked both submissions again on today using xcrun notarytool info. For the ARM64 submission, notarytool log returns: Submission log is not yet available or submissionId does not exist However, notarytool info successfully finds that submission and still reports In Progress. Could someone please check whether this submission is still undergoing additional analysis, or whether there is an issue requiring action on our side? If another support channel is more appropriate after this length of time, please let us know. This is blocking our Apple Silicon release. We would appreciate any guidance.

Hello. I was trying to build a project on my Macbook via XCode and came across the message: "Communication with Apple failed. Your maximum App ID limit has been reached. You may create up to 10 App IDs every 7 days". Is there a solution to this? I don't know how much the prices are but I don't think I can afford it. What can you suggest to continue building projects with a free account?

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.

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.

Following up with a full diagnostic summary since my last post, in case it helps narrow this down. Certificates: Developer ID Installer and Developer ID Application (Team ID 6VCLSHAN7R), both freshly created Aug 19, 2026. Both show as valid/trusted in Keychain Access and match the developer portal (expiration 2031/08/20). What I've verified/tried, all pointing to the same conclusion: Local signature is valid. pkgutil --check-signature shows a full chain (Developer ID Installer → Developer ID Certification Authority → Apple Root CA) with a trusted timestamp. codesign -dvv on the embedded binaries (VST3, AU component, standalone app) all show Authority=Developer ID Application: ..., hardened runtime enabled, valid secure timestamp. No account/cert issues found. No duplicate certificates (security find-identity -v -p basic returns exactly 2 valid identities). No pending Program License Agreement. developer.apple.com/system-status shows Notary Service operational. Signed with productsign directly, not just via the packaging GUI (Packages/Whitebox) — same result. Isolated from product content: a minimal pkgbuild test package (single text file, signed only with productsign, no relation to my actual product) fails with the exact same error. Waited 3+ days in case of certificate propagation delay — no change. Tried both authentication methods — Apple ID + app-specific password, and a Team-scoped App Store Connect API key — both fail identically. Every single attempt returns: "message": "The binary is not signed with a valid Developer ID certificate." Latest Submission IDs (all Invalid, same error): 5b495af5-1a31-41cd-b8a3-d1e33ab2a12a (product pkg, API key auth) 91eee4f0-778a-4edb-9515-eabfc6711f3f (minimal test pkg, Apple ID auth) At this point I've ruled out everything on my end I can think of — package contents, signing tool, authentication method, certificate freshness/propagation, account status. This looks like something wrong with how these specific certificates are provisioned on Apple's side for notarization. Could someone from DTS take a look at the account/certificates directly? Happy to provide any further diagnostics needed. Thanks for your patience.

Hi all I'm stuck on a notarization failure that doesn't match any cause I can find or fix locally — looking for either a known explanation or a pointer to the right support channel. Setup: macOS 15.7.2 (24G325) Certificate: "Developer ID Installer" Issued: 16 Aug 2026, expires 17 Aug 2031 Confirmed on developer.apple.com as Active (not revoked) — matches the certificate installed locally by serial/expiry Signing a component .pkg containing a notarized-requirements-compliant plugin bundle (hardened runtime, secure timestamp, universal x86_64/arm64, signed with a valid "Developer ID Application" cert from the same team) What I've verified locally, all pass cleanly: pkgutil --check-signature on the .pkg: full valid chain, Developer ID Installer -> Developer ID Certification Authority -> Apple Root CA, with a trusted timestamp spctl -a -vvv -t install on the .pkg: recognizes it as "Developer ID" origin, correctly reports "Unnotarized Developer ID" (i.e. Gatekeeper trusts the signature itself, just knows it isn't notarized yet) codesign -dv --verbose=4 on the inner plugin bundle (both architecture slices checked individually): valid Developer ID Application signature, hardened runtime flag set, trusted timestamp present What I've tried, no change in any case: Originally built/signed via the third-party "Packages" app — failed notarization Re-signed the same .pkg independently with Apple's own productsign directly (bypassing Packages entirely, to rule out a third-party tool bug) — productsign's own console output explicitly confirmed it added both the "Developer ID Certification Authority" and "Apple Root CA" certificates to the signature — still failed notarization, identical error Found and accepted a pending Program License Agreement banner on developer.apple.com that I hadn't noticed before — resubmitted after accepting — still failed, identical error Rebuilt the plugin bundle from source fresh, repackaged, resubmitted — still failed, identical error Every attempt gets the same result from xcrun notarytool log <id>: "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "issues" "severity": "error", "path": "<the .pkg filename itself>", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": null Note "path" is the top-level .pkg itself and "architecture" is null — so this is flagging the Installer signature on the package, not the inner bundle's Application signature. Some submission IDs for reference, in case anyone from Apple can look at the notary service's own logs directly: 9a5364bf-7b0e-4cf8-a68c-0508bc081855 caa2a263-d4af-443b-89dd-1c26d93a7bee f15fcf6d-99c3-4810-8c42-926e4328a042 Has anyone seen this combination before — a certificate that verifies as fully valid by every local tool (pkgutil, spctl, codesign) and shows as Active on the portal, but is rejected by the live notary service specifically? Is there some other account-level state (beyond agreements, which I've now accepted) that can cause this? Trying to figure out whether this needs a Technical Support Incident or if it's a known/documented gotcha I'm missing. Thanks for any pointers.

Hi, I have a hard time renewing my certificates. The double click on the .cer file just opens the Keychain Acces but doesn't install anything. I'm missing a step. Thanks in advance for your help.

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