I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

i'am still getting crash while testing dotnetmaui my app, here is my environment info and crash report @shanselman macOS Tahoe 26.5, macOS Rider 2026.1.2 dotnet workload list Workload version: 10.0.300.3 Installed Workload Id Manifest Version Installation Source ios 26.5.10284/10.0.100 SDK 10.0.300 maccatalyst 26.5.10284/10.0.100 SDK 10.0.300 maui-android 10.0.20/10.0.100 SDK 10.0.300 maui-ios 10.0.20/10.0.100 SDK 10.0.300 xcodebuild -version Xcode 26.5 Build version 17F42 crash-report.txt

Hello. I am developing our company's SDK for iOS as a third-party library. This SDK consists of a static library and header files wrapped within a framework (and wrapping the target-specific frameworks in xcframework). I understand that codesign is required even for static frameworks, is it correct? Should I update the distributed files when the certificate expires? Does this depend on whether it is static or dynamic? When is the signature verified?

Hi, I recently enrolled in the Apple Developer Program and I’m trying to notarize my first Developer ID apps for distribution outside the Mac App Store. All of my valid notarization submissions are stuck in “In Progress”. The oldest one has been stuck since 2026-06-03, and newer submissions are stuck too. None of the valid submissions have moved to Accepted or Invalid, and no log is available. Team ID: TP32Y96XC5 Feedback Assistant: FB22994785 https://feedbackassistant.apple.com/feedback/22994785 Oldest stuck submission: 07865316-b2e0-4529-9790-97a63746d9a9 Hello Developer ID Test.dmg Created: 2026-06-03T12:20:18.595Z Status: In Progress This also happens with other apps/artifacts, so it seems like it may be account-level or team-level rather than an issue with one specific build. Other stuck submissions include: f1574597-154e-4386-a0b1-5560a57dde9d Azad IDE.zip Created: 2026-06-03T23:40:55.335Z aab15661-a883-413a-8a5d-8c78d1d0dabb Azad IDE.zip Created: 2026-06-05T11:29:46.664Z df4bb6dd-38fc-4083-92fa-d0846037fd53 MyMacOSApp-0.1.1-Darwin.dmg Created: 2026-06-05T11:52:54.093Z 305d56b7-a66a-4881-b649-c8738e39f3f2 Azad IDE.zip Created: 2026-06-08T10:58:24.724Z 1947d3c3-fc84-4479-9bee-355c16d51670 Azad IDE.zip Created: 2026-06-08T11:19:58.848Z What I checked: Developer ID certificate is installed and valid. The apps are signed with Developer ID Application: Matan Nahmani (TP32Y96XC5). codesign verification passes locally. Hardened runtime is enabled. notarytool authentication works. notarytool history/info works. notarytool log says the submission log is not yet available for the stuck submissions. I have not received a rejection email for the stuck submissions. Apple Developer System Status shows the notary service as available. Note: I do have one Invalid submission, but that one was intentional. I created it as a negative-control test while following a notarytool tutorial, to confirm that invalid submissions can produce a terminal status. The issue is that all valid Developer ID submissions remain stuck in In Progress. I understand that first-time notarization can take longer because of deeper analysis, but this has now been several days and every valid submission is still pending. Could someone from Apple DTS or the notarization team check whether Team ID TP32Y96XC5 is stuck in the first-time review/notarization queue? Thanks.

I work for a company which develops as part of our product suite a System Extension implementing an Endpoint Security client. Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds in to a VM, where to get the System Extension to load and be accepted we need to disable SIP & AMFI. macOS 27 VM is refusing to allow me to disable SIP. Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioningprofile) developer certificate for local validation?