General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums post If your notary requests are stuck in the In Progress state, see my reply here. If your notary requests are failing with Team is not yet configured for notarization, see my reply here and also the follow-up here. Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

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

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

Two Developer ID submissions for the same app have been stuck in In Progress with no resolution one for 20+ hours, a second for 2+ hours. Neither has ever transitioned to Accepted/Invalid, and notarytool log reports the log is not yet available for either. Apple's System Status shows Developer ID Notary Service as operational. Signing is verified correct (Developer ID Application, full chain, hardened runtime, secure timestamp details below), so I don't believe this is a client-side configuration issue. This is a newly enrolled account, Is this a known issue for new accounts, and is there a way to get these submissions looked at? Is there a known server-side backlog / in-depth-analysis hold affecting Developer ID notarization right now? Is it expected that a large, first-time app can sit in In Progress for 20+ hours with no log generated? Does submitting a second time (rather than waiting on the first) create an independent in-depth-analysis job and make things worse? Should I stop resubmitting and wait on the oldest one? Submission IDs and Team ID (982R8LP4Q7) above. Happy to provide more detail. Thanks.

Every notarytool submit from my team is rejected with: "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support…", "statusCode": 7000 This has persisted for 10+ days across many submissions (most recent job ID 00042820-f5d8-4c6b-a178-9b98d247170d, 2026-07-09). I distribute a macOS app outside the Mac App Store via Developer ID, so there is intentionally no App Store Connect app record. Everything on my side is verified correct: Apple Developer Program membership is active (Individual), team ID 5JDP238JFX. Valid Developer ID Application certificate; codesign --verify --strict passes with hardened runtime + secure timestamp; the signature chains cleanly to Apple Root CA. notarytool authenticates successfully — notarytool history returns my submission list — so credentials and team are correct; only notarization eligibility appears not to be enabled. I've signed in as Account Holder and see no pending agreements to accept. (← edit this line to match what you actually find — see note below.) My trader information was recently approved (received Apple's confirmation email). I've filed a Developer Program Support request but have had no response in over a week. The statusSummary reads like a team-level provisioning flag that hasn't been enabled. Ask: Can a DTS/forums engineer help get the notary service provisioned/enabled for team 5JDP238JFX, or point me to what account-side step is still outstanding? Happy to provide additional submission IDs or logs.

We have been using notarization for a long time without failure. Today, we are trying to do a release and we are getting this failure: 13:11:30 Conducting pre-submission checks for Dictionary-App-Builder-14.3-amd64.dmg and initiating connection to the Apple notary service... 13:11:31 Submission ID received 13:11:31 id: d7aeafcd-3ad8-459a-b46f-26eea6a50dff 13:13:32 Error: abortedUpload(resumeRequest: SotoS3.S3.ResumeMultipartUploadRequest(uploadRequest: SotoS3.S3.CreateMultipartUploadRequest(acl: nil, bucket: "notary-submissions-prod", bucketKeyEnabled: nil, cacheControl: nil, contentDisposition: nil, contentEncoding: nil, contentLanguage: nil, contentType: nil, 13:13:32 expectedBucketOwner: nil, _expires: SotoCore.OptionalCustomCoding<SotoCore.HTTPHeaderDateCoder>(value: nil), grantFullControl: nil, grantRead: nil, grantReadACP: nil, grantWriteACP: nil, key: "prod/AROARQRX7CZS3PRF6ZA5L:d7aeafcd-3ad8-459a-b46f-26eea6a50dff", metadata: nil, objectLockLegalHoldStatus: nil, objectLockMode: nil, _objectLockRetainUntilDate: SotoCore.OptionalCustomCoding<SotoCore.ISO8601DateCoder>(value: nil), requestPayer: nil, serverSideEncryption: nil, sSECustomerAlgorithm: nil, sSECustomerKey: nil, sSECustomerKeyMD5: nil, sSEKMSEncryptionContext: nil, sSEKMSKeyId: nil, storageClass: nil, tagging: nil, websiteRedirectLocation: nil), uploadId: "FpPG5uT2KfARISbYk2HKKB6iMm2dy5KeveNbOmIAoU0hCStokISxOS9.EG8.UXWLe.z8cC_X4kt2u0181.xJGA68EIkbSGq_jErYizapfmQNhTHmadbdSCgC8ErQL7jZcBdZGcGDYTgUbvUE3WYMzN.4AXgVGgUAxEV5idGoBBg.5t1.ZG.CHEFSvJJ3HH4G", completedParts: [SotoS3.S3.CompletedPart(eTag: Optional(""ac99c7fbb27adc503e084c6e06996576""), partNumber: Optional(1)), SotoS3.S3.CompletedPart(eTag: Optional(""97177a00dc53964afaa32172adb7de85""), partNumber: Optional(2))]), error: The operation couldn’t be completed. (Network.NWError error 54 - Connection reset by peer))

Hi — multiple notarytool submissions from my account have been stuck "In Progress" for 60+ hours and never reach Accepted/Invalid. Apple's Developer System Status shows "Developer ID Notary Service" as operational, so this appears to be a backend/account processing stall rather than a public outage. This is blocking a product launch. Team ID: Q7FF775479 ("Developer ID Application: JUNSEN LIU", individual account). Submissions (all still In Progress): e9d00de6-074c-4818-a452-f765fa178a4e — 2026-06-19 06:07 UTC (current build) f02a0398-b6db-4ba0-8429-86a797bdc153 — 2026-06-18 23:21 UTC 8aa72d28-642a-466a-be85-181db125596b — 2026-06-18 04:40 UTC App: "Dollar Desktop Pet" 1.0.0 — a signed .dmg of a hardened-runtime, Developer ID-signed Universal (arm64 + x86_64) Electron app. Tooling: notarytool 1.1.2, Xcode 26.5, macOS 26.5. notarytool submit/history/info all work and list the submissions; status simply never completes, and notarytool log returns nothing. Could you please investigate why these aren't processing? I can provide the .dmg or any additional logs. Thank you.

Hello Apple Developer Support, I need help with several macOS notarization submissions for my app "Dollar Desktop Pet" 1.0.0. Team ID: Q7FF775479 Developer ID: Developer ID Application: JUNSEN LIU (Q7FF775479) Bundle ID: com.dollar.desktoppet App type: Universal Electron macOS app, Developer ID signed, hardened runtime enabled Update as of 2026-07-05T21:23Z: The same keychain profile still works for a control/probe submission: 626063b7-643e-4b3d-aeb0-430532fa4ca9 Name: DollarNotaryProbe.zip Created: 2026-07-01T04:58:19.608Z Status: Accepted However, xcrun notarytool history --keychain-profile dollar-notary now only returns that probe submission. It no longer lists any Dollar Desktop Pet submissions. When queried directly, these Dollar submission IDs now return: "Submission does not exist or does not belong to your team." Affected submission IDs: 4e3c96b2-19fc-4b8b-844e-c95ca9242f11 Signed DMG submitted 2026-07-04T02:31:10.690Z 26f558b5-ea70-4196-8923-a77beb9fdc70 App-only ZIP submitted 2026-07-04T02:39:21.525Z f36faef2-14b8-4edb-b7e5-5db1bd3e1e17 Older DMG submitted 2026-06-26T22:28:21.305Z Local verification: The signed DMG verifies locally with Developer ID and timestamp. The app bundle verifies with: codesign --verify --deep --strict --verbose=4 The app is universal, hardened runtime, and uses Electron-standard entitlements. The local signed DMG still has no stapled ticket. Gatekeeper still rejects it only as: source=Unnotarized Developer ID origin=Developer ID Application: JUNSEN LIU (Q7FF775479) This is not an Accepted or Invalid result. It looks like the Dollar submissions either disappeared from the team view or are in a backend state that notarytool can no longer address, while the same profile can still read the accepted probe submission. Can Apple confirm what happened to these submission IDs, and whether I should wait, resubmit, or change packaging? Thank you.

Hello, I recently enrolled in the Apple Developer Program (Program License Agreement accepted 2026-07-03) and this is my first-ever notarization. All submissions have been stuck at status "In Progress" for over 48 hours and never reach Accepted or Invalid. "xcrun notarytool log" returns "Submission log is not yet available". I have verified everything on my side is correct: Signed with Developer ID Application (Team ID AXGBW2496Q) Hardened runtime enabled (flags=0x10000 runtime) Secure timestamp present codesign --verify --deep --strict passes ("satisfies its Designated Requirement") No get-task-allow entitlement notarytool credentials validate successfully All account agreements are accepted; none pending Could you please look into why these submissions are not completing? Team ID: AXGBW2496Q Submission IDs (all stuck In Progress): 3667a654-bd7e-40a9-927c-c919875aaf61 ffd1fcbf-ebf4-47cb-9a15-29731f973a86 98082a85-19d4-4efe-8119-36400dd1560c The app is a small (~360 KB) macOS utility. Thank you for any help.

Hi Apple Developer Support, My Developer ID notarization submissions are stuck in “In Progress” for over 24 hours with no terminal state. Team ID: KYM5Q9Y394 Stuck submissions: e3bedb66-3821-4737-8e9c-c1620e06ffea (2026-06-30T10:54:50.954Z) 5127868d-1953-4ab1-9be7-f26fc14804d9 (2026-06-30T10:45:54.870Z) 830069c1-037f-4bd8-a79a-0f445839603c (2026-06-30T10:38:54.060Z) All were uploaded via notarytool and remain “In Progress”. Codesign verification passes locally, and earlier submissions were accepted (e.g. 6e1617c3-b612-4fce-9165-286c71dce56d). Could you please check whether these submissions are stuck in backend processing and advise next steps? Thank you.

submission ID (e3bedb66-3821-4737-8e9c-c1620e06ffea) and createdDate (2026-06-30T10:54:50.954Z)

Hi — I'm trying to notarize a Developer ID–signed macOS app (a small menu-bar .dmg, ~1.4 MB) and every submission has been stuck at status: In Progress for 7+ hours without ever reaching Accepted or Invalid. The Developer System Status page shows the Notary Service as green/operational. This is a recently enrolled account (Individual) and these are its first notarization submissions, so I suspect a first-time-on-new-account hang, but wanted to get it looked at. Team ID: C4GLRN98Q7 Submission IDs (all still In Progress): a206d94b-c0e7-4901-a35e-daaf69c8ec65 — created 2026-06-25 19:02 UTC (oldest, ~7h+) 71d08fb3-0ae0-413a-8004-e3fb99721403 — 2026-06-25 19:32 UTC a6687302-d7b2-43be-8098-1442f0b1d4ab — 2026-06-25 19:45 UTC a8428002-0cd0-4d46-bc6d-8e95b9df409b — 2026-06-25 19:58 UTC cb8602bf-386e-4d98-9d1a-ad7e5308e629 — 2026-06-26 02:16 UTC (newest) What I'm doing: Signing with codesign --options runtime --timestamp using a Developer ID Application cert, then submitting the .dmg with xcrun notarytool submit … --keychain-profile … --wait. codesign --verify --strict passes locally. xcrun notarytool info returns valid submission metadata, just perpetually In Progress. The very first --wait died on a local network drop, but the submission had already uploaded 100% and kept processing server-side; I have not been spamming — the repeats above were a handful of retries before I realized they were all hanging. I've stopped submitting new ones. Could someone check why these submissions aren't completing? Happy to provide a notarytool log once any of them finishes. Thanks!

Hi. How can I change to an Individual Membership? Or when the time comes to notarize the app I will distribute from my website can I do that as an individual?

I'm hitting what looks like the same service-side notarisation issue reported recently (e.g. the "submissions stuck In Progress for days" thread / FB22939442), and would appreciate having my submissions looked at on the backend. Since 2026-06-25 ~12:00 UTC, every notarytool submission from my team goes to "In Progress" and never reaches a terminal state — no Accepted, no Invalid, no log (Submission log is not yet available, though info resolves the ID fine). The oldest is ~15 hours. Signing checks out: codesign --verify --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, Developer ID Application. My builds notarised normally yesterday (e.g. 1ad9878b, Accepted 2026-06-24) — but those were on my previous Developer ID certificate. That cert's private key was lost (orphaned login keychain after a reboot), so I re-issued the Developer ID cert on 2026-06-25, and every submission on the new cert has been stuck since. Key data point: a trivial 5.8 KB signed "hello world" CLI binary (8c138308 below) also hangs "In Progress", so this is account/team-level, not app content. This lines up with the new-Developer-ID evaluation described in the Notarisation Resources Q&A, but several of mine are now past the usual window. Team: Creative Machines Limited (V95N2B8X7A) Feedback: FB23407538 Stuck submission UUIDs (oldest first): ef4af6d3-5750-4213-a108-584c75a861cc – 2026-06-25 ~11:59 UTC (oldest) 2d435abc-af77-4447-b2c8-94572b723f34 404a7d9d-9713-42df-99b6-1f144bc27ba1 8c138308-f23f-4df1-85f9-29095587f42b – the 5.8 KB hello-world This is the only blocker before I can distribute. Is there any way to get these specific IDs cross-referenced against the notary backend queue? Happy to share signed artifacts or the full notarytool poll log. Environment: macOS 26.4.1 (25E253), Xcode 26.5, notarytool 1.1.2 (41).

Hi, I am trying to build an installer package of an usual(?) format: it contains a binary that I am developing code signing and notarization is straightforward here. it contains a 3rd-party binary that is open source, code signed and notarized by this third party code signing and notarization is also straightforward here as it's already been done. it also contains a 3rd-party binary that is also open source, however, it is not code signed or notarized This last one is the subject of my question. It is a well-established project with thousands of stars on GitHub, however their own "installation method" is a shell script that downloads the binary, checks its checksum and just places it in the right location. When building an installer package (it's an installer package of these three binaries packaged - productbuild with --distribution flag) this binary needs to be code signed and notarized for Developer ID distribution. I trust this binary, however the chance of supply chain attacks is never zero. My questions are: How can I shield myself best against accidentally submitting a malicious version of this third binary via notarytool to Apple? Should I separately submit versions of this binary for notarization from submitting new versions of my app? This binary is bound to change way less frequently than the app I'm actually developing. I really don't want to risk termination of my Apple Developer account because it has many high-value applications available. I am doing some basics - matching the intended checksum before packaging, signing with the hardened runtime entitlement - but I would love to hear if there's other steps I can do to protect this pipeline and my company from accidents like these that may unintentionally damage our reputation. Thanks in advance!

Hello, I submitted a .pkg installer for notarization on 2026-06-23 at 05:26 UTC, and more than 24 hours later the status is still In Progress. This is the first time I notarize this particular software — a small, lightweight Adobe Premiere Pro plugin — so I have no previous turnaround time to compare against. From what I understand, notarization usually completes within minutes to an hour, so a delay of this length feels abnormal and I'm not sure whether it's expected. Submission details Submission ID: 28b6be07-6bf0-4456-b6f1-6c2f7da27409 Submitted (UTC): 2026-06-23 05:26:37 Tool: xcrun notarytool (authenticated via a stored keychain profile) Package: .pkg installer for a small Premiere Pro plugin Status: In Progress (never moves past this state) The build was submitted successfully with no error and returned a valid submission ID. Running notarytool log does not yet return a log, since processing hasn't completed. Questions Is there currently a known notarization backlog or service delay on Apple's side? Can a first-time submission for a given product take noticeably longer than usual (e.g. an initial review)? What is a realistic maximum processing time before a submission should be considered stuck rather than simply slow? Should I wait, or cancel and resubmit? I'd rather not create duplicate submissions if it won't help. Thanks in advance for any guidance. Best regards, Robin