You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I've been unable to notarize an installer for an app (https://fxfactory.com/info/fxcore/) ever since adding a plug-in SDK that I was hoping to distribute as follows: /Library/Developer/SDKs/FxCore.sdk /Library/Developer/Xcode/Templates/FxCore/FxCore.xctemplate This creates the smoothest possible UX for someone who starts using the SDK, mimicking official SDKs. This is causing notarization failure, without a useful explanation, but a search suggests that Apple is preventing installers from touching the /Library/Developer directory as this might otherwise compromise the developer toolchain. What is the correct strategy for third-party SDKs? I'm assuming that ADDITIONAL_SDKS doesnt' care if the SDK isn't located at that specific location, but is there any other place where I can put the xctemplate and have it appear when creating a new project in Xcode? (I haven't tried using a post-install script to copy files after the fact but I’d assume that would fail... otherwise what would be the point of this extra safety check.) Thank you!

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

Two notarization submissions for a Developer ID–signed macOS app have been "In Progress" for over an hour. Earlier submissions from this same team, credentials and workflow were all Accepted within minutes. Submissions Created (UTC)IDFileStatus2026-11-05 15:54:4802956de4-0ec7-4009-8f8e-1635f93a10d1ProxyPal.zipIn Progress2026-11-05 16:37:25e38d47a1-6709-4008-9682-18f9b96af217ProxyPal.zipIn ProgressThe second one is a resubmission of the identical zip, sent after the first had been stuck for about 40 minutes. What I've checked xcrun notarytool info <id> returns In Progress. xcrun notarytool log <id> returns "Submission log is not yet available". Authentication and upload work, and notarytool history lists both submissions. codesign --verify --deep --strict passes on the app. Every executable in the bundle has the hardened runtime and a secure timestamp. The zip is made with ditto -c -k --keepParent, the same command as the earlier accepted releases. The bundle contents are essentially unchanged since the last accepted release. The differences are a small generated static HTML help folder and version-number changes. Environment Submitted with xcrun notarytool submit ... --keychain-profile ... --wait from a script. macOS 26 (Darwin 25.6), Xcode toolchain notarytool. Zip is 89 MB, 193 files, and includes two nested .apk files that were also in earlier accepted releases. Questions Are these two submissions held for additional analysis, or stuck in the queue? Is there anything on my side I should change?

I'm testing Apple's official "Capturing screen content on iOS" sample architecture using Xcode 27.2 and a physical iPhone running iOS 27.2. My application builds, signs and launches successfully using a Personal Team without the screen-recording entitlement. However, when I add the entitlement required by Apple's sample, automatic provisioning fails with: "Entitlement com.apple.developer.screen-recording not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file." The generated provisioning profile does not contain the entitlement. Could Apple clarify: Is this entitlement available to Personal Teams for development? Does it require Apple Developer Program membership or separate capability approval? What is the supported procedure for obtaining a provisioning profile that includes it? Is there a known issue with entitlement availability or the iOS 27 sample? Our intended use is explicitly authorised full-display capture using the system picker, with on-device processing and no attempt to bypass user consent. I would appreciate guidance on the correct supported provisioning procedure.

My first app cannot be uploaded: every IPA is rejected with ITMS-90035 "Invalid Signature". Setup: individual account, Team ID V7F74UFRBN, Xcode 27.0, macOS 26.6.2, Cloud Managed Apple Distribution certificate. My team name contains the Turkish letter "İ" (TELLİ). The certificate common name stores it as NFC (C4 B0), but the designated requirement written at signing time stores it as NFD (49 CC 87): certificate leaf[subject.CN] = 0x...54454c4c49cc87... so "codesign --verify --deep --strict" reports "does not satisfy its designated Requirement" for the app and every embedded framework. This looks like FB24633162 / thread 843700. I asked Developer Support to change my team name to the ASCII form "Mehmet Kaan TELLI" (case 103017162953) but have had no reply after several days, and the phone option shows as unavailable. Questions: Can DTS help escalate the team name change? Until then, is there a supported way to sign so the upload passes?

Application Group identifier unavailable after moving from a Personal Team to a paid Apple Developer Program enrollment Hi everyone, I built an app in Xcode using a Personal Team (free, signed in with my Apple ID) with the bundle identifier com.jcsnp.Minutely. My paid Apple Developer Program enrollment has been active since 5 Nov 2026, and I'm now trying to build and run the app under the new team. Xcode is blocking me on the App Group and the provisioning profile. Environment macOS 27, Xcode 27.2, iOS target 26.6 Paid enrollment: individual account, active since 5 Nov 2026 Errors Communication with Apple failed. An Application Group with Identifier 'group.com.jcsnp.Minutely' is not available. Please enter a different string. No profiles for 'com.jcsnp.Minutely' were found Xcode couldn't find any iOS App Development provisioning profiles matching 'com.jcsnp.Minutely'. What I've tried Cleaning the build folder. The errors remain. Questions The App Group group.com.jcsnp.Minutely is reported as unavailable. Is it still registered to my old Personal Team, or to another account? If so, how do I release it or move it to the new team? Does the Personal Team's registration of the bundle ID need to be removed before com.jcsnp.Minutely can be registered under the paid team? Is there a recommended order for setting this up: registering the App ID and App Group in the developer portal first, then letting Xcode generate the profile? Thanks in advance for any guidance.

Hi everyone, I'm trying to publish my first iOS app (a game built with the Godot engine), but every upload to App Store Connect fails with this error: "Invalid Signature. Code failed to satisfy specified code requirement(s). The file at path "sevenatseven.app/sevenatseven" is not properly signed. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate." Setup: Xcode 27.1 (27A9275), macOS 27.0.1 The Xcode project is exported from Godot 4.7.2 (stable) Automatic signing with my paid team; no signing errors shown in Xcode Release configuration, Code Sign Identity: Apple Development (Xcode re-signs for distribution on upload) My account has a valid Distribution Managed certificate What I tried: Archive with "Any iOS Device (arm64)", then Distribute App > App Store Connect > Upload Clean Build Folder, fresh project export, new archive The archive always succeeds and the app runs fine on a real iPhone, but the upload is rejected every time with the same error on the main executable. What can cause this error on the main executable when the archive and signing look correct in Xcode? Is there a way to see which code requirement is failing, or a codesign command I should run on the archive to check it? Thanks!

Title: Supported launch code requirement with direct posix_spawn and exclusive child reaping on macOS I'm designing a security-sensitive process-lifecycle controller on Apple silicon macOS. The controller directly launches a signed foreground executable and must satisfy two requirements: Before any child executable code runs, macOS must enforce a launcher-supplied requirement binding the child to approved code, preferably using LaunchCodeRequirement and CodeDirectoryHash. The original parent must retain exclusive ownership of the child's terminal status through waitpid(), with signalling and reaping serialised by one designated execution context. I understand that Foundation Process.launchRequirement supports launch-time executable constraints, whereas the established lifecycle currently uses direct posix_spawn(). Could Apple DTS clarify: 1. Is there a supported public API for supplying an equivalent launcher-owned code requirement through direct posix_spawn() or its attributes? 2. If Foundation Process is the supported route, can its caller exclusively consume the direct child's terminal status with waitpid() without competing automatic reaping or status consumption by Foundation? Or must callers use Foundation's own termination reporting? 3. If those requirements cannot be combined through one supported interface, is there a recommended public API or launch topology providing both pre-execution code-requirement enforcement and an attributable terminal-status oracle? I'm seeking supported contractual behaviour, not private implementation details. This question concerns executable identity and child lifecycle ownership only. It does not assume that process termination establishes containment of descendants, delegated work or pending external operations. Thank you.

Can someone tell me the applications requirements for using the secure enclave on MacOS? Does the application need to be signed with the secure-enclave entitlement in order to use it? Since this is a restricted entitlement, does my App ID need approval to use it from Apple? Currently I'm building in XCode 16 on Sequoia (15.5) using developer signing. My application is a C/C++ daemon running as plist out of /Library/LaunchDaemons. I have also built it as an application using the instructions here but this has not lead to a solution: https://developer.apple.com/documentation/xcode/signing-a-daemon-with-a-restricted-entitlement/ When I run my application from the command line via sudo signed but without the secure-enclave entitlement enabled in my entitlements file it runs. The first call to: SecAccessControlRef access = SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, kSecAccessControlPrivateKeyUsage, &error); succeeds without error. The call to create the key using: SecKeyRef privateKey = SecKeyCreateRandomKey(attributes, &error); then fails with error: (OSStatus error -50 - Failed to generate keypair) Here are the setup attributes (keySize = 256): CFDictionarySetValue(attributes, kSecAttrKeyType, kSecAttrKeyTypeECSECPrimeRandom); CFDictionarySetValue(attributes, kSecAttrKeySizeInBits, keySize); CFDictionarySetValue(attributes, kSecAttrLabel, keyName); CFDictionarySetValue(attributes, kSecAttrApplicationTag, keyLabel); CFDictionarySetValue(attributes, kSecAttrTokenID, kSecAttrTokenIDSecureEnclave); // Store in the Secure Enclave CFDictionarySetValue(attributes, kSecAttrKeyClass, kSecAttrKeyClassPrivate); CFDictionarySetValue(attributes, kSecAttrAccessControl, access); CFDictionarySetValue(attributes, kSecAttrIsPermanent, kCFBooleanTrue); // persist key across app restarts and reboots CFDictionarySetValue(attributes, kSecAttrCanEncrypt, kCFBooleanTrue); CFDictionarySetValue(attributes, kSecAttrCanDecrypt, kCFBooleanTrue); CFDictionarySetValue(attributes, kSecAttrAccessible, kSecAttrAccessibleWhenUnlockedThisDeviceOnly); CFDictionarySetValue(attributes, kSecReturnPersistentRef, kCFBooleanTrue); When I run the application signed and include the "com.apple.developer.secure-enclave" in my entitlements file it crashes at startup. I believe this is to be expected based on above. How do I proceed such that my application can use the secure enclave correctly?

I release my app both in the MAS and on my website. I use the same signing credentials, but necessarily different certs (Apple Development vs. Developer ID). When I run the MAS app and then run the other version, or vice versa, I need to re-authenticate the many privacy permissions each time (Finder AppleScript, Network browse, Full Disk Access), which is tedious and keeps causing trouble for other users because some of these require a tcc reset (which my app currently invokes manually, which I consider a hack, though). So, am I doing something wrong or is it really no possible to have both signed apps use the same identity with TCC?

An existing development-signed arm64 iPad Release build succeeds in Xcode, including its code-signing step. Post-build static verification from a restricted automation environment reports CSSMERR_TP_NOT_TRUSTED for Runner, App.framework, and Flutter.framework. The recorded commands were: codesign --verify --deep --strict --verbose=6 <app-path> codesign --display --entitlements - --xml <app-path> The entitlements command returns no XML and reports: binary contains an invalid entitlements blob; OS will ignore these entitlements This warning occurs only for Runner. The two frameworks have no entitlements slots. A public Security framework code-signing trust evaluation returned false, TrustResultValue 0, and an empty detailed result. The error and last underlying error were NSOSStatusErrorDomain / -26276, with description "OSStatus -26276". Existing observations: The Apple Development signing certificate matches the provisioning profile, which includes the target iPad. Keychain Access showed valid certificates using system-default trust. Offline code-page/resource hash and CMS signature checks matched. Offline parsing found matching XML/DER entitlement values within the profile's allowed values. These checks do not establish native trust or installation validity. The host is an Apple Silicon Mac and the target is a physical iPad. We have not isolated a focused Xcode sample that reproduces this issue. The original app contains Flutter and other integrations. We do not know whether the cause is in the artifact, trust evaluation, or the restricted execution environment. An OS log query was denied by that environment; it has not been retried or bypassed. We have not changed certificate trust, re-signed, rebuilt, or attempted installation to work around the verification failure. What supported, narrowly scoped diagnostic procedure would: distinguish a genuine trust-policy rejection from an evaluation that could not complete, diagnose the Runner-only entitlements warning, and establish whether the unchanged artifact is installable? Please advise the minimum redacted evidence or focused sample needed. We are seeking Apple's supported diagnostic route without exporting credentials or weakening trust settings. Attachments: none.

Since upgrading my free Apple Developer account to the paid Apple Developer Program (Individual) on September 21, 2026, every app signed with my paid team fails to install on my devices. TestFlight builds work. Error (Xcode Run, devicectl, Ad Hoc export): MIInstallerErrorDomain Code 13 / 0xe8008018 "The identity used to sign the executable is no longer valid." +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:] LibMISErrorNumber = -402620392 What I've established: A brand-new Hello World app with no capabilities fails the same way, so it is not my project, entitlements or widget. The same Hello World signed by a free Personal Team installs on the same iPad (after trusting the developer in Settings). So the device, OS, Xcode and Mac are fine. Fails on iPad Pro 13" M4 (iPadOS 27.0.1 and 27.2), iPhone Air (iOS 27.0.1) and iPhone 15 Pro Max (iOS 26.0.1), with Xcode 27.0, 27.1 and 27.2. Fails with Apple Development signing (Xcode Run) and with an Ad Hoc export signed with an Apple Distribution certificate. codesign verifies the app, the embedded profile contains the signing certificate and the device UDIDs, and the chain (WWDR G3 to Apple Root CA) is valid and not expired. Regenerated the Development and Distribution certificates, cleaned expired WWDR certificates from the keychain, removed profiles on the device, re-paired and toggled Developer Mode. No change. Only apps re-signed by Apple (TestFlight) install. This looks like stale signing state for the team on Apple's side after the free-to-paid conversion. I have an open request with Apple Developer Support (Case-ID 22506476) and Feedback Assistant report FB24912726, but have had no reply in two weeks. Has anyone seen 0xe8008018 on a team that was recently upgraded or converted, and is there anything I can do on my side beyond asking Apple to reset the team's signing identity?

Hello Apple Developer Support, We are seeking clarification regarding the impact of the upcoming certificate changes taking effect on February 1, 2027. Our organization has previously distributed macOS installer packages (.pkg) that were: • Signed using a Developer ID Installer certificate that chains to the Developer ID Certification Authority intermediate certificate expiring on February 1, 2027. • Successfully notarized by Apple. • Signed with a secure timestamp. We are specifically seeking clarification on the impact of the Developer ID Certification Authority intermediate CA expiration on packages that were signed, securely timestamped, and successfully notarized prior to the expiration date. We would like to understand how these existing packages will be treated after February 1, 2027. Questions Will installer packages (.pkg) that were already signed, timestamped, and notarized before February 1, 2027 continue to install successfully after that date? Does notarization combined with a secure timestamp allow these previously distributed packages to remain trusted and installable after the certificate changes take effect? Are software vendors required to re-sign and re-notarize installer packages that have already been distributed if they were signed using certificates affected by this change? If re-signing is required, does this apply to: • Only new packages created after February 1, 2027, or • Existing packages that were previously notarized and distributed? Are there any recommended validation steps to determine whether an existing notarized package will continue to install successfully after February 1, 2027? Business Impact We are evaluating whether previously released installer packages signed with Developer ID Installer certificates that chain to the expiring Developer ID Certification Authority intermediate CA will remain deployable for customers after February 1, 2027, and whether any re-signing or re-notarization effort is required for our existing catalog of notarized installers. Without clarification, we cannot determine whether archived installers will continue to function as expected or whether remediation work is required to preserve the installability of previously released software versions. Thank you for your guidance. We would appreciate any relevant documentation or recommendations regarding best practices for existing notarized installer packages.

xcrun notarytool submit crashes with a SIGBUS during upload, every time, for one specific build of our app. Filing this as its own post since it is a distinct, reproducible crash with a clear crash report, separate from general In Progress slowness. The exact exception, from the macOS crash reporter, is EXC_BAD_ACCESS (SIGBUS), subtype KERN_PROTECTION_FAILURE, with the message "Could not determine thread index for stack guard region." It happens on a background thread named nio.nioTransportServices.connectionchannel, which is the SwiftNIO Network.framework transport thread handling the upload connection. The faulting stack is inside notarytool's own code, going through String.init(format:), then Foundation's NSString formatting, then CoreFoundation's CFString formatting functions, almost certainly while it is trying to format a log or progress line during the upload. The same small set of return addresses repeats many times in a row right before the crash, which looks like unbounded or very deep recursion in that logging path. Reproduction: run xcrun notarytool submit yourbuild.zip --apple-id ... --password ... --team-id ... --wait against a roughly 180 MB zip of a signed .app. The tool prints Submission ID received, starts the S3 multipart upload, and crashes within about a second, before any upload progress is shown, with no error message. The submission is left behind on Apple's side, stuck at status In Progress, and disappears entirely about 11 to 12 hours later, at which point notarytool info for that id returns Submission does not exist or does not belong to your team. This is completely reproducible for us: it has now happened on five separate submissions of our x64 (Intel) build, and zero times submitting our arm64 (Apple Silicon) build of the exact same app, same machine, same credentials, same day. We also tried setting the upload timeout higher with defaults write com.apple.gke.notary.tool nt-upload-connection-timeout 300, which did not help, same crash. We have full macOS crash reports (.ips files) for two separate occurrences of this and are happy to attach or send them, along with the zip that triggers it.

Unfortunately Radar has been down for several hours tpday, so I figured I'd post here to see if anyone else is having the same issue. All of our Notarization and Stapling for our non-App Store apps is done via Terminal. It's generally worked pretty well for the past 12 months. But for the last 6 days, Notarization has been fine, but Stapling results in a NSURLErrorDomain Code=-1005 error ("The network connection was lost.") about 50% of the time. Needless to say this is getting to be pretty frustrating. I haven't noticed any hiccups with my Internet connection. Using Xcode 26.3 on Sequoia 15.8.2, and again doing everything on the command line. Anyone else seeing the same thing? Here's the most recent Stapling failure from a few minutes ago: error is Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x6000007983f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x600002a84050 [0x20221bfa8]>{length = 16, capacity = 16, bytes = 0x100201bb11f8f13c0000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>" ), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4} CloudKit's response is inconsistent with expections: (null)

Hello everyone, I'm currently developing a macOS application called macOSDocker, which uses Apple's Virtualization.framework to run a lightweight Linux virtual machine hosting Docker containers. One of the main features is bridged networking using VZBridgedNetworkDeviceAttachment, allowing the virtual machine to obtain its own IP address on the local network and making Docker containers directly accessible without additional NAT or port forwarding. However, this requires the restricted com.apple.vm.networking entitlement. Application details: App: macOSDocker Bundle ID: com.macOSDocker Team ID: RYPSKH8HG5 Apple Developer Support Case: 102997773774 I've already contacted Apple Developer Support to request access to this entitlement, but they directed me to the Apple Developer Forums instead. Currently, Xcode reports that the com.apple.vm.networking entitlement is missing from my provisioning profile. My questions are: What is the official process for requesting approval for the restricted com.apple.vm.networking entitlement? Is there a specific form or contact within Apple Developer Relations for submitting such a request? I would appreciate any guidance, particularly from Apple engineers, on how to proceed with the entitlement approval process. Thank you! Kevin

Hello Apple Developer Community, I'm running macOS 27.2 on Apple Silicon with Python 3.13.17 installed from the official python.org installer. I am investigating an inconsistency in macOS code-signing and trust verification. What I have observed: In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed. In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED. The Mac's date and time are configured automatically. The exact cause of the difference between execution contexts remains unknown. My questions: What could cause macOS trust evaluation to differ between execution contexts? Which read-only diagnostics could identify the cause? How can I investigate this without modifying Keychain trust settings, disabling system security or purchasing a paid developer membership? I can provide sanitized diagnostic logs if needed. Thank you for your help!

I am struggling with uploading my Mac-only app to TestFlight. I used to do this with Xcode 13.4.1 for a while without trouble, but now I have built the app with Xcode 27.1 and am getting issues such as ITMS-90885 and ITMS-90288 and I cannot figure out how to make it work. I have now at least realized that I seem to need to create a new provisioning profile because the one was using is missing some entitlement(s). To create a new profile, I need to create also a new certificate at https://developer.apple.com/account/resources/certificates/add But there's already my first hurdle: There are two types that allow upload the to MAS: "Apple Distribution" and "Mac App Distribution". Which one should I choose? I even googled for help but found nothing more than what the above website says. It's not clear what the difference is when I only want to submit to the MAS, and whether choosing the wrong one may already be part of the problem I'm having now with uploading my app. Can someone please explain in more detail if they're having exclusive behavior when using them to upload Mac apps to the MAS and TestFlight?

Hello, All of our notarization submissions except one are stuck in "In Progress" with no terminal state. I would appreciate it if someone could confirm whether they are still queued, or whether something on our side is blocking them. Team ID: 7MK3979GD2 Account: individual, newly enrolled; Developer ID Application certificate issued 2026-10-29 Tool: xcrun notarytool submit with an App Store Connect API key (Team Key, Admin role) Auth/upload work fine: notarytool info returns "In Progress"; notarytool log says the log is not yet available. Submissions (all times UTC): created submission id file status 1 2026-10-29T23:59:53Z 10b84260-955d-4ed5-a7ad-aa7484228427 GsGPT.zip In Progress 2 2026-10-30T01:24:44Z 2fa44ce1-345e-467b-8ea9-97362be6f45f GsGPT.app.zip Accepted (~2.5 min) 3 2026-10-30T01:28:09Z 097fee47-6fec-4645-b4af-f8250820dc8f GsGPT-mac-arm64-8.31.0.dmg In Progress 4 2026-10-30T09:21:25Z 9f4ec58b-d116-4e84-b859-9281ec0e5b92 GsGPT.app.zip In Progress 5 2026-10-30T11:05:58Z d0b9cebb-7795-4699-94b7-2c040fd06028 GsGPT.app.zip In Progress Notes: Submission #2 was accepted in about two and a half minutes, and its log reports "status": "Accepted", "issues": null. All submissions come from the same account, the same certificate and the same build job, so I believe the signed content is compliant. I have not resubmitted the same content. Later attempts are different artifacts from the same pipeline (app zip and DMG). App: GsGPT, an Electron-based macOS desktop app (bundle id cc.ekoaku.gsgpt, version 8.31.0, arm64), signed with Developer ID Application with hardened runtime, to be distributed outside the App Store as a notarized, stapled DMG. I understand that first notarizations from a new account may undergo additional screening. The oldest stuck submission has now been waiting over 13 hours, so I would just like to know whether these are still being processed or have been held. Could you please confirm the current state of Team 7MK3979GD2's submissions and let me know if anything on our side needs action? I am happy to provide any logs or additional details. Thank you very much for your time.

Hi Apple team, I have a recently created dev account and submitted two different 20-30 mb .apps for notary through the notary tool. I have read that this should only take minutes at this size of an app but both have been stuck in progress for almost 24+ hours. Below are the UUIDs of the notary submissions. Also I tried re-submitting but these are also stuck in progress. Successfully received submission history. history -------------------------------------------------- createdDate: 2025-09-26T11:46:32.643Z id: 9714758e-e216-496d-80f8-422f77011ebe name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T21:48:46.161Z id: c2a81300-c903-4277-8ef3-70205a690c76 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T18:24:36.205Z id: 42742be1-c7e5-4483-a2c5-95e89086d070 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T16:35:09.059Z id: a404256e-40c2-4dca-97fc-983e70ea4b7b name: <>.zip status: In Progress