Team: TS447Y97LA Please help identify the underlying failure for two automatic Xcode Developer ID submissions: a904af7c-751d-4e79-9f16-f71f16163ad5 — received SHA-256 a185ebe3860985d0e5f6a07e00348008687a636731a88033d620e3cb3f9ec6aa, 9,454,788,726 bytes. 1f55d5d3-f96f-47d5-ba91-b7372c213ad7 — received SHA-256 efe2aaa7c3714c68d82d4efc1eab9f14c9cc0751ef78c9b3a0856f1b53757ece, a fresh signing/export attempt. Both logs return Invalid/4000 and name these arm64 paths: Pelican.app/Contents/MacOS/Pelican Pelican.app/Contents/XPCServices/PelicanInference.xpc/Contents/MacOS/PelicanInference For the first submission only, we retained the exact Xcode upload ZIP and submitted app. Independent full comparison confirmed the received hash, all 117 ZIP members, and every app resource and metadata entry. There are 115 matching app entries plus two consistent Apple ZIP metadata entries. Python and installed libarchive independently reproduce identical bytes, CRCs, types and permissions. Raw local/central records, ZIP64 values, ranges and footer are consistent; there are no data descriptors or symlinks. The extracted host and all three XPC services pass deep, strict, all-architecture local codesign verification with exact Apple/Team/Developer-ID requirements. Earlier retained code-page, CMS and timestamp-binding diagnostics also passed. These local checks do not override the notary result. The second submission has not received the first submission's full independent ZIP comparison. The inference model contains one 5,349,771,222-byte stored member requiring ZIP64 sizes. Later Methods and host metadata also require ZIP64 offsets. We have not established this as a cause, or inferred success for code parts absent from the issue list. Which exact object and verifier stage failed: the named Mach-O CodeDirectory/CMS, an enclosing resource seal, or archive extraction? Is there a specific error code or documented resource-size limitation relevant to this member? If more evidence is needed, what is the smallest targeted diagnostic? We saw the workflow guidance about excluding huge data from notarization and would like to know whether it applies here before changing the distribution. The separate inert public carrier job, 9e033029-3914-436d-992b-96bd261637de, is now Accepted. At 2026-09-07 18:32 UTC, its exported app passed strict local verification, stapler validation and Gatekeeper assessment as Notarized Developer ID. This confirms the small control succeeded; it does not establish why the larger app failed. The full product remains Invalid. The proposed attachment contains the two issue logs, complete member/hash records, four-part size/signature map and a short result summary. No models, apps, profiles, certificates, credentials, account logs or system diagnostic are attached. The original artifacts can be discussed if a specific follow-up is needed.

Hello, ppq.apple.com appears to be unavailable. The issue is reproducible from multiple networks/devices. Requests to https://ppq.apple.com fail, preventing iOS from verifying developer-signed applications. This results in the device displaying an error indicating that an Internet connection is required to verify the developer/app. The issue appears to be server-side rather than related to the developer certificate or provisioning profile. Affected: (tested on) ppq.apple.com HTTPS / TCP 443 iOS 9.3.4 iPhone 5S [07/09/2026/20:07 + Zurich] Example: curl -I https://ppq.apple.com Response: HTTP/2 404 server: Apple date: Mon, 07 Sep 2026 18:08:13 GMT content-type: text/plain; charset=UTF-8 content-length: 0 x-b3-spanid: bdf368a2edbdbef7 x-b3-traceid: bdf368a2edbdbef7 x-b3-sampled: 1 strict-transport-security: max-age=31536000; includeSubdomains x-frame-options: SAMEORIGIN x-content-type-options: nosniff x-xss-protection: 1; mode=block Please investigate the availability of the PPQ service.

Hi team, Earlier, Apple’s documentation clearly mentioned that we needed to submit a request to Apple to obtain the Location Push Service Extension (com.apple.developer.location.push) entitlement. However, when I checked the Apple Developer Portal now, I don’t see an option to request this entitlement for my App ID. Could you please confirm whether this entitlement is still required to be requested from Apple, or if the process has changed and the request is no longer required? Thanks

When attempting to build an Apple Vision Pro application written in Swift in Xcode, we get the following status errors: "Provisioning profile [Profile Name] doesn't include the Main Camera Access capability.” and "Provisioning profile [Profile Name] doesn't include the com.apple.developer.arkit.main-camera-access.allow entitlement.” The provisioning profile we are attempting to use DOES have the Main Camera Access capability enabled through the Apple Developer portal. We have tried deleting and remaking the profile multiple times, as well as creating new profiles with the same settings, but completely different names and bundle identifiers, but keep getting the same errors. We DO have the "com.apple.developer.arkit.main-camera-access.allow” added to the entitlements file of the Xcode project, and we DO have the “NSMainCameraUsageDescription” key added to the info.plist file, along with the needed string describing the camera usage. Our organization has a valid and active Enterprise account, through which we have requested and been granted access to the “Main Camera Access” capability. We have built this applications multiple times before in the past year with no issues, these errors began after one of our provisioning profiles expired and we re-made it. We have tried clearing the Provisioning Profile Cache on our machine, clearing the Derived Data in the Xcode settings, and clearing the Xcode build cache. We are experiencing these errors on multiple machines, with different versions of our app, and with completely different apps that use the Main Camera Access entitlement. We experience these errors when the profile is downloaded directly in Xcode, and when it is downloaded from a browser and imported into Xcode. When we use “Automatically manage signing” our app properly builds and deploys to the Vision Pro, but when we use the app and attempt to access the main camera, the app crashes with the exception: "Exception: This app failed to request an authorization.” We have searched online forums and found several instances of others that have experienced this problem, but have not found a solution that works. Software Versions: Xcode Version: 26.6 macOS Version: Tahoe 26.5.1 VisionOS Version: 26.5

Free Personal Team, hitting "Your development team has reached the maximum number of registered iPhone devices." I need a local build on a physical device for a demo, so I'm looking for the fastest supported path rather than a fix for the underlying behavior. Context: I hadn't used this Apple ID for development in about two years, so the usual "wait a week for registrations to expire" advice doesn't seem to apply here. The registrations appear to have persisted well past that window. Already tried: removing and re-adding the account in Xcode, clearing ~/Library/Developer/Xcode/UserData/Provisioning Profiles, deleting the developer profile from the device, and confirming this isn't the separate offloaded-apps issue that causes the "maximum number of apps for free development profiles" error. Free accounts have no Devices page, so there's nothing to clear manually. I'm aware of two options: enroll in the Developer Program, or create a new Apple ID and use it as a fresh Personal Team. I've also seen reports of people calling Apple Support and having devices dropped manually, with mixed results. Is the phone call route still viable for someone on a free account, or has that closed? And is there anything else I'm missing before I go the new-Apple-ID route?

Hi everyone, For the past three days I've been unable to notarize my app — every attempt fails with an HTTP 500 error from Apple's notarization service. What's unusual is that the error occurs not only during submission, but also when simply validating credentials via store-credentials. Example: $ xcrun notarytool store-credentials "notarytool-password" \ --apple-id <id> --team-id <team> --password <app-specific-password> Validating your credentials... Error: HTTP status code: 500. Internal Server Error Request ID: K6NYCMIFNM66OI2WRG3ORZEDUE.0.0 Please try again at a later time. Since the failure happens at credential validation — before any package is even uploaded — I'm fairly confident this is a server-side issue, not something wrong with my setup or the binary. I've tried across different network connections, same result. Has anyone else been hitting this? Is there a known outage or incident on Apple's notarization infrastructure? Any way to escalate or get a status update beyond checking developer.apple.com/system-status/? Thanks

I have been trying to use Apple Developer Support to help with issues I'm having preventing me from signing and notarizing my apps. Delayed and not helpful responses from support. This has been going on for several weeks. I find it hard to believe that a Multi-Trillion Dollar company can't help me with my issues. I have what I think is a good certificate and private key as well as my App-Sepcific Password. The problem is that when trying to sign my apps, I get a popup indicating that that it's trying to sign in to Keychain using my first Name (Steve). My login on my system is "Stephen" which works fine for login and anything that wants to access Keychain. I need some help trying to resolve this.

I have two Apple Developer accounts under different Apple IDs: a free "Personal Team" account and a separate paid Organization account. Before my organization's Program enrollment was approved, I built an app to a physical device using Xcode signed into my personal account, which auto-registered an App ID under that personal team. Now that my organization account is active, I can't register the same App ID under the organization — both the web portal and Xcode's automatic signing return "not available," since it's already reserved under my personal team. Since personal (free) accounts have no web portal access, I can't see or manage that registration anywhere to release it myself. I own both accounts. Is there any self-service way to release an App ID from a personal team, or is contacting Apple Developer Support the only option? If support is required, is there a faster route than the standard contact form (I submitted a request several days ago with no reply yet)?

When trying to develop an Apple Shortcut, the shortcut doesn't appear (after many open, quit, adding permissions, etc.). My only Apple Account is my name associated with an Apple ID of QZ99..... However, when I try to check one (of many reasons) why it does not show up with Terminal: codesign -dv --verbose=4 "/Applications/My App.app" etc, it shows something "rejected" Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Aug 25, 2026 at 1:26:38 PM Info.plist entries=22 TeamIdentifier=QZ99... Runtime Version=26.5.0 Sealed Resources version=2 rules=13 files=4 Internal requirements count=1 size=204 /Applications/Write Create Date from Original.app: rejected origin=Apple Development: My Account (K533...) The K533... is different than my Team ID of QZ99... Could that be a reason my app is not registered with Shortcuts? Is that expected functionality? I guess I expected my Team ID to appear everywhere even after I deleted my account in Xcode, removed a current and expired certificate associated with K533 in Keychain, and then added my account back, and let Xcode regenerate a certificate.

Hi all, I've hit a wall trying to notarize a macOS installer pkg (built with Packages/Whitebox, signed with productsign). Every submission fails with: "message": "The binary is not signed with a valid Developer ID certificate." What's strange: this happens even on a minimal test pkg built with pkgbuild containing a single text file, signed only with productsign — no relation to my actual product. So it's not a content/nested-binary issue. Local verification passes fine: pkgutil --check-signature shows a full valid chain (Developer ID Installer → Developer ID Certification Authority → Apple Root CA) with a trusted timestamp. Both my Developer ID Installer and Developer ID Application certificates were freshly created on Aug 19, 2026, show as valid/trusted in Keychain Access, and match on developer.apple.com (Team ID 6VCLSHAN7R). What I've already tried: Re-created both certificates from scratch Waited 2 days in case of propagation delay Checked for pending program agreements (none) Checked developer.apple.com/system-status (Notary Service shows operational) Verified no duplicate/conflicting certificates in keychain Submitted a DTS support ticket 2 days ago, still waiting on a response. Has anyone run into this exact "valid everywhere except the notary service" situation? Any pointers appreciated. Example submission ID: 91eee4f0-778a-4edb-9515-eabfc6711f3f

I have requested an entitlement for my DriverKit based driver, but the status is still in "Submitted" phase. I have also tried contacting Apple Support by phone/mail but to no avail [Case ID: 20000143721904]. Below are the details of my request. Is there any way to know the turnaround time or to expedite the process as this entitlement is necessary for the distribution of our app? Also, what is the preferrable way to follow up in such cases? Entitlement: com.apple.developer.driverkit.transport.pci - DriverKit PCI (PrimaryMatch) Team: 8S33FS7Q5Q Request Id - NZYWRD96U3 Requested At - August 13, 2026 Type - Team Status - Submitted Thank you, Abishek.

We completed an App Store app transfer and the Notification Service Extension Filtering Entitlement (com.apple.developer.usernotifications.filtering) did not transfer with the app. App Apple ID: 6760007376 NSE Bundle ID: io.nolink.ios.nse New Team ID: M85WA8W78C Previous Team ID: V2E3A94DC9 The app, bundle IDs, and App Store presence all moved normally, but the entitlement is not available on the new team, so we cannot sign the NSE with the configuration the app previously shipped with. Our app is an encrypted messenger and this breaks incoming call handling for live users. Two questions: Is there an official process for re-associating a previously approved entitlement with the receiving team after a transfer, or does the new team always have to submit a fresh request? Could entitlements tied to a specific App ID move with the app during a transfer, the same way bundle IDs do? We have an open support case, but wanted to raise the general question here too.

I use a free Apple Personal Team with Xcode for on-device testing. My Apple Development certificate created on 15 August 2026 shows “Missing Private Key”, and Xcode is not allowing me to create a fresh replacement certificate. I have already contacted Apple Developer Program Support, and they directed me to the Apple Developer Forums for technical assistance. How can I revoke/reset the unusable certificate or clear the certificate state for my Personal Team so that Xcode can create a new Apple Development certificate?

Hi, I'm reporting three notarization submissions that have all been stuck in the "In Progress" state today. I'm posting mainly to ask whether my team has been pulled into in-depth analysis, since as far as I know there is currently no way to determine that from the client side. Team ID: SE3B3RM5Y4 === Stuck submissions (all still "In Progress" as of 2026-08-17 12:15Z) === 99722c12-dc10-4098-88be-84b7b58ff1f4 created 2026-08-17T07:51:19Z a41cf8fe-8883-4073-a043-5143323407da created 2026-08-17T09:45:11Z 35746a17-d332-4398-a353-cd7b1d8520ac created 2026-08-17T11:34:55Z notarytool info returns status "In Progress" with no message field for all three. No errors, no rejections - they simply have not moved. === Immediately prior submission, same pipeline, succeeded === a9138c72-41ee-4b42-adcf-78851eb3e5c7 created 2026-08-12T10:58:00Z Accepted That submission was Accepted in roughly 25 minutes. Every submission before it (2026-08-09 x2, 08-06, 07-26, 07-21, 07-15, 07-09) was also Accepted within a similar window. Today's three are the first that have not completed. === Why I believe this is team-scoped rather than a bad package === The three submissions are not retries of one another: 99722c12 and a41cf8fe are the same app version (1.3.1). 35746a17 is a different build of a different app version (1.3.2), produced from a newer source tree, with different content and a different zip. It was submitted almost 4 hours after the first one and was stuck immediately as well. So a fresh, independently produced package entered the same stuck state right away. That seems more consistent with a team-level hold than with a problem in any individual package. I understand from previous threads that once a team enters in-depth analysis, it affects all notarizations for that team until the state clears, which appears to match what I'm seeing. === What changed between the last successful submission and today === I want to disclose this in case it is relevant to the analysis: Package size grew from ~635 MB to ~751 MB (+116 MB, +18%) for the signed .zip. This is one of the larger single-release size increases in this app's history. A bundled third-party command-line helper was updated to a much newer release. It ships its own separately Developer ID-signed Mach-O executable, so while the file path and its signing identity are unchanged from previous releases, the actual binary content is almost certainly different from what was notarized on 2026-08-12. The app's own main executable is rebuilt every release, so its content always differs between releases. That has never caused a delay before. No new kinds of executables, dylibs, or runtimes were added to the bundle. I verified this by diffing the packaging scripts and the bundle tree: there are no newly introduced binary types, and no new entitlements. The Hardened Runtime entitlements are byte-for-byte identical to the 2026-08-12 build. === What I've already checked === Signing identity is a valid, unexpired Developer ID Application certificate. codesign -vvv --deep --strict passes on the app before submission. Hardened Runtime is enabled; entitlements unchanged from the accepted build. The Developer ID Notary Service shows as operational on the system status page. I am nowhere near the documented submission rate limits (3 submissions today). App-specific password and credentials are valid - notarytool history authenticates and returns results normally. === Environment === macOS host: Apple silicon Xcode command line tools, xcrun notarytool submit --wait Electron-based application, packaged with electron-builder Signed zip: ~751 MB === My questions === Is there any way to confirm from my side whether these submissions have been routed into in-depth analysis? I understand this is a known and frequently requested feature, but I want to make sure I'm not missing an existing diagnostic. Given that these are only a few hours old, I understand this is well below the threshold at which it makes sense to investigate individual submissions. I'm happy to wait. I'd just like to confirm whether waiting is in fact the correct action here, or whether there's anything in the changes described above that I should address on my end before resubmitting. Is submitting an additional build while earlier submissions are still pending harmful in any way? I've read that it's acceptable, but I want to confirm I'm not making the queue situation worse for my own team. I will update this thread when the state resolves, including how long it took, so there's a data point on the record. Thanks very much for your time.

My first-ever notarization submission on this developer account has been stuck in “In Progress” since it was submitted, with no result and no log available. Submission ID: cf59096b-e736-433c-b4e9-bd070e7d28bc Submitted: 2026-08-15 10:03 UTC via xcrun notarytool submit File: FLXZ-Sync-notarize.zip — a signed macOS app (“FLXZ Sync”, bundle ID media.flxz.sync) Signed with: Developer ID Application: Bipan Sharma (59CHL44F2Z) Status checks via xcrun notarytool info consistently return status: In Progress and counting as of this post) I understand a first submission on a new account goes through extended vetting and I have deliberately not resubmitted to avoid slowing that down. Could someone from Apple please take a look at whether this submission is proceeding normally or has stalled? It’s blocking distribution of the app. Happy to provide any further details. Thank you.

Hello, I am distributing a macOS application outside the Mac App Store and using xcrun notarytool to submit my .zip payload. However, my submission has been permanently stuck in the "In Progress" state for several days without completing, failing, or generating a log. Standard Apple Developer Support advised me to post here, as they do not have visibility into the Notary Service backend queue. From reading other threads on the forum, I suspect this might be a first-time submission hang or a backend account-provisioning issue. Could an engineer please take a look at the queue and help unstick this submission? Here are the exact details: Team ID: 5LY7WW2QDP Submission ID: 154a0dbd-4e6e-4475-b03f-da19cdc983bd Filename: Enso.zip Tool Used: xcrun notarytool When querying the status using xcrun notarytool info, it continues to return status: In Progress and xcrun notarytool log confirms no log is available yet. Any assistance in clearing this queue so I can proceed with notarization would be greatly appreciated. Thank you!

The actual error: pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (DeveloperID)”. I'm trying to sign a program written with gfortran. The steps worked the last time (Mar 23) I built this code. The steps to error: a) xcrun notarytool store-credentials --apple-id "xxx" --team-id "yyy" Giving Profile Name zzz and App-specific password b) codesign --force --timestamp --options=runtime -s "Developer ID Application: My Name (yyy)" AppName c) pkgbuild --root ROOT --identifier org.aaa.bbb --version "1.1.1" --sign "Developer ID installer: My Name (yyy)" AppName.pkg ROOT contains the package contents At this point I get the error pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (yyy)” Are there steps that have changed. Any suggestions? Thanks, David

Some UDIDs are getting added immediately but some takes up to 72 hours and status is "iPhone Processing". Is there a way to get this processing expedited and why some devices gets added immediately.

Team ID: RSNGKW5LNH I have a matched pair submitted seconds apart that I cannot explain, and I think it shows a service-side problem rather than one in my bundle. Submission Contents Result 359b004e-ccd2-4ab0-a02e-0516b5598b75 a signed Node binary + 2,000 identical one-line text files In Progress for 36+ minutes e4abe4b5-8829-47fb-aa1c-6a79d6824094 the same signed Node binary + a full 7,900-file npm dependency tree Accepted in 87 seconds Both created 2026-08-13 at 05:40Z, submitted in the same loop, same signing, same ditto -c -k --keepParent, same notarytool invocation. The trivial one hung; the complex one cleared. The first fixture is as innocuous as a submission gets — one Developer ID signed Node binary and 2,000 copies of a file whose entire content is // inert fixture stub. I can regenerate it from a script and share it. Eight of fifteen submissions tonight are still In Progress, the oldest at 78 minutes, spanning every shape I tried: with and without the dependency tree, with and without a signed binary, plain and encrypted inner archives, 11MB to 60MB, high-entropy and trivially compressible. WWDC21 session 10261 states a commitment to 15 minutes for 98% of submissions. WWDC21 session 10261 says Apple is "committed to completing this process within 15 minutes for 98 percent of Notary submissions, and most complete in under five." My cleared submissions match that — 19 to 113 seconds. The affected ones ran past five hours and were then deleted. I ran a 21-submission bisection with a decision rule fixed in advance (still In Progress at 10 minutes = hung; in practice the results were bimodal, with nothing at all between 113 seconds and 36 minutes). Each fixture differed from its neighbour by one property. Cleared, and so exonerated: the submission channel (31s), byte volume (108MB Node runtime alone, 44s), the Mach-O binaries themselves (9.9MB esbuild alone, 19s), file count (11,001 stubs, 110s), the name node_modules (108s), @-scoped directories, nesting depth, and directory count. Still hung after: pruning unused files, dereferencing all 222 symlinks, flattening the tree, and sealing it inside an inner zip. Two things make me think this is not a signing mistake on my side. First, a matched pair. A fixture containing an unsigned binary nested inside an inner zip came back Invalid in 113 seconds, with the log naming the offending path three times. Its pair — same layout, submitted two minutes later, differing only in that the nested binary was signed — has never returned anything. When the notary has something to say it says it quickly and precisely, and it descends into nested archives. Second, the stuck submissions are deleted. Seven were confirmed In Progress at 2026-08-12T07:13:12Z. Re-queried 21–26 hours later, all seven return "Submission does not exist or does not belong to your team" and none appears in notarytool history, while submissions from the same minutes under the same credentials still resolve — a978eb1f-d781-4fdc-9295-88540a37a504 (05:49:24Z) still returns Accepted; f991e71b-742e-4a7d-a47c-48809a60b321 (05:10:08Z) is gone. Two questions: Can anyone see what is happening to 359b004e-ccd2-4ab0-a02e-0516b5598b75? Given what is in it, I do not think there is anything in the archive to find, and its same-batch pair completing in 87 seconds suggests the service was healthy at that moment. Happy to provide the generating script, digests, or the full fifteen-submission ledger. Should a submission that cannot be processed disappear rather than reaching a terminal state? As it stands there is no way to tell "queued" from "will never complete," and the ids needed to report it expire before a support cycle finishes. The submission above is not my app — it is a fixture generated by a script, containing only my own JavaScript files and no Mach-O at all. I can describe its contents exactly, and regenerate it on request. I also have matched fixtures that differ only in directory naming, and a variant sealed inside an encrypted inner archive, if any of those would help narrow it.

I submitted an Endpoint Security entitlement request today (request ID NWFPYC286F, Team type). The request shows up in my Request History with status "Submitted," but I never received an ACK email or follow-up number. I've checked spam/junk folders and the email associated with our team account. Nothing from Apple. Two questions: Is the request actually in the review queue if I have a request ID in the portal but no email confirmation? Is there any way to check status or get a timeline estimate? This entitlement is critical for our product development. We're building agent identity infrastructure that needs ES for process-level attestation on macOS. Appreciate any help, especially from anyone who's been through this recently.