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"

Hoping to get visibility on a Family Controls (Distribution) entitlement request pending without status updates after an app transfer. Context: Digital wellbeing app, 500K+ active iOS users Previous team had Family Controls (Distribution) approved and shipping to production App transferred to new team (H2HM68H8PP) ~1 month ago; entitlement re-requested immediately Capability page shows "View Requests (6)" with no approvals, rejections, or updates Developer Support cases opened (102883853173, 20000112879750, 102875975624) — confirmed they cannot check entitlement status Impact: Core app feature depends on Family Controls. Production app for 500K+ users will break once transfer fully propagates at provisioning level. This is a continuity issue, not a new-app launch — entitlement was previously approved on the prior team. Questions: Recommended escalation path for post-transfer entitlement requests? Should I stop resubmitting to avoid queue deprioritization? Could the entitlements team provide a status update? Happy to share bundle ID, previous team ID, and request dates privately with Apple staff.

Hi, Two notarization submissions on my Team ID are stuck "In Progress" well past normal turnaround. Looking for guidance on whether this is normal first-time-enrolment latency or whether something needs escalating. Team ID: U7N63C278S Submissions: 2ac71ef0-cbfa-4bdd-9059-c2554050de48 — submitted 2026-05-14 08:09 UTC (currently ~48 hours In Progress) c2b557c5-92a2-4c36-996e-812b61b67fe6 — submitted 2026-05-14 11:33 UTC (currently ~46 hours In Progress) Status: xcrun notarytool history shows both as "In Progress" xcrun notarytool info <id> returns no log URL, no message, no error No rejection email received at the APPLE_ID address Apple System Status shows Developer ID Notary Service as green Context: This is my first notarization from a newly enrolled Developer Program account (enrolled ~5 days ago). I'm aware first-time submissions can be subject to longer in-depth analysis, which is why I haven't escalated sooner. Build verification (already done): codesign --verify --deep --strict -verbose=2 exits 0 Hardened runtime flag (0x10000) present on top-level .app and every nested Mach-O Full Developer ID Application chain (signed by Developer ID Application: poojan (U7N63C278S)) Secure timestamp present Universal binary (x86_64 + arm64) Every nested framework, helper app, and binary signed Built with electron-builder, hardened-runtime entitlements, notarized via notarytool submit --wait Question: Is this within expected first-time-enrolment latency, or is there something on the notary service side that needs a nudge? Happy to provide additional codesign output or the .app bundle structure if useful. Thanks for any guidance.

I'm posting this so other devs hitting error 7000 know they're not alone, and so this gets some visibility outside the support ticket black hole. Timeline: End of February 2026: first notarization attempts. All rejected with status code 7000 March 1st: first support case opened Today, beginning of May: still blocked. Still error 7000 Four cases: 102833704616, 102836645198, 102842517951, 102865000390. Different advisors each time. I've uploaded my government ID twice. When I ask for a status, the answer is "I'll get back to you when I have news." Then silence. My setup is fine. Team ID is Y564MF82K8. App is signed with Developer ID Application, hardened runtime, secure timestamp, no get-task-allow, deep verify clean. Apple rejects the submission before inspecting the binary. The block is on Apple's side. Somebody needs to push a button but they cannot agree who needs to push it, so they just pass it from one department to another. The "correct escalation path" doesn't work. Quinn (Apple DTS engineer) keeps saying on this forum that error 7000 is administrative and the path is Developer Program Support (https://developer.apple.com/forums/thread/118465?answerId=379585022#379585022). I followed that path four times. The cases just sit there. Threads on this forum about error 7000 go back to 2019. Six years. Devs report cases stuck for weeks, months, with the same scripted responses. Apple knows. Apple does nothing. I'm a solo dev and I want to do a proper launch of my SaaS on all major desktop platforms. I paid the $99. I built the app. I signed every agreement. I cannot launch on macOS because Apple's departments cannot agree on who needs to push a button. If anyone here has actually unblocked error 7000, please share what worked. The official path obviously doesn't.

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.

Hi all, I'm submitting a Developer ID-signed, hardened-runtime app for notarization. Every submission returns: "statusCode: 7000 statusSummary: Team is not yet configured for notarization. Please contact Developer Programs Support..." Team ID: V67NRZ84A2. Apple Developer membership is active, Developer ID Application certificate is valid, signing/verification all clean. Already opened a support case last week via the recommended path. The "contact page" on the developer site said Apple usually responds within 2 business days.... Has anyone hit this and gotten it resolved? How long did it take, and was there a more effective channel than the standard support form? I've seen people on Reddit claim they've actually been able to call a Developer phone line, but I haven't seen a valid phone number anywhere. I appreciate your response!

We have been having unexplained failures with the codesign tool recently on macosx aarch64 and x64 hosts. Every once in a while when signing an app locally using the following command: /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app results in the following error: /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock The number of seconds reported in the error message keeps varying (but usually in that range). We have checked the system clock but there isn't anything wrong (from what we can see) with the host. In fact, we have been seeing this error on several hosts now, so it isn't specific to one host. While looking into this issue, we even printed the details of an already signed binary using the following command: codesign -dvvv HelloWorld.app and that prints among other things, similar warning message: ... Timestamp=12 May 2026 at 5:36:0 AM HelloWorld.app: timestamp mismatch: internal time 12 May 2026 at 5:32:59 AM (184 seconds apart) I'm looking for inputs on how we go about debugging this issue and where/how the codesign tool sources these timestamps from (any specific API?) and what value is it comparing against to notice a difference. These affected hosts have different operating system versions some 15.x and some 26.x.

Hello, We are currently in the process of creating our Developer ID Application certificate which is due to expire. While creating the certificate, we were posed with the option of choosing a Developer ID Certificate Intermediary G2 Sub CA which is supported by Xcode 11.4.1 and later Previous Sub CA We currently build our application out of Xcode using Make or CMake files and perform the codesign and productsign using the codesign commands. We also use 2 different build machines, Ventura with Xcode 14.3 for our latest releases High Sierra (10.13) with Xcode 10.1 for legacy releases to support some customers. Can you please let us know which Developer ID Certificate Intermediary we should choose for generating the new Developer ID Application certificate?

I've been waiting on the Family Controls distribution entitlement for my app for over two weeks with use case to self direct app and sites blocking Setup: Development entitlement: ✅ approved and working Request ID: 27684X55GC The blocker: Xcode warns: "Bundle identifier is using development only version of Family Controls (Development) capability. Please request access to Family Controls (Distribution)." Archiving for App Store fails with provisioning profile errors on all my targets Questions: Is 2+ weeks normal for distribution entitlement approval? Any recommended path to escalate besides the request form and have also emailed apple support?

Hi, I submitted my Family Controls entitlement requests on April 15 for my iOS app, but I still haven’t received an approval, rejection, or any status update. This is blocking my ability to properly test and move forward with the app, since it depends on the Screen Time / Family Controls APIs. I've tried contact to apple developer support and filed a code-level support on app connect dashboard. and still nothing received. Here is the request information: code-level support case id: 19834379 apple developer support case id: 102878196850 Family Controls Distribution RequestId: BT4C47F5VB,SLP56WRZ3J,BZ7MF3R4FF,5HAY5UF5X2,P49SM5C859,KG2T2X2L76,N353H759C4 Thanks.

Hi DTS, I have 4 notarytool submissions all stuck in "In Progress" with no movement for 12+ hours. 'xcrun notarytool log <id›' returns "Submission log is not yet available" for all of them - they don't appear to have been processed at all. Team Identifier: NS22D2XK8A 1 .dmg submission at 2026-05-12T01:35Z (12+ hours stuck) dmg submissions between 10:04Z and 12:12Z This is my first time notarizing with this Team ID - possibly the new-account first-submission "in-depth analysis" delay? The DMG passes every standard check: Signed with Developer ID Application (Team NS22D2XK8A) Hardened runtime on all 6 embedded binaries (codesign flags 0x10000) Full authority chain: Developer ID App → Developer ID CA → Apple Root CA Secure timestamp present Entitlements: allow-jit, allow-unsigned-executable-memory, disable-library-validation, network.client, network.server, files.user-selected. read-write codesign --verify -deep --strict passes cleanly spctl source = "Developer ID Application" (correct) DMG itself signed inside-out per TN2206 I have read the other recent "stuck In Progress" threads from new Developer IDs - same pattern. Could the queue be unblocked, or is there a team-side configuration that needs flipping? Happy to provide submission UUIDs + filenames privately via Feedback Assistant or DM. Thanks!

Hi, I'm building a wellness app called that helps users manage their phone usage based on their consumption, using the Screen Time API. I need the Family Controls (Distribution) entitlement to ship it. I've already submitted multiple requests across all my bundle IDs, but due to the lack of confirmation feedback after each submission, I may have submitted more than needed. Regardless, the oldest request submitted was on April 22nd (exactly 2 weeks ago), without any reply or change. Is this normal ? Also, I came across a forum post (https://developer.apple.com/forums/thread/821964?answerId=885672022#885672022) suggesting that the entitlement is now scoped at the team level rather than per bundle ID, and that I should resubmit a single request. I want to do the right thing here but I'm not sure whether to resubmit or wait and I don't want to make the situation worse than it already is. We're about a month away from our launch date and this is the last remaining blocker for both TestFlight and App Store submission. Any guidance on next steps, or help prioritizing this, would mean a lot. Thanks so much,

tle: New account — all notarization submissions stuck In Progress 26+ hours Hi, I recently enrolled in the Apple Developer Program and all my notarization submissions have been stuck "In Progress" for over 26 hours with no resolution. Team ID: 799833449H Submission IDs: bb31ba38-9ff4-416d-b6ea-8ad88b84a2be (26+ hours) 8fdd039d-3db4-4e96-8111-37dba9d4afd2 (25+ hours) 685cba55-aacd-4a05-8086-707a6b88e138 (23+ hours) Binary is a universal macOS binary, codesign verifies cleanly with hardened runtime. notarytool log returns "not yet available" for all. Is this the in-depth analysis path for new accounts? Any ETA or action needed from my side?

Hello, My macOS notarization has been blocked since March with: "status": "Rejected", "statusCode": 7000, "statusSummary": "Team is not yet configured for notarization", "issues": null Latest fresh probe: Submission ID: 3201b921-2313-45fd-b274-0e46d3fb03c2 Upload time: 2026-05-09T12:37:16Z Archive: KwantflowNotaryProbe-20260509T123714Z.zip Status: Rejected Error: -2052 / 7000 Issues: None Support cases: 102842156916 — Development and Technical → Other Development or Technical Questions 102882811151 — Development and Technical → Code Signing The archive uploads successfully and notarytool history/log work, but every submission is rejected before binary validation. The log shows no signing, entitlement, hardened runtime, timestamp, or executable issues. Apple forum answers say this is a Developer Program Support issue, not DTS/code-level. I have already contacted Developer Support, but the issue is still unresolved and blocks our macOS release. Has anyone recently resolved -2052 / 7000 / “Team is not yet configured for notarization”? Did Apple need to manually enable something on the team/account? Thank you.

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?

We are implementing an exam mode feature for an educational app used in schools, which restricts device usage during assessments. We requested the Automatic Assessment Configuration capability, received approval from Apple, and confirmed that the capability is listed as Assigned under our App ID in the Apple Developer portal. What works: When using a Development Provisioning Profile (downloaded from the portal), the entitlement key com.apple.developer.automatic-assessment-configuration is included in the profile, and our exam lock feature works correctly in development testing. The problem: When we manually download a Distribution (InHouse/Enterprise) Provisioning Profile from the portal — even after creating a new one — the entitlement key com.apple.developer.automatic-assessment-configuration is not present in the profile. verified this by running: security cms -D -i YourProfile.mobileprovision The key appears in the Development PP but is absent in the manually downloaded Distribution PP, despite the App ID showing the capability as Assigned. Note: When using Xcode's automatic signing, the generated profile does include the entitlement correctly. However, due to our organization's internal security policy, we are required to use manually managed provisioning profiles and cannot use Xcode automatic signing for distribution builds. Questions: Is the com.apple.developer.automatic-assessment-configuration entitlement intentionally restricted to Development profiles only, or is this a known portal issue with managed capabilities not being embedded in manually created Distribution profiles? Is it technically supported and intended to use AEAssessmentSession in an InHouse (Enterprise) distribution environment? If InHouse is not supported, is the correct path to test internally via Development profiles and then submit through App Store distribution to include this entitlement in production? Any guidance on the correct technical direction would be greatly appreciated.

Hello, I've been trying to notarize my macOS app using xcrun notarytool, but all submissions get stuck in "In Progress" status indefinitely (30+ minutes, never resolve). Environment: Tool: xcrun notarytool (Xcode 16) Bundle ID: io.pix-cull.app Team ID: C473MUK7G2 App type: PyInstaller-built .app, wrapped in a signed .dmg Stuck submission IDs: 00e953da (first attempt) f7ab027e 3e35fc3f 293541bc-ba61-4ccb-a273-a8f34cda2422 (most recent) Steps I've already taken: Disabled UPX compression in PyInstaller spec Signed all binaries inside-out (deepest first, .app last) Used --timestamp flag during codesign Verified Apple system status — all services show green Waited 24+ hours on the oldest submission — still "In Progress" What I observe: Running xcrun notarytool info <id> returns status: In Progress every time, no matter how long I wait. The submission never transitions to "Accepted" or "Invalid". Other developers report notarization completing in 2–15 minutes. I also submitted a ticket to Apple Developer Support (DTS), but I'm posting here as well in case anyone has seen this pattern. Is there something wrong with my account that could cause all submissions to stall? Any guidance would be appreciated. Thank you.

Dear Apple Developer Support, We are experiencing an issue where our properly signed, notarized, and stapled PKG installer is being blocked by Gatekeeper on macOS Sequoia (15.3), despite passing all notarization checks. Team ID: 3888L7DV3P Organization: SKY GATE TECHNOLOGYS K.K. Certificate: Developer ID Installer: SKY GATE TECHNOLOGYS K.K. (3888L7DV3P) Issue Details: Our PKG installer is signed with "Developer ID Installer" certificate, notarized (status: Accepted, issues: null), and stapled successfully. pkgutil --check-signature confirms: "signed by a developer certificate issued by Apple for distribution" and "Notarization: trusted by the Apple notary service" xcrun stapler validate confirms: "The validate action worked!" However, spctl --assess --type install returns "rejected" with assessment:verdict = false and assessment:remote = true The system log shows: meetsDeveloperIDLegacyAllowedPolicy = 0 When users download and open the PKG (even from within a notarized DMG), Gatekeeper displays: "Apple could not verify [app] is free of malware" Notably, our .app bundles signed with "Developer ID Application" (same Team ID) pass Gatekeeper without issues. Only PKG installers are affected. Our software is a legitimate enterprise security product (VPN/Zero Trust client) distributed to corporate customers. Could you please: Investigate why our Team ID's PKG installers are being rejected by Gatekeeper's online assessment despite valid notarization Advise on any steps we can take to resolve the meetsDeveloperIDLegacyAllowedPolicy = 0 status for our Team ID Confirm whether there is a trust establishment process for new Developer ID Installer certificates with the Gatekeeper service Thank you for your assistance. Best regards, Riku Ogura Skygate Technologies K.K.

I submitted a Family Controls Distribution entitlement request on April 21, 2026 for my app Dopfast. I also resubmitted on April 29, 2026. I received the confirmation page both times but have not received any approval, rejection, or status update. I contacted Developer Support (Case #102879238806) and was told the request is handled by another team and they cannot check the status. Details: Team ID: HSJ6KB4WEZ App: Dopfast (digital wellbeing / screen time management) Bundle ID: com.dopfast Purpose: #2 — individual device management for focus and productivity (personal screen time tracking and app blocking) This entitlement is the only remaining blocker for our App Store submission. The app is fully built and ready to ship. Has anyone experienced similar delays recently? Is there a recommended way to expedite this request?