Submission UUID: 99192f0b-a0b2-488b-8443-6a6535c300b7 Created: 2026-07-31T09:18:41.522Z Team ID: FNUWX59L8T Artifact: Omitly_2.3.2-beta.2_aarch64.dmg Current status: In Progress (51+ hours) This submission has been In Progress continuously since it was created. I am not asking for it to be rushed — I would like to know whether it is genuinely still being processed, or whether it has failed in a way that will never reach a terminal state, because I cannot tell the difference from the client side and notarytool log is unavailable while it is pending. Before posting I ruled out the causes I could test myself. ┌──────────────────────┬──────────────────────┬─────────────────────┐ │ Created (UTC) │ Artifact │ Result │ ├──────────────────────┼──────────────────────┼─────────────────────┤ │ 2026-07-31T09:18:41Z │ Omitly_…_aarch64.dmg │ In Progress, 51h │ ├──────────────────────┼──────────────────────┼─────────────────────┤ │ 2026-07-31T12:22:38Z │ Probe.zip │ Accepted in ~55 min │ ├──────────────────────┼──────────────────────┼─────────────────────┤ │ 2026-08-02T10:32:37Z │ Probe2.zip │ Accepted in ~41 min │ └──────────────────────┴──────────────────────┴─────────────────────┘ Both probes were a minimal hello-world .app (single arm64 Mach-O, no dependencies), Developer ID signed with hardened runtime using the same identity and same API key. Both returned Accepted / "Ready for distribution" / issues: null. That establishes: the team is configured for notarization (not a 7000 case); certificate and key work end to end; submissions are not serialised behind the stuck one (Probe.zip was submitted three hours later and finished first); and it isn't a weekend effect (Probe2.zip went through on a Sunday morning Pacific in 41 minutes). About the stuck artifact: a Tauri 2 app, arm64, distributed as a DMG. CI verified before submission that the app and every nested Mach-O report Authority=Developer ID Application: with TeamIdentifier=FNUWX59L8T, and that the hardened runtime flag is set. The bundle embeds a qpdf sidecar plus three dylibs (libqpdf.30, libjpeg.8, libcrypto.3) copied from Homebrew, install names rewritten with install_name_tool, then re-signed as part of the bundle. It also ships compressed OCR model data. I appreciate that unfamiliar uploads can be held for additional analysis, and that this is more common for new accounts — this is a recently approved organisation and this was its first submission. My question is whether 51 hours is still within the expected range for that path, or whether this submission is stuck and should be resubmitted.

Since 2026-07-29 every notarization submission for my team (547L3Z8CNP) uploads fine, sits "In Progress" 24h+, then vanishes — notarytool info returns "Submission does not exist." None ever reach Accepted/Invalid. Last success 2026-07-27. Reproduces with a 5.85 KB Developer-ID-signed hello-world (hardened runtime + secure timestamp). codesign --verify --deep --strict is clean; auth works under both an app-specific password and an App Store Connect API key. Submission IDs: 17f9361a-e28d-4cc2-959f-2f3c7ba10325 — In Progress (07-30) f00de349-d449-4539-9d7d-82cac6ef04d7 — now "does not exist" (07-29) 17f1857a-fa44-430f-ad5b-cc42dcc41038 — now "does not exist" (07-29) 4af0cf5d-37e4-4d43-9edf-e78b8594d1db — 5.85 KB probe, In Progress Filed as FB24063069. Anyone else seeing this, or an engineer able to look?

Updating an App for the first time since 2011. Build, Analyze, Archive all successful. Automatically Manage Signing checked. Validation fails with 90286 - Invalid code signing entitlements, and 91130 - Invalid Provisioning Profile dozens of times after tweaks, clean builds, trying manual signing (thought I was done with that), etc. For 90286 it seems my Developer ID , e.g. 346JXXXXX (not Team ID, QZ99XXXXX) is the prefix for the bundle ID, com.company.app-name and that generates the error? For 91130 it's invalid "com.apple.application-identifier" which I assume is the same issue with a Developer ID instead of a Team ID. The original version of the app was QZ99XXXXX.com.company.app-name. I even changed the bundle identifier in Xcode to that, and got this: App Record Creation failed due to request containing an attribute already in use. The app name you entered is already being used for another app in your account. If you would like to use the name for this app you will need to submit an update to your other app to change the name, or remove it from App Store Connect. Yes, the original app name is being used for an app in my account. I was trying to update the app, checked all the boxes, added update text, but of course there was no build to upload. Would appreciate any help.

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

I have a paid Apple Developer account (Team CK4269T4Q4, renewed until 2027/7/10), but Xcode always generates development certificates under my free personal Team (CKY689QC8W) instead of the paid one. What I've tried: Deleted all certificates from Keychain → Xcode regenerates under CKY689QC8W Revoked all certificates on developer.apple.com → same result Manually created CSR + uploaded certificate → still CKY689QC8W Signed out/in of Xcode account → no change Clean build, deleted derived data → no change The problem: iOS 18.7 requires online verification for free Team certificates. The verification always fails with "需要互联网连接以验证是否信任开发者". The "VPN & Device Management" section on iPhone never shows the developer profile. Apple Support case: 102939216200 — they confirmed the certificate was created correctly under CK4269T4Q4, but referred me to technical support here. Has anyone encountered this? How can I force Xcode to use my paid Team for code signing?

I came across your contact on the Apple Developer Forums. I'm encountering an unusual issue during the notarization process. The error message states: "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions." Any guidance you could provide would be greatly appreciated. Here are the error details for reference: json { "logFormatVersion": 1, "jobId": "b6023a7c-dc85-4fa5-91dd-fba92c9ed831", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, "archiveFilename": "Bytemonk.dmg", "uploadDate": "2025-07-02T07:07:07.945Z", "sha256": "b9494170cc040a76045ed263de22e6b89a5455142af16ce502530e1c1ee72ddf", "ticketContents": null, "issues": null }

ID：f73305f0-c566-482d-ab2d-84082e9b8634 status: In Progress 详情：2026-07-24 ，应用签名 ->提交公证 -> 公证一直无法成功 In Progress，请帮忙检查并解决

All notarization submissions from our team are stuck at “In Progress”; none has reached a terminal state (neither Accepted nor Invalid). Environment • Team ID: F2Q623H7F9 • Developer ID Application certificate issued 2026-07-25 18:35 UTC. These are this team's first-ever notarization submissions — there is no prior successful notarization to compare with. • Auth: App Store Connect API key (.p8 + key ID + issuer ID), not an Apple ID password. • Submitted with • Payload: xcrun notarytool submit from GitHub-hosted macos-14 runners, not a local Mac, so a client-side upload crash is not a factor. ditto -c -k --keepParent zip of Mel.app, ~17 MB — a native Rust/egui desktop app. Not Electron; no accessibility APIs. Stuck submissions — all three still “In Progress”, confirmed via both xcrun notarytool info and independently via the Notary REST API ( GET /notary/v2/submissions/{id} ): 1. 8ad4dde0-06f1-43b5-acf4-2847b4cce10e — created 2026-07-25 21:39:24 UTC (oldest; 17+ hours elapsed) 2. 9d60e50e-474c-41f6-920d-1b4a1e1f57b4 — created 2026-07-26 10:24:32 UTC 3. cea068bb-6ffa-4a18-ba49-0dec625071ca — created 2026-07-26 11:25:48 UTC Every upload was accepted (“Successfully uploaded file”). None was rejected. xcrun notarytool log returns “Submission log is not yet available”, which we understand is expected for a non-terminalsubmission. Signing verified locally before each submission codesign --force --deep --timestamp --options runtime --entitlements /mel.entitlements --sign "Developer ID Application: … (F2Q623H7F9)" Mel.app codesign --verify --deep --strict --verbose=2 Mel.app → “Mel.app: valid on disk” and “Mel.app: satisfies its Designated Requirement”. Hardened runtime enabled; secure timestamp present. Service status — the Developer ID Notary Service has shown “Operational” on developer.apple.com/systemstatus for the entire window covering all three submissions. What we have deliberately not done — we have stopped resubmitting. We understand that re-uploading the same build only adds backlog for the service to grind through once the state clears, so we are holding at three submissions and polling instead of retrying. Request — we are not asking for a rejection reason; nothing has been rejected. We are reporting the UUIDs and creation dates as the guidance asks, so these can be distinguished from orphaned submissions that will never reach a terminal state. Question: Are a new team's first submissions subject to an extended review period, and if so what completion time should we expect for 8ad4dde0-06f1-43b5-acf4-2847b4cce10e?

The notary service requires that all Mach-O images be linked against the macOS 10.9 SDK or later. This isn’t an arbitrary limitation. The hardened runtime, another notarisation requirement, relies on code signing features that were introduced along with macOS 10.9 and it uses the SDK version to check for their presence. Specifically, it checks the SDK version using the sdk field in the LC_BUILD_VERSION Mach-O load command (or the older LC_VERSION_MIN_MACOSX command). There are three common symptoms of this problem: When notarising your product, the notary service rejects a Mach-O image with the error The binary uses an SDK older than the 10.9 SDK. When loading a dynamic library, the system fails with the error mapped file has no cdhash, completely unsigned?. When displaying the code signature of a library, codesign prints this warning: % codesign -d vvv /path/to/your.dylib … Library validation warning=OS X SDK version before 10.9 does not support Library Validation … If you see any of these errors, read on… The best way to avoid this problem is to rebuild your code with modern tools. However, in some cases that’s not possible. Imagine if your app relies on the closed source libDodo.dylib library. That library’s vendor went out of business 10 years ago, and so the library hasn’t been updated since then. Indeed, the library was linked against the macOS 10.6 SDK. What can you do? The first thing to do is come up with a medium-term plan for breaking your dependency on libDodo.dylib. Relying on an unmaintained library is not something that’s sustainable in the long term. The history of the Mac is one of architecture transitions — 68K to PowerPC to Intel, 32- to 64-bit, and so on — and this unmaintained library will make it much harder to deal with the next transition. IMPORTANT I wrote the above prior to the announcement of the latest Apple architecture transition, Apple silicon. When you update your product to a universal binary, you might as well fix this problem on the Intel side as well. Do not delay that any further: While Apple silicon Macs are currently able to run Intel code using Rosetta 2, that support is going away soon. About the Rosetta Translation Environment says: Rosetta … will be available through macOS 27 … Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles But what about the short term? Well, I’m glad you asked! Xcode includes a command-line tool, vtool, that can change the LC_BUILD_VERSION and LC_VERSION_MIN_MACOSX commands in a Mach-O. You can use this to change the sdk field of these commands, and thus make your Mach-O image ‘compatible’ with notarisation and the hardened runtime. Before doing this, consider these caveats: Any given Mach-O image has only a limited amount of space for load commands. When you use vtool to set or modify the SDK version, the Mach-O could run out of load command space. The tool will fail cleanly in this case but, if it that happens, this technique simply won’t work. Changing a Mach-O image’s load commands will break the seal on its code signature. If the image is signed, remove the signature before doing that. To do this run codesign with the --remove-signature argument. You must then re-sign the library as part of your normal development and distribution process. Remember that a Mach-O image might contain multiple architectures. All of the tools discussed here have an option to work with a specific architecture (usually -arch or --architecture). Keep in mind, however, that macOS 10.7 and later do not run on 32-bit Macs, so if your deployment target is 10.7 or later then it’s safe to drop any 32-bit code. If you’re dealing with a Mach-O image that includes 32-bit Intel code, or indeed PowerPC code, make your life simpler by removing it from the image. Use lipo for this; see its man page for details. It’s possible that changing a Mach-O image’s SDK version could break something. Indeed, many system components use the main executable’s SDK version as part of their backwards compatibility story. If you change a main executable’s SDK version, you might run into hard-to-debug compatibility problems. Test such a change extensively. It’s also possible, but much less likely, that changing the SDK version of a non-main executable Mach-O image might break something. Again, this is something you should test extensively. This list of caveats should make it clear that this is a technique of last resort. I strongly recommend that you build your code with modern tools, and work with your vendors to ensure that they do the same. Only use this technique as part of a short-term compatibility measure while you implement a proper solution in the medium term. For more details on vtool, read its man page. Also familiarise yourself with otool, and specifically the -l option which dumps a Mach-O image’s load commands. Read its man page for details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2026-07-24 — Updated to reference Apple’s publicly announced plans for Rosetta 2. 2025-04-03 — Added a discussion of common symptoms. Made other minor editorial changes. 2022-05-09 — Updated with a note about Apple silicon. 2020-09-11 — First posted.

This issue is happening from some time only on MacOS Big Sur (11.0 and 11.6 specifically) machines in our environment. Other higher OS versions or even lower versions like Mojave do not have this issue. I can confirm that earlier software version was working fine here. Could this be an issue with any recent changes in the code signature process? In the codes signature details below, I'm concerned about VersionSDK being 0 and RuntimeVersion property not being present, when comparing to working setups. Also, there is a warning about library validation. Could that be causing an issue? Kindly requesting for a resolution here. Crash report: Library not loaded: @executable_path/../<Masked>.dylib Referenced from: /opt/../<Masked> Reason: no suitable image found. Did find: /opt/..<Masked>.dylib: code signing blocked mmap() of '/opt/..<Masked>.dylib' Code signature details: codesign -dv --verbose=4 : Executable=/opt/...dylib Identifier=.dylib Format=Mach-O thin (arm64) CodeDirectory v=20200 size=11314 flags=0x10000(runtime) hashes=349+2 location=embedded Library validation warning=OS X SDK version before 10.9 does not support Library Validation VersionPlatform=1 VersionMin=721920 **VersionSDK=0 ** Hash type=sha256 size=32 CandidateCDHash CandidateCDHashFull Hash choices=sha256 CMSDigest= CMSDigestType=2 Page size=4096 CDHash= Signature size=8988 Authority=Developer ID Application: Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=26-Jun-2026 at 10:48:54 PM Info.plist=not bound TeamIdentifier= Sealed Resources=none Internal requirements count=1 size=180

All our workflows started to fail today due to timeouts - the notarization process is unable to finish in under 1 hour. The latest submission ID that failed after 45mins: 7449abcb-0d24-441b-a992-d5c7e7d279e3 It has never been a problem for us for the past years - is there something off on Apple side?

Hello, I'm trying to notarize my Electron macOS application using a valid Developer ID Application certificate. Environment: Apple Developer Program: Active Developer ID Application certificate: Successfully created App size: ~130 MB (ZIP) Using notarytool (via electron-builder / GitHub Actions) The submission was uploaded successfully, and I received a Submission ID. Submission ID: e48ead02-a837-42cd-9d90-c4c0f014e589 However, the notarization has remained in: Status: In Progress for more than 2 hours. Running both: xcrun notarytool info and xcrun notarytool history continues to report: Status: In Progress No notarization log is available yet. I have already contacted Apple Developer Support, but I wanted to ask the community: Is it normal for a notarization submission to remain "In Progress" for several hours? Has anyone experienced this recently and eventually received an "Accepted" status? Could this indicate a temporary Apple-side queue or backend issue? Any insight would be greatly appreciated. Thank you.

Our iOS app fails to install via Ad Hoc or Development distribution with error: 0xe8008018 (The identity used to sign the executable is no longer valid). Environment: macOS 15.6.1, Xcode 16.0 Team ID: 8CJTVD465A Tested on iPhone 8 (iOS 16.7 + iOS 16.2) What works: TestFlight ✅, App Store ✅ What fails: Ad Hoc ❌, Development ❌ Key evidence: OCSP returns "good" for all certificates Brand new certificate (created today) → same error Install succeeds in Airplane mode but app shows "not available" at launch 4 different certificates, 3 profiles, 2 Xcode versions, 2 devices → all fail codesign --verify passes locally Full cert chain verified: Leaf → WWDR G3 → Apple Root CA This indicates Apple's online verification service is rejecting our team's signatures. Has anyone seen this or know how to resolve?

Title: First notarization submissions stuck "In Progress" (new Developer ID account) Hello, Our first-ever notarization submissions are stuck at "In Progress": d1009b64-8c1c-4d78-bb18-f5b3f1135e72 — submitted 2026-07-21 08:54 UTC a5915e00-8f39-415d-a2de-945dedbbfa69 — the same file, resubmitted 2026-07-21 12:10 UTC Team ID: 9NAR899PX9 The file is a small (~5 MB) macOS utility (Klipto.zip). It passes strict codesign verification with a valid Developer ID Application certificate and hardened runtime enabled. These are the account's first submissions, so we understand extended analysis is expected — but could you please check whether they are held and help unblock them? Thank you! — Margarita at Klipto

Hi — I'm hoping someone from the Notary team can take a look. This is the FIRST notarization on a brand-new individual Developer ID account, and every submission has been stuck at "In Progress" for well over 40 hours. Normal submissions for me would be expected in minutes. Team ID: 4FT9BQJ765 Submissions (all still "In Progress" as of 2026-07-20 21:00 UTC): 08953b37-a6a7-43a3-bf76-0bb7d7450b10 (.dmg) submitted 2026-07-19 01:33 UTC (~43h) 3b1c0d76-11e9-4689-b699-e247b4659c5e (.zip) submitted 2026-07-19 01:09 UTC (~44h) 9025ba6f-0f7e-4137-888c-8ca4c7a2f42b (.zip) submitted 2026-07-18 22:44 UTC (~46h) What I've verified: My very first submission (9d595afa-5603-42b4-9ac9-0ea638c7eca0) returned "Invalid" within ~3 minutes with real signature errors (unsigned nested dylibs). I fixed those — signed every nested Mach-O inside-out with --options runtime --timestamp using my Developer ID Application cert — so the pipeline and my account clearly work. Since fixing the signature, every re-submission just hangs at "In Progress" and never completes (both .zip of the .app and a signed .dmg). Signature checks pass locally: codesign --verify --deep --strict is clean, hardened runtime is enabled, secure timestamp present, and the Developer ID Application cert is valid. The pattern matches other "first notarization on a new account stuck for 24-48h" reports here. Could someone please manually push these submissions through (or let me know if something on the account side needs attention)? Tools: notarytool (Xcode 26), macOS 25, Apple Silicon (arm64). Thanks very much.

I enrolled as an individual Apple Developer on 2026-07-18 (Team ID W6ZKZYL87M) and I'm setting up Developer ID notarization for a macOS app distributed outside the App Store (notarytool + Developer ID Application signing). My first notarization submissions have been stuck at status "In Progress" and have never completed: notarize.zip — submitted 2026-07-18 15:34 UTC — id 9787a18e-e4a7-44cc-abe4-94900f51d336 — still In Progress (~54h) probe.zip — submitted 2026-07-19 13:23 UTC — id 0f7db26d-5abb-468a-9ea5-1bec4f71e1cf — still In Progress (~33h) The second submission (probe.zip) is a trivial ~8 KB Mach-O, locally signed with hardened runtime + secure timestamp, submitted purely to isolate the variable — and it is stuck exactly like the real app. This strongly suggests an account-level hold rather than a problem with any particular package. What I've already verified: Developer ID Notary Service is green on the system status page; submissions enter the queue with no error (no 403 / 7000 / auth failure — I authenticate with an App Store Connect API key); I am NOT re-submitting in a loop; agreements look in order in App Store Connect. This matches the documented "in-depth analysis / notarization profile-building" behavior for newly enrolled accounts, but 50+ hours is past the typical 24-72h window, so I would appreciate a check on whether my account is pending notarization profile provisioning or team configuration. I have an open Developer Support ticket (case 102946182596) but am raising it here in case a DTS engineer can look at the account state. Team ID: W6ZKZYL87M

I have a Flutter project that uploads files in background mode, implemented as a plugin for the iOS part. It works fine in debug mode when running from Xcode, but no files are uploaded in release mode (installed via .ipa). I implemented functions such as BGAppRefreshTask and BGProcessingTask, and configured BGTaskSchedulerErrorCodeNotPermitted properly in Info.plist. I registered background tasks (processing and fetch), and BGTaskScheduler also works well. The issue is that it works fine in debug mode but not in release mode. Do I need to modify some settings in the .entitlements file or configure something else? Environment: macOS: Sequoia 15.7.7 Xcode: 26.3 Flutter SDK: 3.19.5

Team ID: Y6YAJ7YNT2 (Individual) App: Variable Visualizer (com.variablevisualizer.app) Signed with Developer ID Application (G2), Hardened Runtime enabled. Submitted via notarytool + App Store Connect API key. Three submissions all stuck In Progress with no logs: 2debeb8f-9a67-4bb6-9ec6-31f4245cb469 created 2026-07-18T08:55:40Z 6299bcc0-40ee-4e9a-95ec-993e2e01b726 created 2026-07-18T09:11:19Z 5fa55506-88c7-4f10-9f2e-0f288c2b3961 created 2026-07-18T14:47:07Z Stapler returns CloudKit Record not found (Error 65). Apple Developer Program License Agreement accepted. Developer system status normal. Also filed Developer Support case 102945911358. These are the first notarization submissions for this app/team. Can someone on the notarization side check whether these are held for first-time deep analysis, or whether the team needs configuration? Thank you.

Team ID: U4TKZ5TH92 (individual enrollment, first-ever submissions) Submissions (UTC): 2026-07-18 04:45:23 a186c59f-bf3b-4ac9-9780-248045a2eda9 Sentry-notarize.zip -> Invalid in ~5 minutes. Legitimate (unsigned nested binaries); fixed and verified with codesign before resubmitting. 2026-07-18 04:50:13 055e92dc-3a88-42bd-b2df-dc7c30c02443 Sentry-notarize.zip -> In Progress, 38+ hours, no log available 2026-07-18 22:34:41 7db6ada0-f3f8-4bf8-80e5-404e59425321 NotaryTest.zip (16 KB) -> In Progress, 19+ hours The third submission is a deliberate minimal reproducer: a copy of /bin/echo inside a bare .app, Developer-ID signed with --options runtime --timestamp, a single Mach-O, no nested code, 16 KB total. It has now been In Progress for over 19 hours. A package that small cannot plausibly require extended analysis, which points to an account/team-level issue rather than package content. Note the FIRST submission was processed and returned Invalid within about five minutes, so the notary service was working for this account earlier the same day. Something changed between 04:45 and 04:50 UTC. Environment: Developer ID Application certificate valid (verified via security find-identity, G2 intermediate installed), notarytool credentials validated successfully via store-credentials, Developer ID Notary Service shows Available on the system status page. One possibly relevant detail: I have a WITHDRAWN organization enrollment (9L795ANY7S) on the same Apple ID, withdrawn for a website-verification failure. Could that withdrawal affect notarization for my individual team U4TKZ5TH92? Could someone check the backend notary queue status for team U4TKZ5TH92? Support case 102943331355 is open but has so far been routed to enrollment rather than notarization.

I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated. Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours. Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions. This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case. Is this a known issue for new accounts, and is there a way to get these submissions looked at? Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).