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"

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?

We maintain an existing iOS/tvOS App Store application that uses AVFoundation for authenticated streaming playback. One upstream provider supplies some account-entitled playback sessions as fragmented MP4 using ISO Common Encryption scheme cenc (AES-CTR). The provider controls the rendition, and no corresponding cbcs rendition is available to our client. We understand that Apple’s documented FairPlay Streaming path supports cbcs. We identified com.apple.coremedia.allow-mpeg4streaming as relevant to this playback case, but the entitlement is undocumented and does not appear under Capability Requests for our App ID. Apple Developer Support was unable to identify the request process and recommended posting this question in the forums and filing Feedback Assistant report FB24649355. Could an Apple engineer clarify: Is this entitlement available to third-party iOS/tvOS applications? If so, what is the official request process? We can provide additional technical information privately if an Apple engineer needs 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.

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 team, Earlier, Apple’s documentation clearly mentioned that we needed to submit a request to Apple to obtain the Location Push Service Extension (com.apple.developer.location.push) entitlement. However, when I checked the Apple Developer Portal now, I don’t see an option to request this entitlement for my App ID. Could you please confirm whether this entitlement is still required to be requested from Apple, or if the process has changed and the request is no longer required? 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.

When attempting to build an Apple Vision Pro application written in Swift in Xcode, we get the following status errors: "Provisioning profile [Profile Name] doesn't include the Main Camera Access capability.” and "Provisioning profile [Profile Name] doesn't include the com.apple.developer.arkit.main-camera-access.allow entitlement.” The provisioning profile we are attempting to use DOES have the Main Camera Access capability enabled through the Apple Developer portal. We have tried deleting and remaking the profile multiple times, as well as creating new profiles with the same settings, but completely different names and bundle identifiers, but keep getting the same errors. We DO have the "com.apple.developer.arkit.main-camera-access.allow” added to the entitlements file of the Xcode project, and we DO have the “NSMainCameraUsageDescription” key added to the info.plist file, along with the needed string describing the camera usage. Our organization has a valid and active Enterprise account, through which we have requested and been granted access to the “Main Camera Access” capability. We have built this applications multiple times before in the past year with no issues, these errors began after one of our provisioning profiles expired and we re-made it. We have tried clearing the Provisioning Profile Cache on our machine, clearing the Derived Data in the Xcode settings, and clearing the Xcode build cache. We are experiencing these errors on multiple machines, with different versions of our app, and with completely different apps that use the Main Camera Access entitlement. We experience these errors when the profile is downloaded directly in Xcode, and when it is downloaded from a browser and imported into Xcode. When we use “Automatically manage signing” our app properly builds and deploys to the Vision Pro, but when we use the app and attempt to access the main camera, the app crashes with the exception: "Exception: This app failed to request an authorization.” We have searched online forums and found several instances of others that have experienced this problem, but have not found a solution that works. Software Versions: Xcode Version: 26.6 macOS Version: Tahoe 26.5.1 VisionOS Version: 26.5

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.

Free Personal Team, hitting "Your development team has reached the maximum number of registered iPhone devices." I need a local build on a physical device for a demo, so I'm looking for the fastest supported path rather than a fix for the underlying behavior. Context: I hadn't used this Apple ID for development in about two years, so the usual "wait a week for registrations to expire" advice doesn't seem to apply here. The registrations appear to have persisted well past that window. Already tried: removing and re-adding the account in Xcode, clearing ~/Library/Developer/Xcode/UserData/Provisioning Profiles, deleting the developer profile from the device, and confirming this isn't the separate offloaded-apps issue that causes the "maximum number of apps for free development profiles" error. Free accounts have no Devices page, so there's nothing to clear manually. I'm aware of two options: enroll in the Developer Program, or create a new Apple ID and use it as a fresh Personal Team. I've also seen reports of people calling Apple Support and having devices dropped manually, with mixed results. Is the phone call route still viable for someone on a free account, or has that closed? And is there anything else I'm missing before I go the new-Apple-ID route?

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.

Hi everyone, For the past three days I've been unable to notarize my app — every attempt fails with an HTTP 500 error from Apple's notarization service. What's unusual is that the error occurs not only during submission, but also when simply validating credentials via store-credentials. Example: $ xcrun notarytool store-credentials "notarytool-password" \ --apple-id <id> --team-id <team> --password <app-specific-password> Validating your credentials... Error: HTTP status code: 500. Internal Server Error Request ID: K6NYCMIFNM66OI2WRG3ORZEDUE.0.0 Please try again at a later time. Since the failure happens at credential validation — before any package is even uploaded — I'm fairly confident this is a server-side issue, not something wrong with my setup or the binary. I've tried across different network connections, same result. Has anyone else been hitting this? Is there a known outage or incident on Apple's notarization infrastructure? Any way to escalate or get a status update beyond checking developer.apple.com/system-status/? Thanks

I have been trying to use Apple Developer Support to help with issues I'm having preventing me from signing and notarizing my apps. Delayed and not helpful responses from support. This has been going on for several weeks. I find it hard to believe that a Multi-Trillion Dollar company can't help me with my issues. I have what I think is a good certificate and private key as well as my App-Sepcific Password. The problem is that when trying to sign my apps, I get a popup indicating that that it's trying to sign in to Keychain using my first Name (Steve). My login on my system is "Stephen" which works fine for login and anything that wants to access Keychain. I need some help trying to resolve this.

I have two Apple Developer accounts under different Apple IDs: a free "Personal Team" account and a separate paid Organization account. Before my organization's Program enrollment was approved, I built an app to a physical device using Xcode signed into my personal account, which auto-registered an App ID under that personal team. Now that my organization account is active, I can't register the same App ID under the organization — both the web portal and Xcode's automatic signing return "not available," since it's already reserved under my personal team. Since personal (free) accounts have no web portal access, I can't see or manage that registration anywhere to release it myself. I own both accounts. Is there any self-service way to release an App ID from a personal team, or is contacting Apple Developer Support the only option? If support is required, is there a faster route than the standard contact form (I submitted a request several days ago with no reply yet)?

When trying to develop an Apple Shortcut, the shortcut doesn't appear (after many open, quit, adding permissions, etc.). My only Apple Account is my name associated with an Apple ID of QZ99..... However, when I try to check one (of many reasons) why it does not show up with Terminal: codesign -dv --verbose=4 "/Applications/My App.app" etc, it shows something "rejected" Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Aug 25, 2026 at 1:26:38 PM Info.plist entries=22 TeamIdentifier=QZ99... Runtime Version=26.5.0 Sealed Resources version=2 rules=13 files=4 Internal requirements count=1 size=204 /Applications/Write Create Date from Original.app: rejected origin=Apple Development: My Account (K533...) The K533... is different than my Team ID of QZ99... Could that be a reason my app is not registered with Shortcuts? Is that expected functionality? I guess I expected my Team ID to appear everywhere even after I deleted my account in Xcode, removed a current and expired certificate associated with K533 in Keychain, and then added my account back, and let Xcode regenerate a certificate.

Hi all, I've hit a wall trying to notarize a macOS installer pkg (built with Packages/Whitebox, signed with productsign). Every submission fails with: "message": "The binary is not signed with a valid Developer ID certificate." What's strange: this happens even on a minimal test pkg built with pkgbuild containing a single text file, signed only with productsign — no relation to my actual product. So it's not a content/nested-binary issue. Local verification passes fine: pkgutil --check-signature shows a full valid chain (Developer ID Installer → Developer ID Certification Authority → Apple Root CA) with a trusted timestamp. Both my Developer ID Installer and Developer ID Application certificates were freshly created on Aug 19, 2026, show as valid/trusted in Keychain Access, and match on developer.apple.com (Team ID 6VCLSHAN7R). What I've already tried: Re-created both certificates from scratch Waited 2 days in case of propagation delay Checked for pending program agreements (none) Checked developer.apple.com/system-status (Notary Service shows operational) Verified no duplicate/conflicting certificates in keychain Submitted a DTS support ticket 2 days ago, still waiting on a response. Has anyone run into this exact "valid everywhere except the notary service" situation? Any pointers appreciated. Example submission ID: 91eee4f0-778a-4edb-9515-eabfc6711f3f

I have requested an entitlement for my DriverKit based driver, but the status is still in "Submitted" phase. I have also tried contacting Apple Support by phone/mail but to no avail [Case ID: 20000143721904]. Below are the details of my request. Is there any way to know the turnaround time or to expedite the process as this entitlement is necessary for the distribution of our app? Also, what is the preferrable way to follow up in such cases? Entitlement: com.apple.developer.driverkit.transport.pci - DriverKit PCI (PrimaryMatch) Team: 8S33FS7Q5Q Request Id - NZYWRD96U3 Requested At - August 13, 2026 Type - Team Status - Submitted Thank you, Abishek.

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.

We completed an App Store app transfer and the Notification Service Extension Filtering Entitlement (com.apple.developer.usernotifications.filtering) did not transfer with the app. App Apple ID: 6760007376 NSE Bundle ID: io.nolink.ios.nse New Team ID: M85WA8W78C Previous Team ID: V2E3A94DC9 The app, bundle IDs, and App Store presence all moved normally, but the entitlement is not available on the new team, so we cannot sign the NSE with the configuration the app previously shipped with. Our app is an encrypted messenger and this breaks incoming call handling for live users. Two questions: Is there an official process for re-associating a previously approved entitlement with the receiving team after a transfer, or does the new team always have to submit a fresh request? Could entitlements tied to a specific App ID move with the app during a transfer, the same way bundle IDs do? We have an open support case, but wanted to raise the general question here too.

I use a free Apple Personal Team with Xcode for on-device testing. My Apple Development certificate created on 15 August 2026 shows “Missing Private Key”, and Xcode is not allowing me to create a fresh replacement certificate. I have already contacted Apple Developer Program Support, and they directed me to the Apple Developer Forums for technical assistance. How can I revoke/reset the unusable certificate or clear the certificate state for my Personal Team so that Xcode can create a new Apple Development certificate?

Hi, I'm reporting three notarization submissions that have all been stuck in the "In Progress" state today. I'm posting mainly to ask whether my team has been pulled into in-depth analysis, since as far as I know there is currently no way to determine that from the client side. Team ID: SE3B3RM5Y4 === Stuck submissions (all still "In Progress" as of 2026-08-17 12:15Z) === 99722c12-dc10-4098-88be-84b7b58ff1f4 created 2026-08-17T07:51:19Z a41cf8fe-8883-4073-a043-5143323407da created 2026-08-17T09:45:11Z 35746a17-d332-4398-a353-cd7b1d8520ac created 2026-08-17T11:34:55Z notarytool info returns status "In Progress" with no message field for all three. No errors, no rejections - they simply have not moved. === Immediately prior submission, same pipeline, succeeded === a9138c72-41ee-4b42-adcf-78851eb3e5c7 created 2026-08-12T10:58:00Z Accepted That submission was Accepted in roughly 25 minutes. Every submission before it (2026-08-09 x2, 08-06, 07-26, 07-21, 07-15, 07-09) was also Accepted within a similar window. Today's three are the first that have not completed. === Why I believe this is team-scoped rather than a bad package === The three submissions are not retries of one another: 99722c12 and a41cf8fe are the same app version (1.3.1). 35746a17 is a different build of a different app version (1.3.2), produced from a newer source tree, with different content and a different zip. It was submitted almost 4 hours after the first one and was stuck immediately as well. So a fresh, independently produced package entered the same stuck state right away. That seems more consistent with a team-level hold than with a problem in any individual package. I understand from previous threads that once a team enters in-depth analysis, it affects all notarizations for that team until the state clears, which appears to match what I'm seeing. === What changed between the last successful submission and today === I want to disclose this in case it is relevant to the analysis: Package size grew from ~635 MB to ~751 MB (+116 MB, +18%) for the signed .zip. This is one of the larger single-release size increases in this app's history. A bundled third-party command-line helper was updated to a much newer release. It ships its own separately Developer ID-signed Mach-O executable, so while the file path and its signing identity are unchanged from previous releases, the actual binary content is almost certainly different from what was notarized on 2026-08-12. The app's own main executable is rebuilt every release, so its content always differs between releases. That has never caused a delay before. No new kinds of executables, dylibs, or runtimes were added to the bundle. I verified this by diffing the packaging scripts and the bundle tree: there are no newly introduced binary types, and no new entitlements. The Hardened Runtime entitlements are byte-for-byte identical to the 2026-08-12 build. === What I've already checked === Signing identity is a valid, unexpired Developer ID Application certificate. codesign -vvv --deep --strict passes on the app before submission. Hardened Runtime is enabled; entitlements unchanged from the accepted build. The Developer ID Notary Service shows as operational on the system status page. I am nowhere near the documented submission rate limits (3 submissions today). App-specific password and credentials are valid - notarytool history authenticates and returns results normally. === Environment === macOS host: Apple silicon Xcode command line tools, xcrun notarytool submit --wait Electron-based application, packaged with electron-builder Signed zip: ~751 MB === My questions === Is there any way to confirm from my side whether these submissions have been routed into in-depth analysis? I understand this is a known and frequently requested feature, but I want to make sure I'm not missing an existing diagnostic. Given that these are only a few hours old, I understand this is well below the threshold at which it makes sense to investigate individual submissions. I'm happy to wait. I'd just like to confirm whether waiting is in fact the correct action here, or whether there's anything in the changes described above that I should address on my end before resubmitting. Is submitting an additional build while earlier submissions are still pending harmful in any way? I've read that it's acceptable, but I want to confirm I'm not making the queue situation worse for my own team. I will update this thread when the state resolves, including how long it took, so there's a data point on the record. Thanks very much for your time.