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"

Could someone help expedite our pending DriverKit USB distribution review request? Our driver works under development signing, but approval is blocking a TestFlight pilot for our accessibility product. Request: 8AR5R3NKZD Submitted October 18, 2026 (still "Submitted") Team: 7U9T57JPF7 Capability: DriverKit USB Transport – VendorID USB: VID 6790 (0x1A86), PID 29987 (0x7523) Support case: 103013236358 Thank you!

My macOS app notarized in 22-24 seconds on every release for months under my previous Developer ID team. I often shipped several releases a day, even with minor changes. Since moving to a new Developer ID team (FPRW433858) on Oct 25, every submission of the same app is held for hours: 85da38d3-1874-458a-9bb5-e4656c770037 (Oct 25 19:09 UTC): still In Progress when my CI job hit its 6-hour limit; accepted later. e4bf6e71-58dc-4710-abc0-ba0b459b099f (Oct 29 17:02 UTC): Accepted after 1h56m. Log: "issues": null, "Ready for distribution". Useless because GitHub CI crashed on it. 0c21d8be-cd60-45c0-b990-f7ebb616201a (Oct 29 19:02 UTC): In Progress, 1.5+ hours and counting. Same source, same build pipeline, same Sparkle framework, hardened runtime, inside-out signing. The only change is the team. The build is clean, and you have accepted it twice. I've read the "some uploads are held for in-depth analysis" answers. That is not an answer I can work with. A bugfix release now takes hours or fails outright on CI time limits (6h on github), for an app you have already accepted twice under the new Dev ID and countless times under the old Dev ID. I need concrete answers: Is team FPRW433858 flagged for in-depth analysis, and why? When does that end? After how many accepted submissions, or on what date? Is there anything I must do on my side? If so, what exactly? If nothing on my side causes this, please clear the team or escalate it to someone who can. I cannot accept to wait hours/days on app releases that are straightforward otherwise.

Hello Apple Developer Community, I'm running macOS 27.2 on Apple Silicon with Python 3.13.17 installed from the official python.org installer. I am investigating an inconsistency in macOS code-signing and trust verification. What I have observed: In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed. In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED. The Mac's date and time are configured automatically. The exact cause of the difference between execution contexts remains unknown. My questions: What could cause macOS trust evaluation to differ between execution contexts? Which read-only diagnostics could identify the cause? How can I investigate this without modifying Keychain trust settings, disabling system security or purchasing a paid developer membership? I can provide sanitized diagnostic logs if needed. Thank you for your help!

Hello, New to Apple's system and structure for certs and signing. I've been working with their team to get access for developers on my team to access the correct Certs and sign what they need to so we can push our latest builds out, since this is needed by our CI/CD pipeline. How can I give access to members of my team so they can do the code saying they need to and access the certs they need to? the certs are for dmg and pkg installers on macos.

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.

When attempting to access the (Certificates Identifiers & Profiles) page, I receive the message "Unable to find a team with the given Team ID to which you belong". Even while set as a developer or as an admin I still receive the same message above.

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.

I have requested two entitlements for my driver: "DriverKit USB Transport - VendorID" and "DriverKit UserClient Access" I have submitted them in Sep 20, and got no response or ETA on it. It's the only thing blocking the release of my driver. Request ID: C9ULM24X2U Team: F34U2UUGXX Status: Submitted What can I do to expedite this?

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.

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 would like to identify a supported, minimally scoped diagnostic method for a code-signature verification failure, without changing certificates, trust settings, or system protections. The command execution environment reported macOS 27.0.1, build 26A434. The following command was run against the standard system executable: /usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf It returned exit status 1 with: CSSMERR_TP_NOT_TRUSTED In architecture: arm64e.x1 The designated requirement displayed for the file was: identifier "com.apple.printf" and anchor apple The signature display reported Authority=(unavailable). Following TN3161, the CMS data was inspected structurally: it contained three certificate structures, whose recorded validity periods included the observation date. This was not a cryptographic or trust validation, and I do not treat the file as authenticated. My question is how to distinguish a certificate/trust rejection from inability to complete evaluation in the command's execution context. The documentation for SecStaticCodeCheckValidityWithErrors describes detailed errors, and kSecCodeInfoTrust describes access to the trust object used in code-signature evaluation. Is either a supported diagnostic route for this system executable and architecture? If so, please identify the required flags, prerequisites and minimum non-sensitive result fields. In particular, I do not want to change the strict or architecture coverage merely to obtain a passing result. No diagnostic using those APIs has been implemented or run. I am not asking to re-sign the system file, install certificates, reset trust settings, disable protections, or bypass validation. I would prefer an initial diagnostic that does not require private Keychain contents, broad system logs, or a full diagnostic archive. I understand that a diagnostic result or a successful information query would not by itself authorize execution or prove that the environment is safe.

Hello, We transferred an app from Team A to Team B. The app is live on the App Store, and every build currently in circulation was signed by Team A. Team B has not released any update — no App Store release and no TestFlight distribution — and the app may stay in that state for a considerable time. The distribution certificate and provisioning profile that Team A used to sign the build which is live right now will expire. We would like to confirm that this has no effect on sign-in and no effect on payments for the version that users already have installed from the App Store. Reasoning that applies to both The App Store re-signs the app as part of the distribution process, and the delivered build contains no embedded provisioning profile (TN3125), so neither Team A's certificate nor Team A's profile exists on the device. "Certificates overview" also states that an expired App Store distribution certificate does not affect existing App Store apps, and only prevents uploading new builds signed with it — which the transferor can no longer do in any case. Sign-in Login tokens live in the keychain under an access group whose name is prefixed with Team A's App ID Prefix. Our reading is that certificate and profile expiry has no bearing on keychain access at all, because the access check compares the group string in the binary's entitlements against the item's kSecAttrAccessGroup, and the signing certificate is not an input to that comparison. Is that correct? Payments Our reading is that payments are unaffected on both sides: StoreKit transactions — purchases, renewals, refunds — are handled by Apple's servers and do not depend on the app's signing certificate or provisioning profile; our server-side receipt validation relies on the app-specific shared secret, a 32-character hexadecimal string with no relationship to any certificate, so receipt validation keeps working. Is that correct, or does something break here? One consequence we would like confirmed If Team A ever needed to publish another build under its own account, we assume it would first have to issue a new, valid certificate and provisioning profile — that is, expiry does not affect the installed app, but it does affect Team A's ability to publish anything further. Is that right? Thanks!

Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that. There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test: – Installed through VPP on supervised devices running watchOS 26.1. – Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2. This strongly appears to be a VPP signing issue because we even did the following experiment: Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2. Verify that both apps launch successfully. Use an MDM command to install from VPP over the existing installations Verify that the watch app fails to launch (the iOS app is unaffected) My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.

It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

I’m developing an ARM64-native Wine + FEX compatibility runtime on Apple Silicon, without relying on Rosetta 2. According to the August 2026 Wine-devel discussion, the following entitlement is intended to be available to free developer accounts: com.apple.developer.cross-architecture-support-unmanaged However, I have encountered the following issues: My Xcode Personal Team does not offer a “Cross-architecture Compatibility Framework” capability. Certificates, Identifiers & Profiles is inaccessible to my free developer account. I cannot obtain a provisioning profile authorizing this entitlement. I contacted Apple Developer Support. They explained that entitlement requests generally require an Apple Developer Program Account Holder, but were unable to confirm whether this particular entitlement is currently requestable or where to request it. Could an Apple engineer clarify: Is the unmanaged entitlement currently available to free Personal Teams? What is the official App ID, provisioning profile, and code-signing procedure? Does this entitlement require additional approval from Apple? If it is unavailable, is there an officially supported alternative for development of an ARM64-native Wine loader? My goal is to use the native macOS cross-architecture features while keeping SIP and other security protections enabled. Relevant Wine-devel discussion: https://list\.winehq\.org/hyperkitty/list/wine\-devel%40list\.winehq\.org/thread/CKG5CEN2BE5VRXZ7O7NX4YUSBH3247WH/ Thank you.

Is the com.apple.developer.kernel.increased-memory-limit entitlement working as of iOS 15 Beta 3. As of right now if I try to add this entitlement on Beta 3 or below, the Automatic Signing fails. How much extra memory would be provided for an Application or its extension with this entitlement?

Dear Apple Developer Support Team, I am reaching out for assistance with two pending DriverKit entitlement requests. This is my first experience developing an application within Apple's ecosystem, and I recognize that my use case is somewhat unconventional. I may not have reached the appropriate support channel, so I would appreciate your guidance or assistance in directing this request to the correct team. We are currently evaluating the feasibility of adopting iPads for an internal enterprise application that communicates with our proprietary USB devices. These devices use the standard USB Communications Device Class (CDC), exposing a virtual serial port (UART). They work reliably on Windows, Linux, and macOS. To my surprise, I discovered that iPadOS does not provide general-purpose access to standard USB CDC serial devices. Based on my research, the recommended approach appears to be implementing a custom driver using DriverKit. We also use macOS as our primary development and debugging environment, so we would like to maintain a consistent DriverKit-based implementation across both platforms in macOS only for development. On September 30, 2026, I submitted the following entitlement requests: 1. Request GW966578ZB — DriverKit UserClient Access Requested entitlement: com.apple.developer.driverkit.userclient-access 2. Request 3HN2GMDFN5 — DriverKit / USB Transport Distribution Authorization Requested entitlements: com.apple.developer.driverkit com.apple.developer.driverkit.transport.usb Unfortunately, I have not received any response or status update on either request in the three weeks since submission. At this stage, our work is strictly a proof of concept (POC). We are not requesting public distribution or App Store publication. Our immediate objective is to validate the technical feasibility of communicating with our USB devices from iPadOS before committing to Apple's platform for our enterprise solution. The lack of progress on these requests has effectively blocked our evaluation for three weeks, making it difficult to assess whether iPadOS is a viable platform for our intended use case. Apple Developer Team ID: R4PSRJ28G7 We are genuinely interested in adopting Apple's technology for our enterprise operations, but we need to establish technical feasibility before proceeding. I would appreciate any guidance that could help us move forward. Best regards,Alon Bar-Lev

We ship an Endpoint Security system extension inside a host app. On one managed Mac (macOS 26.6.2, build 25G83, arm64) the extension can't be activated, while the same package works on other Macs with the same macOS build. WHAT WE SHIP AND HOW IT'S NOTARIZED Host app: ElasticEndpoint.app (co.elastic.endpoint), Developer ID signed, notarized, with the ticket stapled (codesign -dvv shows "Notarization Ticket=stapled"). System extension: ElasticEndpoint.app/Contents/Library/SystemExtensions/co.elastic.systemextension.systemextension (co.elastic.systemextension), same Team ID, Developer ID signed. It was part of the same notarization submission as the host app but has no ticket stapled to itself (stapler validate says "does not have a ticket stapled to it"). Delivery: a root-owned service extracts the app into /Applications with tar (so no quarantine attribute) and then runs "ElasticEndpoint --install" as root to request activation. Versions: first reported on 9.0.8, and the same on 9.5.1. 9.1.0 and 9.5.4 have the same layout. Public packages: https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.0.8-darwin-aarch64.tar.gz , with the app in data/elastic-agent-*/components/endpoint-security-resources.zip -> 64_Bit_Elastic_App_macOS.tgz. The 9.5.1 package is at the same URL pattern. SYMPTOMS ON THE AFFECTED MAC syspolicyd: [com.apple.syspolicy:default] Unable to parse ticket. syspolicyd: [com.apple.syspolicy:default] error registering ticket: -1 sysextd: Error checking with notarization daemon: 3 sysextd: bundle code signature is not valid - does not satisfy requirement: -67050 code failed to satisfy specified code requirement(s) sysextd: co.elastic.systemextension: extension failed to validate! uninstalling... "spctl -a -vv -t execute" prints "accepted / source=Developer ID", not "Notarized Developer ID", for our app and for an unrelated vendor's notarized app. Healthy Macs print "Notarized Developer ID". "syspolicy_check distribution" reports a notary error, and "codesign -R="notarized" --check-notarization" fails. RULED OUT The stapled ticket (Contents/CodeResources, 1716 bytes, SHA-256 e8679543f9934bd43b127210c10348f764b78a53360ec515ccbcb4afc0920e28) is byte-identical on the affected Mac, on a healthy Mac, and in the official 9.5.1 package. The network: TLS to api.apple-cloudkit.com and valid.apple.com works, there's no proxy, and the clock is correct (sntp offset 0.03 s). WHAT A HEALTHY MAC DOES (fresh macOS 26.6.2 VM, app without quarantine) Running the app's binary produces: "Extracting ticket from bundle" -> "Registering stapled ticket with system" -> CloudKit fetch -> "Inserting ticket". /var/db/SystemPolicyConfiguration/Tickets gains rows in the "tickets" and "hashes" tables, including the extension's cdhash. sysextd then validates the extension locally ("isNotarized = 1"), so the extension's notarization is established through the host app's ticket. If I truncate CodeResources on the VM, I get the same "Unable to parse ticket" / "-1" lines and then -67050. So on the affected Mac, ticket registration seems to fail even though the ticket file is intact. A third-party write-up describes the same signature on one Mac ("stapler validate" exit 65 for every vendor's app): https://github.com/fsnow/cst/blob/main/docs/implementation/NOTARIZATION_TICKET_ISSUE.md They report that none of these helped: resetting the Tickets database with SIP off, restarting syspolicyd/trustd, a fresh user account, or OS upgrades up to macOS 27.0.1. QUESTIONS What can make syspolicyd fail to parse or register a valid stapled ticket on a single Mac? Is there a supported way to repair ticket registration without erasing the Mac? Is it expected that sysextd validates nested code (the extension) only against the local ticket database, with no online fallback? What should we collect for you: a sysdiagnose, or a Feedback Assistant report? [FB number if filed]

Hi, This is our first-ever Developer ID notarization submission for our macOS application, Recto. The submission was created on: 2026-10-17T12:55:05.164Z Submission ID: d6f971e4-755c-494e-8f80-b2fa9e48b85e File: Recto.zip The submission has remained: status: In Progress for more than 3 days. Running: xcrun notarytool info d6f971e4-755c-494e-8f80-b2fa9e48b85e \ --keychain-profile "recto-notary" returns the submission successfully and shows In Progress. However, running: xcrun notarytool log d6f971e4-755c-494e-8f80-b2fa9e48b85e \ --keychain-profile "recto-notary" returns: Submission log is not yet available or submissionId does not exist Since notarytool info successfully finds the submission, the submission ID appears to be valid. This is our first notarization under this Developer ID account. Is this delay expected for a first notarization / in-depth analysis, or does the submission appear to be stuck? Should we continue waiting, or is there any action required from our side? Thanks.

Hi, Any idea about the timeline for approval? It's been sitting at submit for 8+ weeks. Email support will not help. Claiming no ETA and it's a separate team that reviews that. I've requested a few as initially had some mistake on submission. Here's one of it: Request ID: R7P34F4338 Team ID: H2SLQH5546 If this forum post can help escalate, that would be appreciated.