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

Hello, I am unable to notarize any macOS app/archive with my Apple Developer Team. Every submission is rejected with the same account/team-level error: statusCode: 7000 statusSummary: Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions. The notarization log has: issues: null ticketContents: null This does not look like a code signing or binary validation issue, because multiple different archives/apps fail with the same statusCode 7000. My recent submission history: 2026-05-22 06:25 MSK, ClipDose.dmg, b967a63b-ce9f-486d-805f-a6853ceaf447, Rejected 2026-05-22 07:02 MSK, ClipDose.dmg, 0dd03db8-267d-4b15-bde7-21bd8f22adec, Rejected 2026-05-22 07:39 MSK, ClipDose.dmg, e79f831f-22e9-47b8-9578-344a5067e34c, Rejected 2026-05-22 14:09 MSK, ClipDose.dmg, 01f1bdb3-3323-4952-b735-0e984cad8737, Rejected 2026-05-22 16:58 MSK, ClipDose.dmg, 3e82d154-517f-4e3c-8808-4f6504c05f35, Rejected 2026-05-22 23:30 MSK, FLEX_VIDEO-notary.zip, 7cbc3fa1-749d-4fa3-bab7-18644019d81b, Rejected 2026-05-23 08:41 MSK, FLEX_VIDEO-0.9.2-macOS.dmg, edf241b0-7a0b-4c26-98a8-d3c6f869b0e1, Rejected 2026-05-23 08:47 MSK, SmokeNotary.dmg, 39c9fdf5-0baa-453c-bdd1-7b884fd9e96a, Rejected 2026-05-30 19:58 MSK, SmokeNotary.dmg, 8e14b3a1-5721-4e1a-ab43-000852630e29, was In Progress for about 9 days 23 hours before finally becoming Rejected 2026-05-30 20:43 MSK, FLEX_VIDEO-notary.zip, 1700b9b2-17b5-47c9-8854-cbdbc342d708, Rejected 2026-06-01 18:36 MSK, FLEX_VIDEO-notary.zip, 3d4c986d-af30-4c5c-a987-05ed09b16189, Rejected I have already contacted Apple Developer Programs Support by email / support contact as requested by the notarytool log, but I have not received any response. Could someone from Apple please confirm what exactly needs to be enabled or fixed for this Developer Team? Is statusCode 7000 something that only Apple can resolve on the backend? Thank you.

It's true - go ahead and look. Every single unlucky soul that encounters the "status code 7000", "Team ID not yet configured for notarization" just stops developing for the mac, as they are left with no other option. Based on a deep review of all posts on the subject in multiple online communities & web searches, here's what we know: This problem has existed since at least 2018 People that drew the short straw are directed to contact Apple Developer Support via email Usually after 3 weeks an automated message is sent that the issue has been added to the queue of "the relevant team" Follow-up calls always indicate that the relevant team cannot be messaged even by Apple Support and that you just have to wait for them to contact you. In the past year, Apple now uses an AI bot to email you periodically to inform you that they are "monitoring" the situation and will let you know once "the relevant team" has completed their work. Apple makes it very clear you're trading emails back and forth with an LLM. The "relevant team" never, ever solves the problem or messages anyone. To be fair, the "relevant team" likely doesn't exist. Usually after 3 months, the average would-be developer gives up, and rues the day he paid the apple developer fee as well as all of the time & effort he'd put into making software on the Apple operating systems. Nobody knows why some people get the 7000 error. It seems as if xcode just randomly assigns it to 20 or 30 people per year. But knowing that the "Team ID is not yet configured for notarization" issue is a problem that will never be solved, we need to formulate some alternatives. Some of the avenues I'm brainstorming: Notarize under a different Team ID. This one stings because I went through so much trouble to create an LLC, all for nothing. Apple binds legal entities (DUNS numbers) with Team ID's. So my cursed Team ID and my new LLC cannot be used. My wife is a casual Apple user, I could set her up with her own dev account. That's torching another $99 as well as losing the protection of an LLC (for which I'd paid about $500 for). Sell my apps un-notarized. Apple treats the "7000 lottery losers" so badly that this might be the only path forward. Apparently a brew cask install in order to circumvent the traditional gates. Fellow devs probably don't mind this, but some of my apps are intended for the general public. Still not ideal. Remove 30% of my app's functionality and sell only the mac app store. That's a lot of feature losses that I'd spent months on. Ask any of the thousands of devs that didn't get randomly stricken by the status code 7000 curse to submit the app for notarization. Brand mismatch in Gatekeeper, but at least then we in the Apple Developer's Program can once again participate in the program we paid to be in. Set up our apps as open source, and include a link for funds. That means the LLC formation was a complete waste of $500. There's not a single Apple employee reading this that can help get us out predicament. If there was, we would have had at least one post anywhere on the internet about successfully overcoming the statuscode 7000 issue. Instead its just hundreds of posts by fee-paying developers saying they waited two, three, or 6 months before finally giving up and moving on to windows & linux software development. For the rest of my life, I'm going to wonder the following: Why was I singled out to get this status code error? If this problem has existed for at least 8 years, and has hundreds of posts about it, why is every single Apple support specialist completely clueless as to the cause of it? Why doesn't Apple have resolution metrics? That's got to be hundreds of unresolved status 7000 cases that have piled up. The company doesn't do any kind of internal reviews? Do they seriously mark cases as closed once its sent to "the relevant team"? And finally....don't Apple employees also think it's weird that "the relevant team" is a nameless, unknowable group that can never be contacted by their fellow co-workers? Like, everyone at Apple Support knows a phone number to reach the head office, or some method to reach C-suite secretarial pool. But the "relevant team" has no internal phone number available that other Apple staff can contact? For 25 days, I've spent between two and six hours each day trying to resolve my status code 7000 problem. That's time I've spent away from work and family, just to keep trying to resolve this issue. Knowing now that it will never be resolved does help as I try to pick up the pieces of my failed software development plans. Quinn/mods - please don't delete this. The people who get the status error need to know this. Absolutely no one who gets the 7000 code should be given false hope that "Oh just contact Apple Developer Support to resolve." At this point there's got to be hundreds of us that know the bitter truth that 7000 is a permanent, lifelong block. These unlucky devs need to immediately face reality so they can figure out the solutions to best navigate their business.

I m from India and used two credit cards to purchase the Developer account for $99 but payment doesn't go through. Please help as this has been pending for two weeks.

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.

Hello, My Apple Developer account has been under review for over a week and is still showing "Validation in Progress." I would appreciate any update regarding the status of my application, as I have not received any requests for additional information. Thank you. Best regards

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

Hello Apple Developer Support, I am requesting maximum escalation for this case. My paid Apple Developer Program account has been unusable for Developer ID notarization for more than two weeks. This blocks macOS distribution entirely, despite the fact that the membership is active and all visible account requirements appear to be completed. Team ID: GRP4HM9M63 Apple Developer Program: Active Account status already checked: Apple Developer Program membership is active Apple Developer Program License Agreement is accepted Apple Developer Agreement is accepted Free Apps Agreement is active W-8BEN tax form is active Developer ID Application certificate exists and is active The applications are signed with Developer ID Application Hardened Runtime is enabled Local codesign verification passes Despite this, notarization is still unavailable for this Team. This is not an issue with a specific app, archive, DMG, ZIP, signing configuration, or binary validation. Multiple different apps and archives are rejected with the same account-level error before binary validation. Recent failed submissions: Cassini.zip Submission ID: a429460d-cdf9-47cc-9731-90bac71286af Status: Rejected Status code: 7000 Status summary: “Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.” Issues: null Lunoura.zip Submission ID: 3aa46853-b3c7-4076-a08d-f9e4db9bea64 Status: Rejected Status code: 7000 Status summary: “Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.” Issues: null Earlier submissions for Cassini.dmg and Cassini.zip were also rejected with the same statusCode 7000. Since multiple unrelated archives are affected and all logs contain issues: null, this clearly appears to be a Developer Team/account configuration issue on Apple’s side, not an application validation issue. Please escalate this case to the appropriate Developer Program / notarization backend team and urgently check the notarization configuration for Team ID GRP4HM9M63. Please explicitly confirm: Whether Team ID GRP4HM9M63 is currently enabled for Developer ID notarization. Whether there is any hidden account, KYC, legal, compliance, tax, or backend configuration issue blocking notarization. Whether Paid Applications Agreement or bank account setup is required for Developer ID notarization, even though we are not distributing paid apps. What exact action is required from our side. When this paid Developer Program account will become usable for Developer ID notarization. This issue has already blocked us for more than two weeks. We are paying for Apple Developer Program membership, but cannot use a critical Developer ID distribution feature.

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.

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?

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.

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