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"

Validation failed (409) Missing Code Signing Entitlements. No entitlements found in bundle 'com.seeyon.yiboyun.child' for executable 'Payload/M3.app/PlugIns/CMPSharePublish.appex/CMPSharePublish'." (ID: 6e5429ed-b896-45a0-ab23-bb8fcb472072)

Can someone please explain why Mac app packaging is so farcically convoluted? Windows app packaging can be picked up in an hour or so. But I've spent longer trying to fathom how to package the Mac version than I did building the app. And it's not done with me yet. Every single line of code requires a deep dive into a new, unrelated skillset. So, it’s sidebar after sidebar. Kafka’s ‘The Trial’ comes to mind. Why does it have to be like this?

Hello, I am a new macOS developer. I've been working on my first Mac application and I am trying to notarize it for distribution using notarytool. However, I've encountered a persistent issue where all my submissions are stuck in the "In Progress" status for several days. As this is my first time going through this process, I initially thought I might have done something wrong. However, I have verified my app with codesign --verify --verbose --deep and it returns "valid on disk" and "satisfies its Designated Requirement". I have also tried bumping the version from 0.1.0 to 0.1.1 and removing spaces from the file names, but the new submission is also stuck. Stuck Submission History (Total 4 submissions): ID: 8cb4aebb-e2d5-4091-b279-18272c3a6ca9 (Created: 2026-04-03 - Latest) ID: 0e9a3584-1a21-471a-bc72-4da3f98e2683 (Created: 2026-04-02) ID: 59b70ef1-0b8e-480d-ba33-df872a691610 (Created: 2026-04-01) ID: 685d8fdb-1e55-4cdd-8203-688991c50dd3 (Created: 2026-04-01) As a first-time developer, it’s frustrating to see these initial submissions hang for so long without any logs or errors to troubleshoot. Is there any specific reason why a first-time submission for a new Mac app might be queued this long? I would appreciate it if someone from Apple could help clear these stuck submissions or provide some guidance as to what might be causing this delay. Thank you very much.

I added a new device and it's not recognizing the device model. This causes a message saying "Unable to verify" when signing an app. Has anyone else encountered this issue? This only happens with this one device, not others.

Hi, I am developing a iOS app with Packet Tunnel Provider Network Extension. I manage signing manually. I created a distribution provisioning profile. Then when I archive and click "validate" I get this error: Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'url-filter-provider' for key 'com.apple.developer.networking.networkextension' So I run security cms -D -i profiles/vpn_distribution.mobileprovision and I see there <key>Entitlements</key> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>app-proxy-provider</string> <string>content-filter-provider</string> <string>packet-tunnel-provider</string> <string>dns-proxy</string> <string>dns-settings</string> <string>relay</string> <string>url-filter-provider</string> <string>hotspot-provider</string> </array> Where are those coming from. My entitlement file has <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider</string> </array> <key>com.apple.security.application-groups</key> <array> <string>group.my-app-group</string> </array> </dict> </plist> What is happening here. How can I get a provisioning profile that only has the entitlements that I actually need?

Hello, I have a question regarding Apple's policy on third-party SDK signatures. I have reviewed the official documentation here: https://developer.apple.com/support/third-party-SDK-requirements/ Our app is developed in the following environment: Minimum Target: iOS 15 Xcode: 26.2 Engine: Unreal Engine 4.27.2 We are integrating the Firebase SDK into our project. However, we are experiencing app crashes caused by an issue within the GoogleAdsOnDeviceConversion.xcframework included in the Firebase SDK (related to a memory optimization issue in UE4). According to an official response from the Firebase team, this crash can be resolved by wrapping the Firebase SDK in a dynamic XCFramework. We have confirmed that this solution does indeed fix the crash. The problem is that wrapping the Firebase SDK in a custom dynamic XCFramework removes all of the original Firebase SDK signatures. The documentation on third-party SDK signatures, which I referenced earlier, states that a signature is required for the Firebase SDK, and this requirement also applies when repackaging it. This leads me to the following questions: Question 1: When we wrap and repackage the Firebase SDK, is it mandatory for the resulting XCFramework to still include the original Google LLC signature? Question 2: To resolve the crash, we intend to use the Firebase SDK by wrapping it in our own dynamic XCFramework (e.g., FirebaseWrapper.xcframework). When we do this, the resulting XCFramework loses the Google LLC signature, and consequently, the final built IPA's signature list does not contain any Firebase-related signatures. Will this be a reason for rejection during App Store review? Question 3: If we wrap the Firebase SDK in a dynamic XCFramework and then sign it with our own developer certificate, would this be a reason for rejection during App Store review?

Hi All, Really weird one here... I have two bundle ids with the same reverse dns name... com.company.app1 com.company.app2 app1 was installed on the device a year ago. app2 was also installed on the device a year ago but I released a new updated version and pushed it to the device via Microsoft InTunes. A year ago the vendor Id's matched as the bundle id's were on the same domain of com.company. Now for some reason the new build of app2 or any new app I build isn't being recognised as on the same domain as app1 even though the bundle id should make it so and so the Vendor Id's do not match and it is causing me major problems as I rely on the Vendor Id to exchange data between the apps on a certain device. In an enterprise environment, does anyone know of any other reason or things that could affect the Vendor Id? According to Apple docs, it seems that only the bundle name affects the vendor id but it isn't following those rules in this instance.

Hello! All notarization submissions for our team (i.e., me) have been stuck "In Progress" since my first attempt on 2026-03-31. This includes a trivial Hello World CLI binary (single print statement, ~8KB), confirming the issue is account/team-level, not related to package content. Team ID: KK4X4YSB8V (Selitic B.V.) This is our first time notarizing. Binary is properly signed with Developer ID Application certificate, hardened runtime enabled, valid timestamp. codesign --verify and spctl pass locally. Submission history (all stuck): Successfully received submission history. history -------------------------------------------------- createdDate: 2026-04-01T11:29:01.416Z id: 39f5e536-d1a6-429b-947d-1a3ac497c03d name: hello-test2.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T09:21:47.585Z id: 46322e0f-026c-4b9d-ab1f-d15d7013c6c6 name: hello-test.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T07:23:47.576Z id: 8199ab8c-7897-461e-8a85-329d3eb22568 name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T05:49:10.593Z id: 410ebd83-8f7d-436a-b30e-2106e9847b2a name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T05:48:52.555Z id: 3d096415-46f9-4743-9dee-692f1c359249 name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-03-31T20:07:52.318Z id: a0e2e5a5-e0ea-4815-86d4-d1c335c4680a name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-03-31T20:07:15.593Z id: 1684585c-c454-479d-add6-7fd33ae8da2a name: nekode-notarize.zip status: In Progress notarytool log returns "Submission log is not yet available" for all submissions, indicating Apple's backend has not started processing. No pending agreements visible on developer.apple.com/account. Certificate is valid (expiry 2031). Could someone check the backend queue status for my team? Any guidance appreciated.

急需一个企业开发者证书，有意者可联系tg:@moonkf2025

Hi Team, i'm running into same issue with notarization time. I create new, small app for a customer but however the notarization is running since this morning, so almost a few hours. This isn't normal or ? Is there anything what i can do ? Best regard, Lars

Team ID: LA64G2ZMY2. Submission f28e6a62-5a46-4554-a4b9-666269b3017f has been "In Progress" for over 24 hours. App is signed with hardened runtime, valid Developer ID certificate, HFS+ DMG format (not APFS - aware of DTS r. 134264492). Codesign verifies clean. All requirements met per Apple documentation. Is notarization provisioning needed for new accounts?

I'm working on an app that needs access to device activity. When I add device activity entitlement, I'm getting Provisioning profile "..." doesn't include the com.apple.developer.deviceactivity entitlement. This is failing for both, the main app and the extension, and both have entitlements added. It is not clear how to add it to the profile, the provisioning profile is created/managed by XCode. When I remove the entitlement, I can build my app but it won't be able to use device activity data I reached out to Developer Support, and they sent me here. What is the right way to add device activity entitlement? I'm also seeing another issue with XCode Cloud builds. When I remove device activity entitlement. I can build my app w/o any issue, and I can also install it directly on my iPhone. However, XCode Cloud builds fail wit Run command: 'xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/d41fc2f1-4f39-4906-8941-112488e75f6c.xcarchive -exportPath /Volumes/workspace/adhocexport -exportOptionsPlist /Volumes/workspace/ci/ad-hoc-exportoptions.plist '-DVTPortalRequest.Endpoint=http://172.16.68.193:8089' -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/ad-hoc-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3' I suspect that it could be related to my app having DeviceActivityExtension but no device activity entitlement is present. Thanks, Peter.

I signed all the agreements yesterday what is going on Agreements Apple Developer Program License Agreement Issued March 30, 2026. Accepted April 5, 2026. Apple Developer Agreement Issued June 7, 2015. Accepted December 29, 2017. Uploading the disk image for notarization... Error: HTTP status code: 403. Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired. `notarytool` command status: 1 notarytool returned no output at all. Error output: > > Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired. > >

Hey, So i am trying to setup OpenGL on my mac. Specs : M2 Pro, 15.5 (24F74) Now i have setup the entire project properly as far as i know. GLFW, GLAD and the OpenGL framework. the build libraries are also reference and everything. I have also included the glad.c file in the folder. i have also kept it to run locally in signing tab. its still giving me Command CodeSign failed with a nonzero exit code All the ss are provided

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

I have 14 total devices, from way back. I am currently in a financial bind and can't renew just yet. BUT I am at past my time to reset the device list back to zero. But the screen to do that is behind the paid account. Catch 22 Can we fix it? As it stands I must email tech support, but this is a bug so I posted

Hi everyone, I’m having trouble getting remote push notifications working on iOS for a production Flutter app, and it looks like it’s related to the provisioning profile / entitlements used during signing. Context Platform: Flutter Push provider: OneSignal (backend is Supabase; Android push works fine) CI: Codemagic Target: iOS TestFlight / App Store builds I’m on Windows, so I cannot open Xcode locally. All iOS builds happen via Codemagic. Capabilities / entitlements In the Apple Developer portal, my App ID for com.zachspizza.app has: Push Notifications capability enabled A separate Broadcast capability is listed but currently not checked. In my repo, ios/Runner/Runner.entitlements contains: xml aps-environment production So the project is clearly requesting the push entitlement. Codemagic signing setup For my App Store workflow (ios_appstore_release in codemagic.yaml ): I use a combination of manual and automatic signing: Environment variables can provide: P12_BASE64 + P12_PASSWORD (distribution certificate) MOBILEPROVISION_BASE64 (a .mobileprovision file) A script in the workflow: Creates a temporary keychain. Imports the .p12 and installs the .mobileprovision into ~/Library/MobileDevice/Provisioning Profiles. For the final export, I generate an exportOptions.plist that does: If a profile name/UUID is provided via env (PROV_PROFILE_SPEC, PROV_PROFILE_UUID, PROVISIONING_PROFILE_SPECIFIER, PROVISIONING_PROFILE): xml signingStylemanual provisioningProfiles com.zachspizza.app[profile name or UUID] Otherwise, it falls back to: xml signingStyleautomatic After archiving and exporting, my script runs: bash codesign -d --entitlements :- "$ARCHIVE_PATH/Products/Applications/Runner.app" ... and again on the signed Runner.app inside the exported IPA codesign -d --entitlements :- "$SIGNED_APP" In both cases, the effective entitlements output does not show aps-environment, even though: The App ID has push enabled. Runner.entitlements includes aps-environment = production. Observed behavior iOS devices (TestFlight build) do not receive remote push notifications at all. Android devices receive notifications as expected with the same backend payloads. OneSignal configuration and backend are verified; this appears to be an APNs / signing / entitlements problem. The Codemagic logs strongly suggest that the provisioning profile being used for signing does not carry aps-environment. Questions Under what conditions would a distribution provisioning profile (for an App ID with Push Notifications enabled) result in a signed app without aps-environment, even when: The entitlements file in the project includes aps-environment, and The App ID in the Developer portal has Push Notifications enabled? Does using a CI flow like the above (custom .p12 + .mobileprovision installed via script, exportOptions with signingStyle=manual) increase the chances of: Xcode ignoring the requested entitlements, or Selecting a provisioning profile variant that does not include the push entitlement? Is there a recommended way, from the Apple side, to verify that a given .mobileprovision (the one I’m base64-encoding and installing in CI) definitely includes the aps-environment entitlement for my bundle ID? i.e., a canonical method to inspect the profile and confirm that APNs is included before using it in CI? Are there any known edge cases where: The project entitlements include aps-environment, The App ID has Push Notifications enabled, But the final signed app still has no aps-environment, due to profile mismatch or signing configuration? Given that I’m on Windows and can’t open Xcode to manage signing directly, I’d really appreciate guidance on how to ensure that the correct push-enabled provisioning profile is being used in this CI/manual-signing setup, and how to debug why aps-environment is being stripped or not applied. CodeMagic Signing/Export Step: Signing / entitlements output from Codemagic Dumping effective entitlements for Runner.app in archive... /Users/builder/clone/build/ios/archive/Runner.xcarchive/Products/Applications/Runner.app: code object is not signed at all Failed to dump entitlements Exporting IPA with exportOptions.plist... 2025-11-20 22:25:00.111 xcodebuild[4627:42054] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path "/var/folders/w2/rrf5p87d1bbfyphxc7jdnyvh0000gn/T/Runner_2025-11-20_22-25-00.110.xcdistributionlogs". 2025-11-20 22:25:00.222 xcodebuild[4627:42054] [MT] IDEDistribution: Command line name "app-store" is deprecated. Use "app-store-connect" instead. ▸ Export Succeeded Dumping entitlements from signed Runner.app inside exported IPA... Executable=/private/var/folders/w2/rrf5p87d1bbfyphxc7jdnyvh0000gn/T/tmp.LHkTK7Zar0/Payload/Runner.app/Runner warning: Specifying ':' in the path is deprecated and will not work in a future release application-identifier.com.zachspizza.app beta-reports-active com.apple.developer.team-identifier get-task-allow As you can see, the signed app’s entitlements do not contain aps-environment at all, even though Runner.entitlements in the project has aps-environmentproduction and the App ID has Push Notifications enabled. Thanks in advance for any help and pointers.

Hi, I'm currently at 19 hours waiting for notarization. My dev account is new and this is the first time I'm submitting anything to be notarized. I've gathered from my research that this is normal (unfortunately). I figure the only thing I can do is wait, but is there any way for me to know if I'm waiting for a human to manually review it? I was going to file a support request, but I saw that they won't be responding to any support requests until after their Thanksgiving break, and I assume nobody is manually reviewing notary submissions for the next week+. I attached the submission below, thanks! createdDate: 2025-11-21T21:17:10.082Z id: c9746d42-1dc7-4641-aec1-62c6cedff1a2 name: ***********.zip status: In Progress

I’m looking for guidance on a notarization submission that has been stuck in In Progress for over 24 hours. Details: Team ID: 94B7AVM73F Certificate: Developer ID Application: Bilal Ahmed Qureshi (94B7AVM73F) Tool: xcrun notarytool File: FlashcardGeneratorTrial-AppleSilicon.dmg Submission ID: 7817f9d0-32da-452f-9e2d-fff43478ccf6 Submission created: 2026-04-17T22:10:01.402Z Current status: xcrun notarytool info still reports In Progress This has now been ongoing for more than 24 hours The submission uploaded successfully and received a valid submission ID The Developer ID certificate is valid and correctly paired with the private key in Keychain security find-identity -v -p codesigning returns 1 valid identity Environment: First-time notarization on this developer account macOS direct distribution outside the Mac App Store DMG signed with Developer ID Application certificate Hardened runtime and timestamp enabled during signing I’ve seen some other recent reports of long notarization delays, especially for first-time submissions, so I’m trying to understand whether this is expected queueing / in-depth analysis, or whether there may be an issue with this specific submission. Questions: Is this normal for a first notarization on a new Developer ID account? Is there anything I should do besides wait? Can Apple check whether this submission is stuck in the queue? Thanks.

I'm unable to notarize my macOS app — notarytool returns statusCode 7000 ("Team is not yet configured for notarization"). My Developer ID certificate is valid (expires 2031), code signing works fine. Timeline: March 4 — opened case 102832266798 via Developer Programs Support March 6 — Apple replied, but the email never arrived (not in spam either) March 9 — sent follow-up requesting the response be resent — no reply March 13 — opened new case 102840272497 via Program Enrollment form — waiting It's been 9 days with no resolution. DTS confirmed this is not a technical issue and referred me to Developer Programs Support. Team ID: 9NL8W3646T Bundle ID: com.traart.app How can I escalate this? Has anyone experienced a similar situation with a new account?