Post

Replies

Boosts

Views

Activity

Developer ID notarization submissions stuck In Progress after app transfer
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?
2
0
809
17h
statusCode 7000 "Team is not yet configured for notarization" — persistent for 2 months, Developer Support stalled
I'm hitting a persistent notarization failure for a new organization team and I've exhausted the Developer Support route (case 102898059793, open since early June with no state change), so I'm hoping someone here can help me understand what statusCode 7000 actually requires. Setup: Team: H4N8Z7K4S4 (SmashMelon LLC, US organization, enrolled May 1, 2026; I'm the Account Holder) App: macOS app, Developer ID direct distribution, hardened runtime, secure timestamp; codesign --verify --deep --strict passes locally The same team ships iOS updates via App Store Connect with no problems Latest Program License Agreement accepted (June 20, 2026) Every notarization submission since May 19 — via both Xcode Organizer and notarytool — is rejected with the identical log: "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support...", "statusCode": 7000, "issues": null Recent submission IDs, should anyone at Apple want to look them up: 7ec8ec66-ab23-46e3-996f-22ff9f463593 (June 15) f7546486-255e-484c-a08f-dd6a2df391df (June 17) 56754783-3436-4142-84a4-d8cbfe400fc1 (June 23) 79f3a014-812f-4cca-969c-e41a432c24fe (July 6) issues:null on every log suggests the binary is never scored at all — the rejection happens at a team-level gate. One possibly-relevant observation: the Certificates section of the developer portal (and the App Store Connect API) lists no certificate of any kind for this team — signing happens via Xcode's cloud-managed signing. So the error's literal wording may be accurate: the team's Developer ID configuration may genuinely never have been provisioned. Notably, Apple's cloud signing service happily issues Developer ID signatures for this team — it's only the notary service that refuses it. The two systems appear to disagree about whether this team is provisioned. Developer Support requested identity and company verification (passport, formation documents, IRS 147-C, etc.), which I uploaded via their secure link on June 15. Since then, three more submissions have been rejected with the unchanged 7000 result, and the case status has been "still under investigation" for four straight weeks. Questions: What does statusCode 7000 actually gate on? Is there anything an Account Holder can do from the portal side, or is this purely an internal provisioning flag? Is there a way to get this escalated to whoever owns team provisioning? Two months without the ability to ship a bug-fix build to direct-distribution users is getting hard to absorb. Happy to provide any additional detail. Thanks!
0
0
24
17h
Developer ID notarization submissions stuck In Progress after app transfer
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?
Replies
2
Boosts
0
Views
809
Activity
17h
statusCode 7000 "Team is not yet configured for notarization" — persistent for 2 months, Developer Support stalled
I'm hitting a persistent notarization failure for a new organization team and I've exhausted the Developer Support route (case 102898059793, open since early June with no state change), so I'm hoping someone here can help me understand what statusCode 7000 actually requires. Setup: Team: H4N8Z7K4S4 (SmashMelon LLC, US organization, enrolled May 1, 2026; I'm the Account Holder) App: macOS app, Developer ID direct distribution, hardened runtime, secure timestamp; codesign --verify --deep --strict passes locally The same team ships iOS updates via App Store Connect with no problems Latest Program License Agreement accepted (June 20, 2026) Every notarization submission since May 19 — via both Xcode Organizer and notarytool — is rejected with the identical log: "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support...", "statusCode": 7000, "issues": null Recent submission IDs, should anyone at Apple want to look them up: 7ec8ec66-ab23-46e3-996f-22ff9f463593 (June 15) f7546486-255e-484c-a08f-dd6a2df391df (June 17) 56754783-3436-4142-84a4-d8cbfe400fc1 (June 23) 79f3a014-812f-4cca-969c-e41a432c24fe (July 6) issues:null on every log suggests the binary is never scored at all — the rejection happens at a team-level gate. One possibly-relevant observation: the Certificates section of the developer portal (and the App Store Connect API) lists no certificate of any kind for this team — signing happens via Xcode's cloud-managed signing. So the error's literal wording may be accurate: the team's Developer ID configuration may genuinely never have been provisioned. Notably, Apple's cloud signing service happily issues Developer ID signatures for this team — it's only the notary service that refuses it. The two systems appear to disagree about whether this team is provisioned. Developer Support requested identity and company verification (passport, formation documents, IRS 147-C, etc.), which I uploaded via their secure link on June 15. Since then, three more submissions have been rejected with the unchanged 7000 result, and the case status has been "still under investigation" for four straight weeks. Questions: What does statusCode 7000 actually gate on? Is there anything an Account Holder can do from the portal side, or is this purely an internal provisioning flag? Is there a way to get this escalated to whoever owns team provisioning? Two months without the ability to ship a bug-fix build to direct-distribution users is getting hard to absorb. Happy to provide any additional detail. Thanks!
Replies
0
Boosts
0
Views
24
Activity
17h