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?

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.

Made a notarization request a few hours ago and woke up to check the history and it's no longer available. Not rejected/accepted just not found. I have gone ahead to make another request but I have no confidence because I expect the same thing to happen again. Any guidance? See logs below: daramfon@MacBook-Pro-3 frontend % xcrun notarytool history --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" Successfully received submission history. history -------------------------------------------------- createdDate: 2026-02-20T23:53:14.066Z id: 6f2fadc0-2e8f-4331-a253-68f81334ebc6 name: Speakeasy AI-0.1.0-arm64.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-20T23:47:12.897Z id: 435aec4f-5356-49a5-898d-48aaafb7949f name: Speakeasy AI.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-20T22:35:23.947Z id: 95896757-873a-4e54-a527-03dc767c9cb5 name: Speakeasy AI.zip status: In Progress daramfon@MacBook-Pro-3 frontend % xcrun notarytool history --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" No submission history. daramfon@MacBook-Pro-3 frontend % xcrun notarytool info 6f2fadc0-2e8f-4331-a253-68f81334ebc6 --apple-id "$APPLE_ID" --password "$APPLE_APP_SPECIFIC_PASSWORD" --team-id "$APPLE_TEAM_ID" Submission does not exist or does not belong to your team. id: 6f2fadc0-2e8f-4331-a253-68f81334ebc6

My notary service has been stuck for more than 5 hours. Is it because i am a new user or there is an notary service outage.

I want to help contribute a feature in a virtual-machine app in macOS that supports PCIe device passthrough over thunderbolt. I have a question about the entitlements. Since I do not represent the GPU vendors, would I be allowed to get a driver signed that matches GPU vendor IDs? Is there such a thing as wildcard entitlement for PCIDriverKit? I don't want end-users to have to disable SIP to be able to use this. Any suggestions/leads? Thank you.

I am building an electron app bundled with python. My code signing was fast, but when it came to notarization, it has already taken over 6+ hours. How can I speed things up?

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Put it in the Code Signing > General subtopic and tag it with relevant tags like Gatekeeper, Code Signing, and Notarization — so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing content in a bundle Embedding nonstandard code structures in a bundle Embedding a command-line tool in a sandboxed app Creating distribution-signed code for macOS Packaging Mac software for distribution Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. Later sections of this post address the most common ones. But first, let’s see if there’s an easy answer. Run a System Policy Check macOS has a syspolicy_check tool that can diagnose many common trusted execution issues. To check an app, run the distribution subcommand against it: % syspolicy_check distribution MyApp.app App passed all pre-distribution checks and is ready for distribution. If there’s a problem, the tool prints information about that problem. For example, here’s what you’ll see if you run it against an app that’s notarised but not stapled: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: MyApp.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error … Note In reality, stapling isn’t always required, so this error isn’t really Fatal (r. 151446728 ). For more about that, see The Pros and Cons of Stapling forums. And here’s what you’ll see if there’s a problem with the app’s code signature: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Codesign Error File: MyApp.app/Contents/Resources/added.txt Severity: Fatal Full Error: File added after outer app bundle was codesigned. Type: Notary Error … The syspolicy_check isn’t perfect. There are a few issues it can’t diagnose (r. 136954554, 151446550). However, it should always be your first step because, if it does work, it’ll save you a lot of time. Note syspolicy_check was introduced in macOS 14. If you’re seeing a problem on an older system, first check your app with syspolicy_check on macOS 14 or later. If you can’t run the syspolicy_check tool, or it doesn’t report anything actionable, continue your investigation using the instructions in the following sections. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code on systems prior to macOS 26 beta. macOS 26 beta supports arm64e apps directly. Prior to that, third-party products (except kernel extensions) were limited to arm64, except for the purposes of testing. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running App Store distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2025-08-06 Added the Run a System Policy Check section, which talks about the syspolicy_check tool (finally!). Clarified the discussion of arm64e. Made other editorial changes. 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

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.

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

Firstly - I didn't want to post here but my attempts at support call service and support submit issue service BOTH returned errors to me upon 'send'/'submit'. Maybe this is linked to my post below. So, here's another one to add to the list of recent (stuck/fail) posts: I'm unable to get any notarization submissions processed. Over the past 24 hours I've submitted 10+ builds of my macOS app and every submission remains at "In Progress" indefinitely — none have completed. To isolate the issue, I submitted a minimal test app (a single "Hello World" binary, ~50KB zip) using the same Developer ID certificate and API key credentials. That submission is also stuck at "In Progress," which suggests the issue is account-level rather than app-specific. What I've ruled out: Network issues (tested on multiple networks, all VPN/network extensions disabled) Authentication method (tested both app-specific password and App Store Connect API key) Code signing (signatures verify locally; one earlier submission did return "Invalid" with actionable errors, confirming the service can process my submissions) The Apple Developer System Status page shows all services as available. Could you please look into whether there's a processing issue or hold on my account's notarization queue? Submission IDs (all stuck at "In Progress"): 20e4c082-b682-4135-a85e-3f17280b0085 (minimal test app, 2026-04-23T07:03 UTC) 81835570-8a2c-462c-8d5a-bd25733a17c3 (2026-04-23T06:55 UTC) 5b7f337e-3e3f-4502-9fde-0a625a2061e7 (2026-04-23T03:38 UTC) bebe35f3-2944-40de-9caf-1c43b68986bb (2026-04-23 ~04:00 UTC) 3c010292-10d7-4cfc-80e3-8bdb4cdae669 (2026-04-23 ~04:30 UTC) a5ca8b1c-91c1-48db-a78a-9e4fd83fe27f (2026-04-23T03:38 UTC) 937f7a3c-435a-4b00-b5b5-7330b80855d4 (2026-04-23T01:59 UTC) 61af2ba4-f136-4993-a8fc-9cd18021fbb5 (2026-04-23T03:10 UTC) b1b7769a-9f1c-4d2b-b1f0-3224808cc901 (2026-04-23T00:12 UTC) 74653d5c-2edf-47b4-9cf3-1e8d33630f6b (2026-04-22T13:27 UTC) 961af655-30e3-44d3-a01b-1c69f5bccfa6 (2026-04-22T12:54 UTC) Thank you!

I will post my app xyz.app uses XY swift package this swift package is a wrapper for XYSDK.xcframework XYSDK.xcframework written in c++ and app running on arm64 macos and iphones succesfully. I got this error when i want to distribute it. Currently i sign .framework for ios with Apple Distribution Certificate and same certificate for macos framework there is no other signing step for swift package or xcframework other than that when i want to archive it validates succesfully. Exporting step shows that app has signed, has provisining profile. but .framework is only signed has no provisioning profile. Also one point i see: i have one target named xyz and its Frameworks, Lİbraries and Embedded Context has only XY package but Embed part has no option like embed and sign etc. Blank. I need more info about what am i doing wrong in which step ? I am stuck and can not move any further like weeks Error Detail: Invalid Signature. The binary with bundle identifier XYSDK at path “xyz.app/Frameworks/XYSDK.framework” contains an invalid signature. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose “Clean All” in Xcode, delete the “build” directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/support/code-signing. (90035)

Hello, when building and signing my application in a Github actions workflow, I am facing an issue on the latest version of xCode (16.4). This issue is resolved by downgrading to 16.3. My CI/CD pipeline is running headless and installing provisioning profile to ~/Library/MobileDevice/Provisioning Profiles.

Problem My ARM64 macOS application is being immediately killed with SIGKILL when launched. No crash report is generated, and the process terminates instantly. Environment macOS Version: 15.x (Sequoia) Architecture: ARM64 (Apple Silicon) Certificate: Mac Developer certificate (development signing) App Type: Native ARM64 application with embedded Java runtime Symptoms ./MacOS/myapp Immediately returns: zsh: killed ./MacOS/myapp Investigation Results System Logs Show Security Policy Rejection kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 92850, /path/to/myapp syspolicyd: (Security) MacOS error: -67062 Error Code Analysis Error -67062 = errSecCSReqFailed (Code signature requirement failed) This is a Gatekeeper enforcement issue, not a code signing problem 3. Code Signature is Valid codesign -dvvv myapp Shows valid signature with Mac Developer certificate Authority=Mac Developer: Name (TEAMID) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA What We Tried (That Didn't Help) ✅ Removed hardened runtime flag from Java components ✅ Added JIT entitlements (com.apple.security.cs.allow-jit) ✅ Verified Mach-O structure is correct ✅ Confirmed all libraries are ARM64 ✅ Re-signed with proper entitlements None of these fixed the issue because the problem is Gatekeeper policy enforcement. Question How can I allow this development-signed ARM64 app to run on macOS 15 without full notarization? I've tried: Removing quarantine attributes Various code signing approaches Different entitlements But Gatekeeper still blocks it with error -67062. Is there a way to add a security exception for development builds, or do I need to use a Developer ID certificate even for internal testing? Additional Context This is for internal development/testing. The app works fine when properly notarized, but we need a way to test development builds without going through the full notarization process each time. Any suggestions would be greatly appreciated!

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?

Hi everyone, After I recently changed my Apple ID (iCloud) password, my Developer ID certificate stopped working for signing macOS apps. Symptoms: Signing fails with the Developer ID certificate that was previously working fine. I tried re-downloading the certificate from my Apple Developer account and importing it into the Keychain, but the issue persists. It seems that the Developer ID identity is no longer trusted or properly linked to my system since the password change. Attempts: Re-downloaded and installed the certificate from the developer portal. Verified that the private key is present and linked. Checked keychain access and code-signing identity — everything appears normal, but the signed apps are rejected or the signing process fails. Blocking issue: I am unable to delete or revoke the Developer ID certificate on my account (Apple Support says it's not possible). Also, I can't create a new one due to the certificate limit. Questions: Is it expected for a Developer ID certificate to become invalid after changing the Apple ID password? Is there a recommended way to refresh or restore the certificate trust on macOS? How can I invalidate the current certificate and generate a new one if I'm stuck? Any insights or official guidance would be really appreciated. Thanks in advance!

I'm distributing a macOS .pkg installer signed with Developer ID Installer and notarized via notarytool. On macOS 26.3 (Tahoe, Build 25D125), the package is rejected by Gatekeeper when downloaded from the internet. What works: pkgutil --check-signature → signed, Developer ID Installer, full chain (G2 intermediate + Apple Root CA) xcrun stapler validate → "The validate action worked!" xcrun notarytool info <id> → status: Accepted The .app inside the .pkg passes spctl -a -vvv → "accepted, source=Notarized Developer ID" What fails: spctl -a -vvv --type install mypackage.pkg → rejected, origin=Developer ID Installer Raw assessment: assessment:remote = true, assessment:verdict = false Double-clicking the downloaded .pkg shows only "Move to Trash" / "Done" (no "Open" option) syspolicyd log: meetsDeveloperIDLegacyAllowedPolicy = 0 (expected, since the cert is new), but no "notarized" match is logged Certificate details: Developer ID Installer, issued Feb 28, 2026, valid until 2031 OID 1.2.840.113635.100.6.1.14 (Developer ID Installer) — critical OID 1.2.840.113635.100.6.1.33 — timestamp 20260215000000Z Intermediate: Developer ID Certification Authority G2 (OID 1.2.840.113635.100.6.2.6) security verify-cert → certificate verification successful Build process: productbuild --distribution ... --sign <SHA1> (also tried productsign) Both produce: Warning: unable to build chain to self-signed root xcrun notarytool submit → Accepted xcrun stapler staple → worked Workaround: xattr -d com.apple.quarantine ~/Downloads/mypackage.pkg allows opening the installer. Question: Is spctl --type install assessment expected to work differently on macOS 26 Tahoe? The same signing and notarization workflow produces .app bundles that pass Gatekeeper, but .pkg installers are rejected. Is there a new requirement for .pkg distribution on macOS 26? Environment: macOS 26.3 (25D125), Xcode CLT 26.3

*** Error: ERROR: [ContentDelivery.Uploader] Validation failed (409) Invalid Provisioning Profile. The provisioning profile included in the com.baiyun-shuniu.scss bundle [Payload/HBuilder.app] is invalid. [Missing code-signing certificate]. A distribution provisioning profile should be used when uploading apps to App Store Connect. (ID: e21c7a63-520f-49c5-8298-9afa3aa14dd5) 2025-05-13 09:23:20.382 INFO: [ContentDelivery.Uploader]

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?

Posting another data point in case it helps the team see the pattern. First-time notariser, Apple Developer Team ID Q9LV8L6XZ9. Four submissions (all Ping.zip, Electron app, arm64, hardened runtime, signed with Developer ID Application) submitted yesterday between 19:13 and 20:27 UTC. All still In Progress 19 hours later with no state change whatsoever. Submission IDs: 3861f4af-ec5e-47f9-93c7-d1583ba98863 c5b200a0-5c13-41cf-8376-83eab8d9afe4 cda1991e-1779-4d1d-9448-d464e64e930a 4f374650-4343-4aa8-8afe-03b150dd52b9 xcrun notarytool log <id> returns "Submission log is not yet available" for every one of them — so Apple hasn't produced any analysis output, successful or not. I appreciate that "in-depth analysis" can take longer for first-time uploads, but 19+ hours on four identical submissions with zero progress looks less like deep analysis and more like the jobs are stuck. Is there anything on the account/team-ID side that might be blocking them from entering the analysis pipeline? Happy to provide anything else that would help.

Hi, I have two xcrun notarytool submissions stuck in status: In Progress for over 60 hours. Hoping an Apple engineer can take a look, or confirm whether there is an ongoing notarization service incident. Submissions Submission A: 55c155c2-0df9-4157-b2c1-b3510c453b22 Submission B: 06926b24-3e76-4d14-b5f1-2083f0d9dae9 Team ID: 4CXZ4H3C2R Both submitted: 2026-04-21 Both still return status: In Progress at 60+ hours No result email received from Apple xcrun notarytool log <UUID> returns "The log is not yet available" Environment macOS 15 Sequoia Xcode 16.x command-line tools (notarytool 1.x) Developer ID Application certificate, SHA-1 70:86:EB:14:E4:C5:AA:71:2F:C5:3D:A4:3F:E8:79:DE:32:CE:B3:42, valid through 2031-04-20 Hardened Runtime enabled Standard notarization workflow from the same dev environment that has processed previous releases successfully Notarized artifact: single DMG, ~120 MB What I have already tried Apple Developer Support case #102874171230 — opened 2026-04-21. Rep replied 3x suggesting Forums + Feedback Assistant (hence this post). Feedback Assistant FB22576862 — filed 2026-04-22 under Developer Tools > App Notarization > Incorrect/Unexpected Behavior, with attached notarytool poll log showing sustained In Progress. Code-level support request (DTS) — form routes this class of issue out to these Forums (no submit path for notarization service queue issues). Reviewed other Forums threads on similar symptoms from March-April 2026 — multiple teams reporting the same pattern. Asking Can any Apple engineer cross-reference UUIDs A and B against the notarization backend queue state? Is there an ongoing service incident affecting these submissions? Is it safe to resubmit, or will that create duplicate queue entries? Thank you.