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

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

Hello. I am developing our company's SDK for iOS as a third-party library. This SDK consists of a static library and header files wrapped within a framework (and wrapping the target-specific frameworks in xcframework). I understand that codesign is required even for static frameworks, is it correct? Should I update the distributed files when the certificate expires? Does this depend on whether it is static or dynamic? When is the signature verified?

Issue: Multiple notarization submissions have remained "In Progress" for several days. Last successful submission: eb3d534a-cd69-4589-916b-8305c63429c2 Accepted on 2026-06-01 Affected submissions: 54123d59-6fcf-4358-b14c-fb2cbd1a6f84 5787259c-cad8-409a-9ca9-ead7cdcbfdd0 d069aeed-bc0c-46f9-ac83-facb00769d66 d2d483ad-55af-465b-aa5b-81e010eaf6fc 1575fc69-3ab8-47bb-a589-f8e6715068ab 7bee3edc-764b-422f-8722-727b51e46355 All submissions remain "In Progress". codesign verification passes successfully. Please investigate whether these submissions are stuck in the notarization service queue.

Support Case 102905607758 — no response after 9+ days. Profile: atlas-mac-notary All stuck "In Progress", notarytool log unavailable: 2026-05-31T08:02:14Z | 6a8ba9e3-60a9-476b-a12e-d27866be0559 | atlas-mac-10.6.38-100640-signed.dmg 2026-05-31T09:57:12Z | 51af581f-3bce-4603-abd6-77a27d332bac | atlas-mac-10.6.38-100640-signed.dmg 2026-05-31T17:19:29Z | 0163ccf4-4475-4161-b9fc-c50fb1df6d75 | atlas-mac-10.6.38-100664-signed.dmg 2026-05-31T18:01:08Z | 0c40ff22-6391-45e9-bd7d-0507f1e11147 | atlas-mac-10.6.38-100665.dmg 2026-06-06T07:33:51Z | fb464637-e8a4-4222-8963-e8e2bf230243 | atlas-mac-10.6.39-100668-submit.dmg 2026-06-07T07:48:16Z | 0a3b3e5b-02a1-4ee4-8456-6071723c131a | atlas-mac-10.6.39-100669.dmg One earlier submission processed: ebb768e3-3200-4933-86c7-5e3402c85ff5 → Invalid (atlas-core signing, fixed in later builds). We stopped all new submits. Please check backend queue state and advise how to clear stale entries. Thank you.

Hi, I'm a new Apple Developer Program enrollee (1 week in) shipping a Mac app via Developer ID + notarytool. Hardened runtime enabled, properly timestamped, all embedded Mach-O signed inside-out. 10 submissions are stuck "In Progress" - the oldest from 2026-06-07 (60+ hours ago). One Invalid verdict came back on 2026-06-08 for a real signing issue (unsigned PyQt5 framework binaries) which I've since fixed; the 10 newer submissions should pass cleanly. Apple's system status page has shown Developer ID Notary Service as green ("Operational") this entire time. This appears to be a queue issue specific to my account, not a service-wide outage. xcrun notarytool history: createdDate: 2026-06-09T16:26:37Z id: 4c928b64... status: In Progress (17h) createdDate: 2026-06-09T16:25:26Z id: 74e9feed... status: In Progress (17h) createdDate: 2026-06-08T21:13:31Z id: 8b246574... status: In Progress (37h) createdDate: 2026-06-08T20:59:37Z id: 4a529617... status: In Progress (37h) createdDate: 2026-06-08T18:49:33Z id: ff43d591... status: In Progress (39h) createdDate: 2026-06-08T18:46:27Z id: 60579d8d... status: In Progress (39h) createdDate: 2026-06-08T18:36:02Z id: a82fd14b... status: In Progress (39h) createdDate: 2026-06-08T18:22:45Z id: 4514a5cb... status: In Progress (39h) createdDate: 2026-06-07T21:20:09Z id: 700c8413... status: In Progress (60h) createdDate: 2026-06-07T20:18:08Z id: 2ea83c6c... status: In Progress (60h) xcrun notarytool info on each returns "status: In Progress" with no processedDate set. I understand new submitters can get held for extended in-depth analysis on first submissions, but 60+ hours is past any documented expectation for that. Could a DTS engineer please look at the backend logs and either release the queue or tell me what's specifically blocking these submissions? Thanks!

Hi, I'm trying to archive my xcode project. There is a build error. Warning: unable to build chain to self-signed root for signer "Apple Development: JOHN WILLIAM BAKER (VCZ7S72JNR)"

This is the first notarisation activity on a newly enrolled Developer Program account. Every submission has been stuck "In Progress" with no terminal status and no log available. Oldest stuck request: UUID: bfb5a0e3-31a2-4dcd-a1c6-2f26ce6e62dd Created: 2026-05-29T13:43:22Z Team ID: ZH3S4VZT33 It has now been more than 7 days. I understand first-time submissions can be held for in-depth analysis, which is why I waited a full week before posting. Evidence this is account/team-level rather than specific to one app: A second submission the same day (e42fb5f4-8fc7-4eec-9eef-9764e756b444) and a separate throwaway probe app submitted 2026-06-01 (0333a989-3a9f-44b1-98e6-69f9ee4028e4) are all stuck "In Progress" too. xcrun notarytool log <id> returns "Submission log is not yet available" for all of them. No rejection email at the Apple ID address. Apple System Status shows Developer ID Notary Service as Available. Could someone from the notary service team check the queue for Team ID ZH3S4VZT33 and advise whether these are in the in-depth-analysis path? Happy to provide codesign output or additional UUIDs.

Hello Team, We are currently implementing a digital membership solution across our gym facilities, allowing members to add their access cards to Apple Wallet. In this regard, we would like to request enablement of NFC capability for Wallet passes associated with our Apple Developer account. Our setup includes NFC-enabled access control hardware integrated with our gym management system, and NFC support is required to issue and utilize digital membership cards. At present, we only have a standard Pass Type ID Certificate in our developer account. However, we understand that NFC-enabled Wallet passes require a Pass Type ID Certificate with NFC capability. We would appreciate your guidance on how we can enable or obtain a Pass Type ID Certificate with NFC support in our Apple Developer account. Looking forward to your support.

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.

Seeing my notarizations getting stuck. This is becoming a blocker for releasing. What's strange is that earlier versions of the same app (very similar) passed notarization very quickly. Any advice or recourse?

My app includes the main program, Finder extension, and launcher helper. Which identifier should I choose when generating a provisioning profile?

Hi, I have Identifiers that's used maybe in old Xcode projects long time ago that never been uploaded for Apple to approve and yet when trying to remove I get an error message below, any suggested fixes ? " The App ID 'xyz.xyz.xyz' appears to be in use by the App Store, so it can not be removed at this time. "

On the Certificates, Identifiers and Profiles section of the Account section of developer.apple.com, if you manually configure the Capabilities of an App Identifier, there are icons with no tooltips. Does anyone know what they mean? (I'm particularly interested in the two different icons shown in my screenshot, with the same name)

I am experiencing an issue where multiple notarization submissions remain in “In Progress” status for an unusually long time. Some submissions are approaching one week without any result. Current affected submissions: ID: 381ea19f-ed44-411b-a283-1dab2845538c File: test-signed.pkg Submitted: 2026-06-04 07:03 UTC Stuck for approximately 65 hours ID: 3ba2198a-fd72-4936-a197-c54d13ed728d Submitted: 2026-06-01 11:52 UTC Stuck for approximately 132 hours ID: bca23b30-e944-442b-8fde-041dd4f22d7b Submitted: 2026-05-31 15:14 UTC Stuck for approximately 177 hours ID: 5f923382-393a-485c-8eec-64bafac1be65 Submitted: 2026-05-31 15:07 UTC Stuck for approximately 177 hours The issue affects both production packages and simple test-signed packages. All submissions remain in the “In Progress” state and never move forward.

I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated. Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours. Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions. This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case. Is this a known issue for new accounts, and is there a way to get these submissions looked at? Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

import AVFoundation var player: AVAudioPlayer? func playBackgroundAudio() { do { try AVAudioSession.sharedInstance().setCategory(.playback, mode: .default) try AVAudioSession.sharedInstance().setActive(true) } catch { print("Audio session setup failed: (error)") } if let url = Bundle.main.url(forResource: "background_music", withExtension: "mp3") { do { player = try AVAudioPlayer(contentsOf: url) player?.numberOfLoops = -1 player?.play() } catch { print("Error playing audio: \(error)") } } } playBackgroundAudio()

I've tried to add the "Pass Type Identifiers" entitlement manually in .entitlements, but it will not archive and shows the error: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. It works correctly for the App (parent of ), but without it the App Clip can't see any passes. The documentation says this should be possible: Note In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. It is not visible in the portal either. Is this an entitlement that I need to specifically request, and if so, how would I go about doing so? Thanks! Wes

Hi Apple Developer Support, I am writing to escalate an urgent unresolved request regarding our app BetterUs (Team ID: TK8M23SECQ, Bundle ID: com.dalesidebottom.betterus). Timeline of attempts: ~1 May 2026 — Submitted FamilyControls Distribution entitlement request via the official form at developer.apple.com/contact/request/family-controls-distribution for bundle IDs com.dalesidebottom.betterus.shield and com.dalesidebottom.betterus.report. No confirmation number received, no response. ~20 May 2026 — Raised support case 102892887667 via developer.apple.com/contact. Received acknowledgement from Eugene. ~21 May 2026 — Replied with all requested information (date of submission, business need, bundle IDs). Today — Still no approval and no further response. It has now been over 3 weeks since the original request. What I need: The FamilyControls Distribution entitlement is already approved on my account for: com.dalesidebottom.betterus ✅ com.dalesidebottom.betterus.monitor ✅ I simply need it extended to these two sub-extensions of the same app: com.dalesidebottom.betterus.shield (Shield Configuration extension) com.dalesidebottom.betterus.report (DeviceActivity Report extension) These are not new use cases — they are part of the same approved parental screen time app. Without this, BetterUs cannot be submitted to the App Store at all. I have active testers waiting and this delay is significantly impacting our launch. I would greatly appreciate urgent attention on this matter. Thank you, Dale Sidebottom

This issue keeps cropping up on the forums and so I decided to write up a single post with all the details. If you have questions or comments: If you were referred here from an existing thread, reply on that thread. If not, feel free to start a new thread. Use whatever topic and subtopic is appropriate for your question, but also add the Entitlements tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining if an entitlement is real In recent months there’s been a spate of forums threads involving ‘hallucinated’ entitlements. This typically pans out as follows: The developer, or an agent working on behalf of the developer, changes their .entitlements file to claim an entitlement that’s not real. That is, the entitlement key is a value that is not, and never has been, supported in any way. Xcode’s code signing machinery tries to find or create a provisioning profile to authorise this claim. That’s impossible, because the entitlement isn’t a real entitlement. Xcode reports this as a code signing error. The developer misinterprets that error [1] in one of two ways: As a generic Xcode code signing failure, and so they start a forums thread asking about how to fix that problem. As an indication that the entitlement is managed — that is, requires authorisation from Apple to use — and so they start a forums thread asking how to request such authorisation. The fundamental problem is step 1. Once you start claiming entitlements that aren’t real, you’re on a path to confusion. Note If you’re curious about how provisioning profiles authorise entitlement claims, read TN3125 Inside Code Signing: Provisioning Profiles. There are a couple of ways to check whether an entitlement is real. My preferred option is to create a new test project and use Xcode’s Signing & Capabilities editor to add the corresponding capability to it. Then look at what Xcode did. You might find that Xcode claimed a different entitlement, or added an Info.plist key, or did nothing at all. IMPORTANT If you can’t find the correct capability in the Signing & Capabilities editor, it’s likely that this feature is available to all apps, that is, it’s not gated by an entitlement or anything else. Another thing you can do is search the documentation. The vast majority of real entitlements are documented in Bundle Resources > Entitlements. IMPORTANT When you search for documentation, focus on the Apple documentation. If, for example, you search the Apple Developer Forums, you might be mislead by other folks who are similarly confused. If you find that you’re mistakenly trying to claim a hallucinated entitlement, the fix is trivial: Remove it from your .entitlements file so that your app starts to build again. Then add the capability using Xcode’s Signing & Capabilities editor. This will do the right thing. If you continue to have problems, feel free to ask for help here on the forums. See the top of this post for advice on how to do that. [1] Xcode 26.2, currently being seeded as Release Candidate, is much better about this (r. 155327166). Give it a whirl! Commonly Hallucinated Entitlements This section lists some of the more commonly hallucinated entitlements: com.apple.developer.push-notifications — The correct entitlement is aps-environment (com.apple.developer.aps-environment on macOS), documented here. There’s also the remote-notification value in the UIBackgroundModes property. com.apple.developer.in-app-purchase — There’s no entitlement for in-app purchase. Rather, in-app purchase is available to all apps with an explicit App ID (as opposed to a wildcard App ID). com.apple.InAppPurchase — Likewise. com.apple.developer.storekit — Likewise. com.apple.developer.in-app-purchase.non-consumable — Likewise. com.apple.developer.in-app-purchase.subscription — Likewise. com.apple.developer.app-groups — The correct entitlement is com.apple.security.application-groups, documented here. And if you’re working on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. com.apple.developer.background-modes — Background modes are controlled by the UIBackgroundModes key in your Info.plist, documented here. UIBackgroundModes — See the previous point. com.apple.developer.voip-push-notification — There’s no entitlement for this. VoIP is gated by the voip value in the UIBackgroundModes property. com.apple.developer.family-controls.user-authorization — The correct entitlement is com.apple.developer.family-controls, documented here. IMPORTANT As explained in the docs, this entitlement is available to all developers during development but you must request authorisation for distribution. com.apple.developer.device-activity — The DeviceActivity framework has the same restrictions as Family Controls. com.apple.developer.managed-settings — If you’re trying to use the ManagedSettings framework, that has the same restrictions as Family Controls. If you’re trying to use the ManagedApp framework, that’s not gated by an entitlement. com.apple.developer.callkit.call-directory — There’s no entitlement for the Call Directory app extension feature. com.apple.developer.nearby-interaction — There’s no entitlement for the Nearby interaction framework. com.apple.developer.secure-enclave — On iOS and its child platforms, there’s no entitlement required to use the Secure Enclave. For macOS specifically, any program that has access to the data protection keychain also has access to the Secure Enclave [1]. See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. com.apple.developer.networking.configuration — If you’re trying to configure the Wi-Fi network on iOS, the correct entitlement is com.apple.developer.networking.HotspotConfiguration, documented here. com.apple.developer.musickit — There is no MusicKit capability. Rather, enable MusicKit via the App Services column in the App ID editor, accessible from Developer > Certificates, Identifiers, and Profiles > Identifiers. These app services are tied to your App ID on the server side, meaning that they have no presence in your code signature. com.apple.developer.shazamkit — There is no ShazamKit capability. Like MusicKit, this is an app service. com.apple.mail.extension — Creating an app extension based on the MailKit framework does not require any specific entitlement. com.apple.security.accessibility — There’s no entitlement that gates access to the Accessibility APIs on macOS. Rather, this is controlled by the user in System Settings > Privacy & Security. Note that sandboxed apps can’t use these APIs. See the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. com.apple.developer.adservices — Using the AdServices framework does not require any specific entitlement. com.apple.security.device.audio-input-monitoring — The com.apple.security.device.microphone entitlement is what restricts microphone access on macOS. [1] While technically these are different features, they are closely associated and it turns out that, if you have access to the data protection keychain, you also have access to the SE. Revision History 2026-05-28 Added com.apple.security.device.audio-input-monitoring to the common hallucinations list (Kevin) 2026-04-23 Added com.apple.developer.shazamkit to the common hallucinations list. Added a little more info about app services. 2025-12-09 Updated the Xcode footnote to mention the improvements in Xcode 26.2rc. 2025-11-03 Added com.apple.developer.adservices to the common hallucinations list. 2025-10-30 Added com.apple.security.accessibility to the common hallucinations list. 2025-10-22 Added com.apple.mail.extension to the common hallucinations list. Also added two new in-app purchase hallucinations. 2025-09-26 Added com.apple.developer.musickit to the common hallucinations list. 2025-09-22 Added com.apple.developer.storekit to the common hallucinations list. 2025-09-05 Added com.apple.developer.device-activity to the common hallucinations list. 2025-09-02 First posted.

Ive spent nearly one month to develop my first app, and now its done. but i am stuck with getting Family Controls Distribution entitlement. i`ve request that one month and half ago. but still get no response. I tried connect the apple developer support、send post on Forum、send code-level support on appstoreconnect. All completely disappeared into a black hole. I understand that you may be facing a significant backlog, waiting for nearly two months without any response or update regarding the Family Controls Distribution entitlement is extremely difficult for me to understand. I genuinely cannot understand why Apple’s review process is operating with such low efficiency.