I'm seeing a problem with custom Installer plugins on macOS 27 beta 5 and beta 6. I have a .pkg containing a custom Installer plugin. The plugin is properly signed, and if I check it manually from Terminal, codesign is happy with it and doesn't report any errors. However, when I install the package by double-clicking the .pkg in Finder, the plugin is not loaded. I see this in the logs: amfid: /private/tmp/com.apple.installer.../KLNagentInstallPlugin.bundle/Contents/MacOS/KLNagentInstallPlugin not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" So apparently the plugin fails signature validation after Installer extracts it into /private/tmp, even though the same plugin passes codesign validation. This package/plugin worked on earlier macOS versions. So far, I've reproduced the issue on macOS 27 beta 5 and beta 6. Has anyone else run into this? Did anything change in macOS 27 regarding signing or validation of custom Installer plugins? I've also filed this via Feedback Assistant - FB24415432.

Title: Notarization submissions stuck "In Progress" for 4 days (new Team ID) Every notarization submission from my team has been stuck "In Progress" since 11 September 2026. The first one went through; everything submitted after it has never reached a verdict. Team ID: T36RPB6Z2G Tool: xcrun notarytool (Xcode command line tools), app-specific password App: a Tauri desktop app, Developer ID distribution outside the Mac App Store Submissions (UTC): 2026-09-11 11:17:19 76bd3fd2-657c-4c3c-9c6b-6e7bc789fb4e In Progress (~92 h) 2026-09-11 11:18:30 1becd424-2ede-4044-b432-7f3afc646270 Accepted (minutes) 2026-09-11 14:39:38 3058ba57-d546-4e82-a781-02a1494eef71 In Progress 2026-09-12 07:24:20 b9568de2-6504-4d83-adc6-40e44f08ba44 In Progress 2026-09-12 09:29:07 572cff54-0e90-4e0d-9908-4ad82759dc9a In Progress (control test) What I have ruled out: Credentials and signing are fine — 1becd424 was accepted within minutes with the same certificate, the same password and the same tooling. It is not my app: as a control I signed a 14 KB Mach-O (a copy of /bin/echo) with the same Developer ID Application identity, hardened runtime and a secure timestamp, submitted it on its own, and it has been "In Progress" for ~70 hours as well. xcrun notarytool log <id> returns "Submission log is not yet available" for all four, so processing appears to have never started. codesign --verify --deep --strict passes on the app bundle; the certificate chains to the Developer ID G2 intermediate and shows as valid in Keychain. The Developer System Status page reports the Notary Service as operational. This looks like the documented behaviour where an upload is held for in-depth analysis and every later submission queues behind it — but four days with no movement, including on a 14 KB binary, seems beyond the usual delay. I have deliberately stopped submitting so as not to lengthen the queue. Could someone from Apple check whether 76bd3fd2 is being held, and release it? This is blocking the first signed release of the app.

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.

One of our notarization submissions has been In Progress since Sep 11 and hasn't moved. Submission ID: 5069b140-08dd-4113-bd13-6bc632b4200d Created: 2026-09-11T19:58:35Z Team ID: 9R8Q4GQCR8 notarytool info still shows In Progress, and notarytool log says the log isn't available yet. Our pipeline had five submissions Accepted on Sep 10 with the same certificates. We moved from an Individual to an Organization account on Sep 9, in case that matters. I haven't resubmitted the same binary. Could you check whether this one is held for deeper analysis, and whether it's holding up new submissions from our team?

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. xcrun notarytool info no longer shows any meaningful state for them. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress (~2.5h): CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict → "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers + ~180 PyInstaller backend binaries) signed inside-out. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck looks like an account-level backend issue, not a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.

Hello everyone, My Mac is Intell-powered macOS 15.7.7 (24G720) $ clang --version Apple clang version 17.0.0 (clang-1700.0.13.5) Target: x86_64-apple-darwin24.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin I am a long-lasting developper on MacOS. For a few days, and probably since I have upgraded to MacOS Sequoia, all my C (or C++, etc) programs, even the simplest ever, fail to launch, once compiled with Apple's command line tools : $ clang simplest_ever_c_program.c $ ./a.out Killed: 9 The program is killed by MacOS before it launches. This occurs no matter with terminal I use (Zsh, bash, sh...). Removing / reinstalling command line tools did not fix the issue. There is no information printed in the Console. For some reason while investigating, I have come at some point to suspect a codesigning issue. **Indeed, signing the code after compilation seems to fix the problem : ** $ clang simplest_ever_c_program.c $ codesign -s - a.out Hello World ! Gratz : this progam could be run from the Terminal ! My questions : Why does MacOS suddenly started to kill my own executables compiled with clang ? Would you know how to fix the issue ? (may be an obscure new setting in MacOS preferences ?) Thanks much for your attention and in advance, Nicolas

My Apple Developer Program team cannot complete Developer ID notarization. Team ID: 8786B65DT4 Both submissions initially uploaded successfully and returned “In Progress,” but later disappeared completely. notarytool info returns: “Submission does not exist or does not belong to your team.” And: xcrun notarytool history --keychain-profile BELLE_EPOQUE_NOTARY returns: “No submission history.” Affected submissions: 9d235d80-01d1-4db7-81ed-112fc8bc97d2 Submitted 2026-08-16T15:28:42.805Z bd49caa9-0f30-4f72-80e4-f1e72ee6f6c9 Submitted 2026-08-22T17:32:43.457Z The app is a universal Unity macOS app distributed outside the Mac App Store via Steam. It is signed with a valid Developer ID Application certificate, Hardened Runtime, and secure timestamp. ZIP integrity and all nested Mach-O signatures pass local verification. Can Apple DTS / the notary service team investigate why submissions for this team disappear rather than reaching Accepted or Invalid?

Hello, I am experiencing persistent ITMS-90034 when trying to upload the first iOS app from a newly enrolled Individual Apple Developer Program account. The exact error is: Validation failed (409) Missing or invalid signature. The bundle at "Payload/[App].app" is not signed using an Apple submission certificate. (ID: 90034) I have already performed extensive signing checks and troubleshooting: Apple Developer Program membership is active. A valid Apple Distribution certificate is installed in Keychain together with its private key. security find-identity -v -p codesigning reports both Apple Development and Apple Distribution as valid identities. The correct Team and Bundle ID are selected. Automatic signing is enabled in Xcode. Provisioning profile caches and DerivedData were deleted, profiles were downloaded again, and a completely fresh archive was created. Xcode's App Store Connect export review explicitly shows: Certificate: Apple Distribution App Store provisioning profile for the correct Bundle ID get-task-allow = false beta-reports-active = true I then exported the IPA locally using Xcode's App Store Connect distribution workflow and independently inspected the actual exported binary with codesign. The main application reports: Identifier=[Bundle ID] Authority=Apple Distribution: [Name] ([Team ID]) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA TeamIdentifier=[Team ID] I also separately checked the embedded Capacitor.framework and Cordova.framework. Both are signed with the same Apple Distribution identity and Team ID and show the same WWDR -> Apple Root CA trust chain. I checked Keychain as suggested in similar forum discussions. The Apple Distribution certificate has its private key, the WWDR intermediate certificates are present and valid, and certificate verification reports: "...certificate verification successful." Despite all of the above, a fresh upload from Xcode Organizer still consistently fails with the same ITMS-90034. This appears very similar to other recent reports involving newly enrolled Individual Developer accounts where correctly signed binaries are rejected by App Store Connect. I also opened an Apple Developer Support case (case 20000149684934). So far I have received general signing/troubleshooting documentation, but the issue remains unresolved. At this point, is there any additional local signing verification I should perform, or could this indicate an account/team-level App Store Connect signing validation issue that needs to be investigated on Apple's side? I would especially appreciate guidance from Apple DTS on what diagnostic information would be useful to distinguish a local certificate-chain issue from an App Store Connect/account-side validation issue. Thank you.

Since my Apple Distribution signing certificate had expired I recently got a new one via https://developer.apple.com/account/resources/certificates/list and installed in on my login keychain. Since I had some issues with signing I suspected that codesign might still be trying to use an old expired certificate (as they have the same name "Apple Distribution: ()"). So to fix this I figured I could just delete the old expired certificate from Keychain Access so there was only the valid new certificate there with the same name. However, after doing this and trying to use it with codesign I get the following error error: The specified item is no longer valid. It may have been deleted from the keychain. In other words it seems it's not finding the new valid certificate and somehow still linking the name to the old certificate that it rightly guesses is removed. Following the tips from https://developer.apple.com/forums/thread/701514 I used security find-identity -p codesigning -v to check for installed codesigning certificates, and this listed the new certificate as expected. Using another tip in the same post I saw that you can also use the certificate hash as an identifier beside the name, and using this I can use it with codesign to sign. However, it's still not finding it via the name (or rather, it's still finding the old now removed one). What could be the reason for codesign not finding the correct new valid certificate based on the name and instead still finding the old one? Maybe there's some reference set somewhere to point the name towards specifically the old certificate?

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress: CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict returns "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers plus ~180 PyInstaller backend binaries) are signed inside-out These packages are essentially identical in size and structure to our previous release 2.1.7, which notarized within minutes. In fact 2.1.8 is about 1 MB smaller than 2.1.7 (arm64 dmg 214.2 MB vs 215.3 MB; x64 dmg 223.3 MB vs 224.5 MB), so this is not a large or unusual upload. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck, while the packages verify cleanly and match a previously-accepted release, looks like an account-level backend issue rather than a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.

Two notarization submissions have been stuck in "In Progress" for over 20 hours with no result. These are the first notarization submissions ever made by this developer account (Team ID: VZUUDKF3MW). Submission IDs: e2fff6a7-f270-421f-abc9-2419b00fc18c (submitted 2026-09-09 03:43:17 UTC) 2eef5754-1e0f-4de2-be32-9c3ee4fdd7b4 (submitted 2026-09-09 06:17:21 UTC) xcrun notarytool info <id> still returns: status: In Progress xcrun notarytool log <id> returns: "Submission log is not yet available or submissionId does not exist" Steps to reproduce: Sign a self-contained app bundle with a Developer ID Application certificate, hardened runtime (--options runtime), and a secure timestamp. Verify: codesign --verify --deep --strict passes; spctl -a -t exec reports "Unnotarized Developer ID" (expected pre-notarization state). ditto -c -k --sequesterRsrc --keepParent "MyApp.app" upload.zip xcrun notarytool submit upload.zip --keychain-profile <profile> --wait The command waits indefinitely. Status never leaves "In Progress". Expected: notarization completes within a few minutes. Actual: "In Progress" for 20+ hours, no log produced, no error returned. The notarytool credentials are valid (xcrun notarytool history succeeds). The signature meets all documented prerequisites. This appears to be a backend processing delay affecting first-time submissions from a newly enrolled team.

Your development team has reached the maximum number of registered iPhone devices. I am use the free provisioning file. So how can I delete old device and use my new iPhone to develop my app. only way is use a paid account? or register a new Apple ID?

I have a DriverKit system extension (dext) that uses PCIDriverKit. I would like to get the build environment straightened out to successfully distribute the dext and associated software to end users. There are three types of software involved: The Dext-hosting application - this is the application that must be installed to /Applications/, and will perform the registration of the dext. The dext is deployed "within" this application, and can be found in the /Contents/Library/SystemExtensions folder of the app bundle. The dext itself - this is the actual binary system extension, which will be registered by its owning application, and will operate in its own application space independent of the hosting application. Additional applications that communicate with the dext - these are applications which will connect to the dext through user clients, but these applications do not contain the dext themselves. There are multiple locations where settings need to be exactly correct for each type of software to be signed, provisioned, and notarized properly in order to be distributed to users: developer.apple.com - where "identifiers" and "provisioning profiles" are managed. Note that there are differences in access between "Team Agent", "Admin", and "Developer" at this site. Xcode project's Target "Signing & Capabilities" tab - this is where "automatically manage signing" can be selected, as well as team selection, provisioning profile selection, and capabilities can be modified. Xcode project's Target "Build Settings" tab - this is where code signing identity, code signing development team, code signing entitlements file selection, Info.plist options and file selection, and provisioning profile selection. Xcode's Organizer window, which is where you manage archives and select for distribution. In this case, I am interested in "Developer ID" Direct Distribution - I want the software signed with our company's credentials (Team Developer ID) so that users know they can trust the software. Choosing "automatically manage signing" does not work for deployment. The debug versions of software include DriverKit (development) capability (under App ID configuration at developer.apple.com), and this apparently must not be present in distributable provisioning. I believe this means that different provisioning needs to occur between debug and release builds? I have tried many iterations of selections at all the locations, for all three types of binaries, and rather than post everything that does not work, I am asking, "what is supposed to work?"

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.