Hi, I have two notarization submissions stuck "In Progress" for over 18 hours. This is my first time notarizing on this Developer ID account. Submission 1: c1ae7112-79d9-4ada-92a8-bcf87930b5a3 (submitted ~24 hours ago) Submission 2: e201629a-35ef-48a9-b6c4-efbdeecee839 (submitted ~12 hours ago) Team ID: PH4PLAN782 Bundle ID: com.SoundHawkStudio.ComboDyn Type: macOS Audio Unit plugin (.component), universal binary (x86_64 + arm64), Developer ID Application signed, hardened runtime enabled. I have also filed support case 102876329587. Both submissions remain In Progress with no transition to Accepted or Invalid. Any assistance would be greatly appreciated.

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.

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!

Hey everyone, Just enrolled in the Apple Developer Program yesterday and tried to notarize my first macOS app. I submitted via notarytool and the submission has been sitting at "In Progress" for over 22 hours now. I've submitted twice and both are stuck. The app is a macOS utility built with PyInstaller. I signed it with my Developer ID Application cert, enabled hardened runtime, added a secure timestamp, and included the appropriate entitlements. Everything looked fine on my end. When I query with notarytool info it just says status: In Progress. No rejection email, no acceptance email, nothing. Is this a known issue for first-time submissions? Or is there something specific about PyInstaller apps that causes this? Submission IDs if anyone from Apple is reading this: b512bd92-7eca-4975-823e-9561d5c2ad63 f90cd69f-cf36-4762-bcda-0d0b047d5f49 Already filed a support ticket but wanted to check here too.

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.

Hi all, and particularly @Eskimo if you spot this — I believe I'm reproducing the backend issuance bug reported in thread 816377 (https://developer.apple.com/forums/thread/816377) on a different Team ID and would like a second pair of eyes before I burn a TSI. Feedback Assistant filed as FB22582333. Team ID: MCN4U9B2K4 · Bundle ID: com.michaeltocco.Sanbox · Xcode 17 · iOS 18.5 · Automatic signing Setup App ID com.michaeltocco.Sanbox has ShazamKit ticked in App Services; persists through portal reloads. Local entitlements file declares com.apple.developer.shazamkit = YES only (no MusicKit client entitlement, per DTS guidance in thread 799000: https://developer.apple.com/forums/thread/799000). CODE_SIGN_ENTITLEMENTS set in both Debug and Release XCBuildConfiguration buildSettings. NSMicrophoneUsageDescription and NSAppleMusicUsageDescription are both present in the generated Info.plist. What Xcode reports After wiping DerivedData and any Sanbox-matching profiles and running xcodebuild … -allowProvisioningUpdates -destination 'generic/platform=iOS': error: Entitlement com.apple.developer.shazamkit not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. (in target 'Sanbox' from project 'Sanbox') What I verified on the profile Apple just issued $ security cms -D -i 0596f302-….mobileprovision | plutil -extract Entitlements xml1 -o - - shows only the baseline four entitlements — application-identifier, keychain-access-groups, get-task-allow, com.apple.developer.team-identifier. com.apple.developer.shazamkit is absent, which is exactly what thread 816377 describes. What I've already tried Deleted and recreated the App ID from scratch — same symptom. Performed the capability-toggle trick (uncheck ShazamKit → Save → wait 60s → re-check → Save → delete local profiles → rebuild) documented in the "Capability & entitlement updates" help page (https://developer.apple.com/help/account/reference/capability-entitlement-updates/) for the Game Center precedent — same symptom. Confirmed I am building for device, not Simulator. Confirmed the entitlement key name matches DTS guidance in thread 799000 and the live profile dumps in thread 816377. Runtime confirmation When I force a build with only the team wildcard profile, SHManagedSession().result() returns com.apple.ShazamKit Code=202 "Missing entitlements", wrapping an AMS 306 wrapping HTTP 401 from api.shazam.apple.com/v1/catalog/US/match. AMS server correlation key: E5VYL5YSUT4L55KQDDP4MJQAZE. So the server side is consistent: the token the client presents lacks ShazamKit scope because the binary doesn't carry the entitlement, and the binary doesn't carry it because Apple isn't issuing it into the profile. Question Is there a configuration step beyond "tick ShazamKit in App Services" that I've missed for Individual-program accounts, or is this the same backend issuance pathology as thread 816377? Happy to share the security cms output, the decoded plist, the build log, or anything else useful. Thanks.

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.

Hello, I'm submitting my first macOS app for notarization from a new Developer ID team. All three submissions have been stuck at "In Progress" for several hours now. notarytool log returns "Submission log is not yet available" for all of them. Submission IDs: 39856e43-46ee-45ed-b1c7-771fb6603258 (submitted 2026-04-18T10:00 UTC) 3edf2f4f-cbaf-4e14-ba3b-c1b4e111827e (submitted 2026-04-18T10:03 UTC) 858c52e7-3386-41a8-8fee-a31c49980319 (submitted 2026-04-18T10:25 UTC) Details: This is the first notarization attempt for this Developer ID team App is signed with Developer ID Application certificate, hardened runtime enabled codesign --verify --deep --strict passes All nested code (including Sparkle framework helpers) is properly signed Only public system frameworks are linked (IOKit, AppKit, Foundation, etc.) Entitlements: app-sandbox + Sparkle mach-lookup exceptions only No private API usage Is this expected for first-time submissions, or could someone check the backend queue status for these submissions? Any guidance appreciated.

Hi everyone, I'm developing a macOS app using Tauri 2. I need to test In-App Purchases (IAP), which requires running the actual built .app (it doesn't work properly in the development environment).I tried two approaches: Apple Development Certificate (free account): After cargo tauri build, the app "Mind Elixir.app" shows this error when I try to open it: “Mind Elixir.app” was not opened because it contains malware. This action did not harm your Mac. Apple Distribution Certificate: The app builds successfully, but because it is not notarized, Gatekeeper completely blocks it and I cannot open it at all. I just want to test IAP locally on my own Mac during development. Is there any other way to get a properly signed and runnable .app for testing IAP? Any help or workaround would be greatly appreciated. Thanks!

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?

Hello! We built a macOS .pkg using pkgbuild (contains a DMG + postinstall bash script). The pkg works locally on the build machine but fails on other devices manually / via MDM unless signed. We tried signing with a Developer ID Installer certificate, but: security find-identity -p codesigning -v → 0 valid identities security find-identity -v → shows the cert Private key is present in Keychain OpenSSL check shows: X509v3 Extended Key Usage: Critical (Expected one might be: Code Signing) We recreated CSR + cert multiple times (G2 Sub-CA), ensured Login keychain, unlocked keychain, etc., but same result. Question: Why is the Developer ID Installer cert missing Code Signing usage and not recognized for signing? Is there any account restriction or step we might be missing? Any recommendations on resolving this issue. Thanks!

I've successfully signed Unix apps manually in the past. Today (after signing the new agreement) I can get it to replace the existing signature but it says "rejected" when I check it. Here are the commands I'm using: michaelleahy@Michaels-Mini ~ % sudo codesign --force --deep --options runtime --sign "Developer ID Application: Bookup Corp. (6J8PUT****)” /Users/michaelleahy/Documents/theapp /Users/michaelleahy/Documents/theapp: replacing existing signature michaelleahy@Michaels-Mini ~ % spctl -a -vvvv -t install /Users/michaelleahy/Documents/theapp /Users/michaelleahy/Documents/theapp: rejected source=Unnotarized Developer ID origin=Developer ID Application: Bookup Corp. (6J8PUT****) Here is a command (issued right after the one above) showing an older signed app is accepted: michaelleahy@Michaels-Mini ~ % spctl -a -vvvv -t install /Users/michaelleahy/Documents/olderapp /Users/michaelleahy/Documents/olderapp: accepted source=Notarized Developer ID origin=Developer ID Application: Bookup Corp. (6J8PUT****) What might I be missing? Something changed since the last time I signed an app.

This is my first time submitting an app for notarization. Both submissions have been stuck "In Progress" with no logs available. Body: This is my first time submitting an app for notarization. Both submissions have been stuck "In Progress" with no logs available. Submission 1: ID: 43ea68c1-5291-42c6-b0e1-3cacab4ca01a Submitted: 2026-04-09T02:05:34Z Status: In Progress (15+ hours) Submission 2: ID: 12ea49a0-64cf-495e-af7e-9aad5aabe30f Submitted: 2026-04-09T17:06:51Z Status: In Progress (1+ hour) Details: Team ID: PWTWN9N25D App: Native macOS SwiftUI app (arm64), ~84 MB zipped Signed with Developer ID Application certificate, Hardened Runtime enabled All embedded helper binaries individually codesigned with Hardened Runtime codesign --verify --deep --strict passes Submitted via xcrun notarytool submit with --keychain-profile notarytool log returns "not yet available" for both Apple System Status shows all services available

Hi, All notarization submissions for our new Electron macOS app have been stuck in "In Progress" for over 24 hours, with no logs available. Environment: Team ID: T7632V8V2D Certificate: Developer ID Application (valid, identity 83AC47F44D984509D5530439DD32729076B84982) Tool: xcrun notarytool submit (Xcode CLI) App: Electron 33, signed with hardened runtime, entitlements include allow-jit and allow-unsigned-executable-memory File: zip of .app (~236MB for arm64, ~104MB for x64) codesign --verify --deep --strict passes with no issues Apple System Status shows "Developer ID Notary Service: Available" Stuck submissions (all "In Progress", no logs available): ea0fd8d4-1f2d-4266-aa84-aa3f3ba9a8fb (Apr 8, 09:40 UTC) dfaacdd2-1a11-4844-b8b7-b07bae809a7b (Apr 7, 16:49 UTC) 8256e1f0-e501-4423-8744-35b5b78ec87f (Apr 7, 10:32 UTC) a477d536-d84a-4c25-99ca-d125e0a22de1 (Apr 7, 09:07 UTC) This is our first time notarizing any app on this developer account. We understand first-time submissions may be routed to in-depth analysis, but 24+ hours with no progress on any of the 4 submissions seems unusual. Could someone from Apple check our team's queue status? Any guidance would be appreciated. Thank you.

Our team (AI Eesti OU, Team ID: W4WXCM4DLL) submitted our first app for notarization and both submissions have been stuck "In Progress" for over 20 hours. Submission IDs: 7433a69a-af1a-463a-a9fc-c80526eb6eab (submitted 2026-04-06 19:11 UTC) d033e2f1-9b33-4b7d-8f8d-271c99f1c61c (submitted 2026-04-06 21:03 UTC) The app is signed with Developer ID Application, hardened runtime enabled, and codesign --verify --deep --strict passes. This is our first notarization submission as a new team. Is this expected for first-time submissions, or is something stuck?

Hi, I’ve been successfully using notarization with notarytool for over a month (20+ submissions, all accepted within minutes). On April 4th around 07:30 (UTC), my last submissions were accepted without any issue: createdDate: 2026-04-04T07:29:08.877Z id: 38d6e6e0-1183-4fe8-ae4a-3036e1f0f025 name: MacOptimizers.dmg status: Accepted -------------------------------------------- createdDate: 2026-04-04T07:26:36.357Z id: 2abf8289-6e00-4b16-9991-fbda7e66a179 name: macopt_notary_payload.UdtfA3 status: Accepted -------------------------------------------- Later that same day (around 16:30 UTC), after minor bug fixes and UI changes, I submitted a new build. Since then, all notarization requests remain stuck in “In Progress” for more than 48 hours: -------------------------------------------- createdDate: 2026-04-05T07:13:03.369Z id: b4872e7a-e2b5-485e-9223-09f3ed94958f name: macopt_notary_payload.mZls1y status: In Progress -------------------------------------------- createdDate: 2026-04-04T20:07:35.937Z id: 375408f2-3c0a-455e-88a1-9cd08ce7dc35 name: macopt_notary_payload.CvrZNt status: In Progress -------------------------------------------- createdDate: 2026-04-04T17:09:47.481Z id: dad888b3-6aff-4c54-9608-da1f86e44db7 name: macopt_notary_payload.IH0RDr status: In Progress -------------------------------------------- createdDate: 2026-04-04T16:28:03.086Z id: 9e129b21-e682-48ce-baa7-8d2d77051bac name: macopt_notary_payload.GsrSa6 status: In Progress No errors are returned, and notarytool log is not yet available. Is this expected behavior (e.g. extended review), or could there be an issue affecting notarization for my team? Thanks for your help.

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

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?

Hi, I'm notarizing my Electron macOS app (DMG) for the first time with our new Developer ID, and most submissions have been stuck in "In Progress" for over 24 hours. Environment: Team ID: BSS9KAH6Z2 Certificate: Developer ID Application (valid until 2031) Tool: xcrun notarytool submit (Xcode CLI) App: Electron 28, signed with hardened runtime File: DMG (~131MB), 104 files inside .app What happened: Total 19 submissions over the past 24 hours Only 4 were Accepted (2 DMGs + 2 zips) The other 15 are still "In Progress" with no log available The 4 Accepted ones took 1~1.5 hours each codesign --verify --deep --strict passes with no issues Accepted submission log shows "issues": null Apple System Status shows "Developer ID Notary Service: Available" What I've tried: Submitting as DMG directly Submitting as ditto zip of .app Submitting via electron-builder's built-in notarize Using both app-specific password and keychain profile auth Verified entitlements (allow-jit, disable-library-validation) Since some submissions did get Accepted, I don't think there's an issue with my signing or configuration. Is this expected for first-time submissions from a new team? Is there anything on Apple's side that needs to be configured for my team? Any help would be appreciated. Thank you.

Hi, I’m hoping someone can help clarify the correct entitlement format for the Enhanced Security capability in a macOS App Store build. Context Our app is a sandboxed macOS app built with Xcode 26.4. We enabled the Enhanced Security capability in Signing & Capabilities, and we configured the entitlements based on the current documentation. What’s confusing me The Xcode 26.4 release notes say apps that already adopted Enhanced Security should remove: com.apple.security.hardened-process.enhanced-security-version com.apple.security.hardened-process.platform-restrictions and replace them with: com.apple.security.hardened-process.enhanced-security-version-string with value 1 com.apple.security.hardened-process.platform-restrictions-string with value 2 Reference: https://developer.apple.com/documentation/xcode-release-notes/xcode-26_4-release-notes The entitlement reference pages also seem consistent with that: https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.enhanced-security-version-string https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.platform-restrictions-string So our app currently uses the new -string entitlements with values "1" and "2". Our App Review rejection said: The app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Entitlement "com.apple.security.hardened-process.enhanced-security-version-string" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions-string" value must be boolean and true. That’s the part I can’t reconcile with the documentation. Questions For a Mac App Store submission built with Xcode 26.4, should these two entitlements use the new string-based form, or Boolean true? If the expected format has changed, is there any updated guidance beyond the Xcode 26.4 release notes and current entitlement reference? If Apple staff or anyone familiar with this can clarify what format is currently expected, I’d really appreciate it. Thanks.