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"

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.

I release my app both in the MAS and on my website. I use the same signing credentials, but necessarily different certs (Apple Development vs. Developer ID). When I run the MAS app and then run the other version, or vice versa, I need to re-authenticate the many privacy permissions each time (Finder AppleScript, Network browse, Full Disk Access), which is tedious and keeps causing trouble for other users because some of these require a tcc reset (which my app currently invokes manually, which I consider a hack, though). So, am I doing something wrong or is it really no possible to have both signed apps use the same identity with TCC?

An existing development-signed arm64 iPad Release build succeeds in Xcode, including its code-signing step. Post-build static verification from a restricted automation environment reports CSSMERR_TP_NOT_TRUSTED for Runner, App.framework, and Flutter.framework. The recorded commands were: codesign --verify --deep --strict --verbose=6 <app-path> codesign --display --entitlements - --xml <app-path> The entitlements command returns no XML and reports: binary contains an invalid entitlements blob; OS will ignore these entitlements This warning occurs only for Runner. The two frameworks have no entitlements slots. A public Security framework code-signing trust evaluation returned false, TrustResultValue 0, and an empty detailed result. The error and last underlying error were NSOSStatusErrorDomain / -26276, with description "OSStatus -26276". Existing observations: The Apple Development signing certificate matches the provisioning profile, which includes the target iPad. Keychain Access showed valid certificates using system-default trust. Offline code-page/resource hash and CMS signature checks matched. Offline parsing found matching XML/DER entitlement values within the profile's allowed values. These checks do not establish native trust or installation validity. The host is an Apple Silicon Mac and the target is a physical iPad. We have not isolated a focused Xcode sample that reproduces this issue. The original app contains Flutter and other integrations. We do not know whether the cause is in the artifact, trust evaluation, or the restricted execution environment. An OS log query was denied by that environment; it has not been retried or bypassed. We have not changed certificate trust, re-signed, rebuilt, or attempted installation to work around the verification failure. What supported, narrowly scoped diagnostic procedure would: distinguish a genuine trust-policy rejection from an evaluation that could not complete, diagnose the Runner-only entitlements warning, and establish whether the unchanged artifact is installable? Please advise the minimum redacted evidence or focused sample needed. We are seeking Apple's supported diagnostic route without exporting credentials or weakening trust settings. Attachments: none.

Since upgrading my free Apple Developer account to the paid Apple Developer Program (Individual) on September 21, 2026, every app signed with my paid team fails to install on my devices. TestFlight builds work. Error (Xcode Run, devicectl, Ad Hoc export): MIInstallerErrorDomain Code 13 / 0xe8008018 "The identity used to sign the executable is no longer valid." +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:] LibMISErrorNumber = -402620392 What I've established: A brand-new Hello World app with no capabilities fails the same way, so it is not my project, entitlements or widget. The same Hello World signed by a free Personal Team installs on the same iPad (after trusting the developer in Settings). So the device, OS, Xcode and Mac are fine. Fails on iPad Pro 13" M4 (iPadOS 27.0.1 and 27.2), iPhone Air (iOS 27.0.1) and iPhone 15 Pro Max (iOS 26.0.1), with Xcode 27.0, 27.1 and 27.2. Fails with Apple Development signing (Xcode Run) and with an Ad Hoc export signed with an Apple Distribution certificate. codesign verifies the app, the embedded profile contains the signing certificate and the device UDIDs, and the chain (WWDR G3 to Apple Root CA) is valid and not expired. Regenerated the Development and Distribution certificates, cleaned expired WWDR certificates from the keychain, removed profiles on the device, re-paired and toggled Developer Mode. No change. Only apps re-signed by Apple (TestFlight) install. This looks like stale signing state for the team on Apple's side after the free-to-paid conversion. I have an open request with Apple Developer Support (Case-ID 22506476) and Feedback Assistant report FB24912726, but have had no reply in two weeks. Has anyone seen 0xe8008018 on a team that was recently upgraded or converted, and is there anything I can do on my side beyond asking Apple to reset the team's signing identity?

Hello Apple Developer Support, We are seeking clarification regarding the impact of the upcoming certificate changes taking effect on February 1, 2027. Our organization has previously distributed macOS installer packages (.pkg) that were: • Signed using a Developer ID Installer certificate that chains to the Developer ID Certification Authority intermediate certificate expiring on February 1, 2027. • Successfully notarized by Apple. • Signed with a secure timestamp. We are specifically seeking clarification on the impact of the Developer ID Certification Authority intermediate CA expiration on packages that were signed, securely timestamped, and successfully notarized prior to the expiration date. We would like to understand how these existing packages will be treated after February 1, 2027. Questions Will installer packages (.pkg) that were already signed, timestamped, and notarized before February 1, 2027 continue to install successfully after that date? Does notarization combined with a secure timestamp allow these previously distributed packages to remain trusted and installable after the certificate changes take effect? Are software vendors required to re-sign and re-notarize installer packages that have already been distributed if they were signed using certificates affected by this change? If re-signing is required, does this apply to: • Only new packages created after February 1, 2027, or • Existing packages that were previously notarized and distributed? Are there any recommended validation steps to determine whether an existing notarized package will continue to install successfully after February 1, 2027? Business Impact We are evaluating whether previously released installer packages signed with Developer ID Installer certificates that chain to the expiring Developer ID Certification Authority intermediate CA will remain deployable for customers after February 1, 2027, and whether any re-signing or re-notarization effort is required for our existing catalog of notarized installers. Without clarification, we cannot determine whether archived installers will continue to function as expected or whether remediation work is required to preserve the installability of previously released software versions. Thank you for your guidance. We would appreciate any relevant documentation or recommendations regarding best practices for existing notarized installer packages.

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.

Unfortunately Radar has been down for several hours tpday, so I figured I'd post here to see if anyone else is having the same issue. All of our Notarization and Stapling for our non-App Store apps is done via Terminal. It's generally worked pretty well for the past 12 months. But for the last 6 days, Notarization has been fine, but Stapling results in a NSURLErrorDomain Code=-1005 error ("The network connection was lost.") about 50% of the time. Needless to say this is getting to be pretty frustrating. I haven't noticed any hiccups with my Internet connection. Using Xcode 26.3 on Sequoia 15.8.2, and again doing everything on the command line. Anyone else seeing the same thing? Here's the most recent Stapling failure from a few minutes ago: error is Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x6000007983f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x600002a84050 [0x20221bfa8]>{length = 16, capacity = 16, bytes = 0x100201bb11f8f13c0000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>" ), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4} CloudKit's response is inconsistent with expections: (null)

Hello everyone, I'm currently developing a macOS application called macOSDocker, which uses Apple's Virtualization.framework to run a lightweight Linux virtual machine hosting Docker containers. One of the main features is bridged networking using VZBridgedNetworkDeviceAttachment, allowing the virtual machine to obtain its own IP address on the local network and making Docker containers directly accessible without additional NAT or port forwarding. However, this requires the restricted com.apple.vm.networking entitlement. Application details: App: macOSDocker Bundle ID: com.macOSDocker Team ID: RYPSKH8HG5 Apple Developer Support Case: 102997773774 I've already contacted Apple Developer Support to request access to this entitlement, but they directed me to the Apple Developer Forums instead. Currently, Xcode reports that the com.apple.vm.networking entitlement is missing from my provisioning profile. My questions are: What is the official process for requesting approval for the restricted com.apple.vm.networking entitlement? Is there a specific form or contact within Apple Developer Relations for submitting such a request? I would appreciate any guidance, particularly from Apple engineers, on how to proceed with the entitlement approval process. Thank you! Kevin

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!

I am struggling with uploading my Mac-only app to TestFlight. I used to do this with Xcode 13.4.1 for a while without trouble, but now I have built the app with Xcode 27.1 and am getting issues such as ITMS-90885 and ITMS-90288 and I cannot figure out how to make it work. I have now at least realized that I seem to need to create a new provisioning profile because the one was using is missing some entitlement(s). To create a new profile, I need to create also a new certificate at https://developer.apple.com/account/resources/certificates/add But there's already my first hurdle: There are two types that allow upload the to MAS: "Apple Distribution" and "Mac App Distribution". Which one should I choose? I even googled for help but found nothing more than what the above website says. It's not clear what the difference is when I only want to submit to the MAS, and whether choosing the wrong one may already be part of the problem I'm having now with uploading my app. Can someone please explain in more detail if they're having exclusive behavior when using them to upload Mac apps to the MAS and TestFlight?

Hello, All of our notarization submissions except one are stuck in "In Progress" with no terminal state. I would appreciate it if someone could confirm whether they are still queued, or whether something on our side is blocking them. Team ID: 7MK3979GD2 Account: individual, newly enrolled; Developer ID Application certificate issued 2026-10-29 Tool: xcrun notarytool submit with an App Store Connect API key (Team Key, Admin role) Auth/upload work fine: notarytool info returns "In Progress"; notarytool log says the log is not yet available. Submissions (all times UTC): created submission id file status 1 2026-10-29T23:59:53Z 10b84260-955d-4ed5-a7ad-aa7484228427 GsGPT.zip In Progress 2 2026-10-30T01:24:44Z 2fa44ce1-345e-467b-8ea9-97362be6f45f GsGPT.app.zip Accepted (~2.5 min) 3 2026-10-30T01:28:09Z 097fee47-6fec-4645-b4af-f8250820dc8f GsGPT-mac-arm64-8.31.0.dmg In Progress 4 2026-10-30T09:21:25Z 9f4ec58b-d116-4e84-b859-9281ec0e5b92 GsGPT.app.zip In Progress 5 2026-10-30T11:05:58Z d0b9cebb-7795-4699-94b7-2c040fd06028 GsGPT.app.zip In Progress Notes: Submission #2 was accepted in about two and a half minutes, and its log reports "status": "Accepted", "issues": null. All submissions come from the same account, the same certificate and the same build job, so I believe the signed content is compliant. I have not resubmitted the same content. Later attempts are different artifacts from the same pipeline (app zip and DMG). App: GsGPT, an Electron-based macOS desktop app (bundle id cc.ekoaku.gsgpt, version 8.31.0, arm64), signed with Developer ID Application with hardened runtime, to be distributed outside the App Store as a notarized, stapled DMG. I understand that first notarizations from a new account may undergo additional screening. The oldest stuck submission has now been waiting over 13 hours, so I would just like to know whether these are still being processed or have been held. Could you please confirm the current state of Team 7MK3979GD2's submissions and let me know if anything on our side needs action? I am happy to provide any logs or additional details. Thank you very much for your time.

Hi Apple team, I have a recently created dev account and submitted two different 20-30 mb .apps for notary through the notary tool. I have read that this should only take minutes at this size of an app but both have been stuck in progress for almost 24+ hours. Below are the UUIDs of the notary submissions. Also I tried re-submitting but these are also stuck in progress. Successfully received submission history. history -------------------------------------------------- createdDate: 2025-09-26T11:46:32.643Z id: 9714758e-e216-496d-80f8-422f77011ebe name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T21:48:46.161Z id: c2a81300-c903-4277-8ef3-70205a690c76 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T18:24:36.205Z id: 42742be1-c7e5-4483-a2c5-95e89086d070 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T16:35:09.059Z id: a404256e-40c2-4dca-97fc-983e70ea4b7b name: <>.zip status: In Progress

We have developed a driver for our WiFi HaLow chipset, but are unable to progress beyond development because our entitlement request has stalled. We have received development entitlements, but these "require provisioning support" The original request was: Entitlement name: DriverKit, DriverKit USB Transport, and DriverKit Networking Business need: Distributing drivers for Morse Micro Wi-Fi HaLow Network Adapters Request date: 7 August 2026 Request ID: C7HYK62R73 When I followed up by email, I was asked to have the Account Holder (rather than a mere admin) reiterate the request to devprograms@apple.com, which I did. That was Follow-up number: 102965131843 The request from the Account Holder was on 21 September. When I followed up on 14 October, I was told to have the Account Holder follow up. None of the responses have asked for any additional information, nor have they offered any insight as to what may be blocking the request beyond the fact that I'm not the Account Holder. No responses have been sent to the Account Holder at all. What's blocking this? We're seeing increasing pressure from major accounts to support macOS, and are powerless to do so.

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

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!

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?