I'm working on a system extension leveraging endpoint security entitlement. However, while in development, is there a way to continue working and testing locally without having the endpoint security entitlement approved or needing the extension signed. I got these errors running a build: Provisioning profile "Mac Team Provisioning Profile: "com.xxxxx.extension" doesn't include the com.apple.developer.endpoint-security.client entitlement.

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?

Hello, I'm working on an app at work and we finally got to signing and notarizing the app. The app is successfully notarized and stapled, I packaged it in a .dmg using hdiutil and went ahead and notarized and stapled that as well. Now I tried to move this app to another machine through various methods. But every time I download it from another machine, open and extract the contents of the dmg and attempt to open the app, I get the "Apple could not verify my app is free of malware that may harm your Mac or compromise your privacy. When I check the extended attributes there's always the com.apple.quarantine attribute which from what I know, is the reason that this popup appears I've tried uploading it to google drive, sending through slack, onedrive, even tried our AWS servers and last but not least, I tried our Azure servers (which is what we use for distribution of the windows version of our app). I tried uploading to Azure through CloudBerry (MSP360 now), and azure-cli defining the content-type as "application/octet-stream", the content-disposition as "attachment; filename=myApp.dmg", and content-cache-control as "no-transform". None of these worked The only times where a download actually worked with no problems was when I downloaded through the terminal using curl, which obviously not a great solution especially that we're distributing to users who aren't exactly "tech savy" I want the installation experience to be as smooth as other apps outside the App Store (i.e Discord, Slack, Firefox, Chrome etc....) but I've been stuck on this for more than a week with no luck. Any help is greatly appreciated, and if you want me to clarify something further I'd be happy to do so

I am trying to set up code signing for my macOS/Tauri app and I’m running into a problem with my Developer ID Application certificate in Keychain Access. Steps I followed: Generated a CSR on my Mac using Keychain Access → Certificate Assistant → Request a Certificate From a Certificate Authority. Uploaded the CSR to the Apple Developer portal. Downloaded the resulting .cer file and installed it in my login Keychain. The certificate appears under All Items, but it does not show under My Certificates, and there is no private key attached. What I expected: The certificate should pair with the private key created during CSR generation and show under My Certificates, allowing me to export a .p12 file. What I’ve tried so far: Verified that the WWDR Intermediate Certificate is installed. Ensured I’m on the same Mac and same login Keychain where I created the CSR. Revoked and regenerated the certificate multiple times. Tried importing into both login and system Keychains. Problem: The certificate never links with the private key and therefore cannot be used for signing. Has anyone experienced this issue or knows why the certificate would fail to pair with the private key in Keychain Access? Any workaround or fix would be greatly appreciated.

I have an application that I have been signing, notarizing and distributing to beta testers for a year with no issues, note: I have never got stapling to work I always get a error 65 in the process. But up until yesterday that hasn't been an issue and online verification has always worked. Yesterday morning around 9am online gatekeeper verification has been failing with: APP not opened, apple cannot verify app is free of malware. etc this keeps happening, with every build I try. redownloading previously successful builds show the same behavior I know I can allow in privacy and security, but heading towards launch I dont want to have to tell users to do that. has there been a change in how gatekeeper works or issues with the service? any help with this or getting stapling working would be very appreciated!

Hi Apple DTS & community folks, I’m reaching out regarding an issue we’ve encountered with the com.apple.developer.mail-client capability for our app (bundle identifier: so.notion.Mail). We were granted this entitlement last week to allow the app to be set as a default Mail client. While everything works as expected when archiving and distributing builds locally in Xcode, we’re running into a problem when using Xcode Cloud. Specifically, Xcode Cloud attempts to archive and distribute an Ad-Hoc build, but the Ad-Hoc provisioning profile does not include this special entitlement. Since we’re using Xcode-managed profiles, we don’t have the ability to create or adjust an explicit profile ourselves. This issue only arises in Xcode Cloud—local distribution works unless we explicitly attempt an Ad-Hoc build (which is not our intent). I’ve included a screenshot of the error for reference. We found this forum post describing the same issue, where the resolution was Apple enabling the entitlement for Ad-Hoc builds. We’d like to request that Apple enable this capability for Ad-Hoc builds for the Notion Mail application so that Xcode Cloud distribution functions correctly. Thank you for your help!

I'm attempting to upload an updated version of our macOS app for distribution via the App Store. We've done this without issue before, but I am now receiving a warning when I upload the app via Transporter: "Cannot be used with TestFlight because the signature for the bundle at “AXON Studio.app” is missing an application identifier but has an application identifier in the provisioning profile for the bundle. Bundles with application identifiers in the provisioning profile are expected to have the same identifier signed into the bundle in order to be eligible for TestFlight." (90886) I just recently started seeing this warning when I upload our application via Transporter. Before this warning started happening, I was using the exact same process and scripts to build/package/codesign our application. NOTE: we are not using Xcode to build our application, so we can't take advantage of any codesigning/packaging automation provided by Xcode (the app is written in C#/.NET 6.0), so we are doing all build/package/codesign steps using the appropriate macOS command line utilities. Also, I have verified that the app bundle and its contents have valid signatures. Does anyone have any idea what may have changed to cause this warning, or how I might go about determining the root cause so I can fix it?

I spent 20 minutes trying to figure out why codesigning was failing -- I had the pf block set up correctly, my keychains were unlocked, and then, eventually, it occurred to me, hey, maybe an IP address changed, so I disabled IPv6 except for link local, and then amazingly, it went back to working. I filed FB13706261 over a year ago. This is ridiculous.

Hi, I am experiencing an issue where Xcode displays a "Provisioning profile doesn't support the capability" error for the User Assigned Device Name capability, despite it being approved by Apple and visible in our provisioning profile on the Developer Portal. Background We have completed and submitted the required capability request form to Apple for the User Assigned Device Name capability and received approval. The capability appears correctly in our provisioning profile on the Apple Developer Portal and shows among the enabled capabilities alongside other standard capabilities like In-App Purchase and Push Notifications. Issue However, Xcode consistently displays the error message when trying to enable the User Assigned Device Name capability in our project settings, preventing successful builds with this functionality. Troubleshooting Steps Attempted We have tried multiple troubleshooting steps including: Regenerating provisioning profiles Performing clean builds Clearing DerivedData Manually installing profiles Adding the com.apple.developer.device-information.user-assigned-device-name entitlement manually to our entitlements file Toggling automatic signing on and off Environment Details Xcode Version: 16.4 (16F6) iOS Deployment Target: iOS 13 Profile Type: Distribution provisioning profile Capability: User Assigned Device Name Despite the capability being approved by Apple and visible in our provisioning profile, Xcode does not recognize it. This appears to be a synchronization issue between the Apple Developer Portal and Xcode's capability validation system. Has anyone encountered similar issues with recently approved capabilities, specifically the User Assigned Device Name capability? Could you please provide guidance on how to resolve this capability recognition issue? Any suggestions for resolving this discrepancy between the Developer Portal and Xcode would be greatly appreciated.

Hello Apple Developer Community, I'm experiencing a persistent issue with App Groups configuration for an iOS app extension that I can't resolve despite trying multiple approaches. I hope someone can help identify what I'm missing. Problem Description I'm getting this error when trying to build my iOS App Extension: Provisioning profile "iOS Team Provisioning Profile: com.idlrapp.Spleeft.SpleeftDataSaver" doesn't include the com.apple.developer.app-groups entitlement. My Setup Main App Bundle ID: com.idlrapp.Spleeft Extension Bundle ID: com.idlrapp.Spleeft.SpleeftDataSaver App Group ID: group.com.idlrapp.spleeft.shared Extension Type: Action Extension (Share Sheet) What I've Verified App Group Creation ✅ Created App Group group.com.idlrapp.spleeft.shared in Apple Developer Portal ✅ App Group shows as "Active" in the portal App ID Configuration ✅ Both App IDs (com.idlrapp.Spleeft and com.idlrapp.Spleeft.SpleeftDataSaver) have "App Groups" capability enabled ✅ Both App IDs are configured with the same App Group: group.com.idlrapp.spleeft.shared Entitlements Files Main App (Spleeft.entitlements): <key>com.apple.developer.app-groups</key> <array> <string>group.com.idlrapp.spleeft.shared</string> </array> Extension (SpleeftDataSaver.entitlements): <key>com.apple.developer.app-groups</key> <array> <string>group.com.idlrapp.spleeft.shared</string> </array> Xcode Configuration ✅ Both targets use "Automatically manage signing" ✅ Same Apple Developer Team selected for both ✅ App Groups capability shows correctly in Signing & Capabilities for both targets The Issue When I examine the downloaded .mobileprovision file, I can see it contains: <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.idlrapp.spleeft.shared</string> </array> <!-- Other entitlements... --> </dict> However, Xcode expects to find: <array> <string>group.com.idlrapp.spleeft.shared</string> </array> What I've Tried Multiple regenerations of provisioning profiles: Deleted all local provisioning profiles Toggled "Automatically manage signing" off/on Downloaded manual profiles from Developer Portal Verified App Group configuration: Double-checked App Group exists and is active Confirmed both App IDs have App Groups capability enabled Verified App Group assignment in both App IDs Entitlements cleanup: Ensured consistent App Group IDs across all files Removed duplicate/conflicting entries Clean builds and cache clearing: Product → Clean Build Folder Derived Data deletion Xcode restart Key Observation The provisioning profile contains com.apple.security.application-groups (which appears to be macOS-style) but Xcode expects com.apple.developer.app-groups (iOS-style) for the App Extension. Questions Is there a known issue with App Groups entitlement generation for iOS App Extensions? Should the provisioning profile contain com.apple.developer.app-groups instead of com.apple.security.application-groups? Is there a way to force regeneration of provisioning profiles with the correct entitlements? Are there additional steps required for App Extensions that differ from main apps? Any guidance would be greatly appreciated. This is blocking our App Extension development and we've exhausted our troubleshooting options. Thank you for your time and assistance.

New to working with xcode and building apps. I started last weekend, and deploying to my usb connected iPhone 16 was working great all week. Yesterday, I upgraded to a paid developer account to start using TestFlight, and I could no longer deploy to my phone. Failed to install embedded profile for com.spred.spred-alpha : 0xe800801a (This provisioning profile does not have a valid signature (or it has a valid, but untrusted signature).) i using automatic provisioning - not a custom provisioning profile. i have tried: deleting all the certificates in keychain for my developer account and recreating them, and also doing the same in the developer portal. logging out and logging back in with my developer id in xcode deleting the app bundle directory and all other associated files in the Xcode/DerivedData directory reinstalling Xcode cleaning my build directory and trying again. changing the bundle identifier to a new name. (It always matches the portal app name) Among other things. It just won’t work. I can run the app inn a simulator, but not get it deployed to my phone. what else can I do? The only things I can think of are that somehow Xcode is still stuck using the free account somehow, or that the free account cert originally used expired after 7 days, and now I’m in some stuck state.

Hi guys, I am new to publishing apps on Apple Store. I used python, pyside6, torch, pyinstaller to build an app for Apple Store. For codesigning, I used the correct "Developer ID Application" to sign the code. When I validate the .app file (codesign -vv --strict ), I got the following my_app.app: valid on disk my_app.app: satisfies its Designated Requirement Next, I used ditto to "ditto -c -k --sequesterRsrc --keepParent my_app.app my_app.zip" to zip it. Then, I submitted this my_app.zip file for notarization with "xcrun notarytool submit ..." and got the following "accepted" message. Received new status: Accepted Current status: Accepted............... [20:08:54.530Z] Info [API] Submission in terminal status: Accepted Processing complete After that, I want to staple it with "xcrun stapler staple my_app.app", but I got the following Could not validate ticket for my_app.app The staple and validate action failed! Error 65. To further investigate it, I ran "spctl -a -vvv my_app.app" and got my_app.app: rejected source=Unnotarized Developer ID origin=Developer ID Application... I don't know why this would happen after notarization accepted. Could someone help me understand this issue? Thanks!

Having reviewed every document, this has been going on for nearly two months. Originally, it was thought that the problem might be related to the fact I had created the developer ID signing certificate on an intel mac, and trying to import and use it on an M1 Mac-Mini. That turned out to not be the case. Completely started over with a new account (the company changed names), requested and was granted the entitlements we needed. Create a new CSR from this new m1 machine, created a Developer ID certificate, installed the certificate on this machine. But no matter what, the codesign fails. Troubleshooting Environment: Brand new Apple Developer account and Developer ID Application certificate (generated CSR on this Mac, installed cert and private key in login keychain) macOS build/signing machine, not running codesign as root Working from Terminal app in GUI session, not via SSH/cron Keychain & Certificate Chain: Verified Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ) certificate and private key are present in login keychain Verified certificate is marked as trusted and has a private key attached Developer ID Certification Authority present and trusted in System keychain (removed any extra from login) Evaluate certificate assistant shows everything is good Apple Root CA present and trusted in System keychain Set all trust settings back to System Defaults after testing with “Always Trust” No expired or duplicate Developer ID intermediates present codesign Troubleshooting: Ran: codesign --force --timestamp --options runtime --sign "Developer ID Application: Fidelis Security LLC (J4WGF5B6KZ)" ./fidelisevents Consistently received: Warning: unable to build chain to self-signed root for signer ... errSecInternalComponent Confirmed correct identity using: security find-identity -v -p codesigning (Shows my Developer ID Application cert as valid) Keychain order confirmed with security list-keychains Tried explicit --keychain argument in codesign (no change) Additional Steps Attempted: Downloaded and re-installed all relevant Apple intermediates/root certificates from https://www.apple.com/certificateauthority/ Rebooted the Mac and killed/restarted the securityd daemon Confirmed no use of sudo or root for codesigning Verified keychain is unlocked Checked that partition list grants access to codesign (set with security set-key-partition-list -S "apple:codesign:" -s -k "" ~/Library/Keychains/login.keychain-db) Attempted to codesign a copy of /usr/bin/true (same error) Ran codesign both with and without --timestamp, both on app bundle and binary Keychain Access showing: Certificate and private key present and linked Correct trust chain System keychain containing all Apple intermediates/roots No trust warnings or red Xs Downloaded the latest Apple CA and Developer ID Root certificates and installed those. None of the forum searches have helped. AI is likewise confused.

Hello Apple Developer Community, I'm experiencing a persistent issue with App Groups configuration for an iOS app extension that I can't resolve despite trying multiple approaches. I hope someone can help identify what I'm missing. Problem Description I'm getting this error when trying to build my iOS App Extension: Provisioning profile "iOS Team Provisioning Profile: com.idlrapp.Spleeft.SpleeftDataSaver" doesn't include the com.apple.developer.app-groups entitlement. My Setup Main App Bundle ID: com.idlrapp.Spleeft Extension Bundle ID: com.idlrapp.Spleeft.SpleeftDataSaver App Group ID: group.com.idlrapp.spleeft.shared Extension Type: Action Extension (Share Sheet) What I've Verified App Group Creation ✅ Created App Group group.com.idlrapp.spleeft.shared in Apple Developer Portal ✅ App Group shows as "Active" in the portal App ID Configuration ✅ Both App IDs (com.idlrapp.Spleeft and com.idlrapp.Spleeft.SpleeftDataSaver) have "App Groups" capability enabled ✅ Both App IDs are configured with the same App Group: group.com.idlrapp.spleeft.shared Entitlements Files Main App (Spleeft.entitlements): Extension (SpleeftDataSaver.entitlements): Xcode Configuration ✅ Both targets use "Automatically manage signing" ✅ Same Apple Developer Team selected for both ✅ App Groups capability shows correctly in Signing & Capabilities for both targets The Issue When I examine the downloaded .mobileprovision file, I can see it contains: However, Xcode expects to find: What I've Tried Multiple regenerations of provisioning profiles: Deleted all local provisioning profiles Toggled "Automatically manage signing" off/on Downloaded manual profiles from Developer Portal Verified App Group configuration: Double-checked App Group exists and is active Confirmed both App IDs have App Groups capability enabled Verified App Group assignment in both App IDs Entitlements cleanup: Ensured consistent App Group IDs across all files Removed duplicate/conflicting entries Clean builds and cache clearing: Product → Clean Build Folder Derived Data deletion Xcode restart Key Observation The provisioning profile contains com.apple.security.application-groups (which appears to be macOS-style) but Xcode expects com.apple.developer.app-groups (iOS-style) for the App Extension. The main app builds fine, but the extension consistently fails with this entitlement mismatch. Questions Is there a known issue with App Groups entitlement generation for iOS App Extensions? Should the provisioning profile contain com.apple.developer.app-groups instead of com.apple.security.application-groups? Is there a way to force regeneration of provisioning profiles with the correct entitlements? Are there additional steps required for App Extensions that differ from main apps? Any guidance would be greatly appreciated. This is blocking our App Extension development and we've exhausted our troubleshooting options. Environment: Xcode: [Tu versión de Xcode] iOS Deployment Target: [Tu target] Developer Account: [Paid/Individual/Team] Thank you for your time and assistance.

Hi, hoping someone can help here. I recently updated my Mac to macOS 15 (Tahoe) and am using Xcode 15+ (possibly 16). I’m working on a Flutter app and testing on a real iPhone device. Here's the situation: I’m using the free Apple Developer account. My signing certificate and provisioning profile both show as valid and active in Keychain and says "signing..." in Xcode. When I build and run the app from Xcode, it works completely fine on a simulator. But when I try to run the same project from VS Code using flutter run, whether on an simulator phone or my personal iphone, I get a code signing error, specifically: Failed to codesign Flutter.framework with identity... I believe the app is set to use the correct Team ID because it says my name and (team) (my team ID isBDKUKWVRBY), and I can see my certificate in Keychain under "My Certificates". What I’ve already tried: flutter clean pod install / pod update Manually selecting my team in Xcode Signing settings Restarting my machine and VS Code Confirming the same project builds on other machines Verified provisioning profile is assigned to the project in Xcode deleting and recreating a certificate I have even had AI inside VS code take a shot at it and that couldn't fix either My question: Why would VS Code / Flutter not be able to use the same certificate and signing setup that works in Xcode? Is this an issue with Flutter tooling on macOS 15, or do I need to reconfigure signing differently now? Any suggestions or fixes would be greatly appreciated!

I recently had to update my certificates for a project. I deleted a few old ones, and I currently have one Development certificate. I needed to create another Development certificate specifically, it's saying "Maximum number of certificates generated." I thought the maximum was two Development certificates? Has anyone else had this issue? Thinking it could be a stuck workflow or something like that.

I am able to sign my application when logged in to the machine, however when build is running in CI (Jenkins), I get this: "Warning: unable to build chain to self-signed root for signer.." We just renewed or certificates, so I am not sure about previous procedure, but it used to work without temporary keychain and stuff, I believe. What should be the recommended way to sign an application on CI? What keychain should we use? system? temporary? other method? Thanks, Itay

Once I have built my macOS .app and signed it I run notarytool using this simple shell script: #!/bin/sh ditto -c -k --keepParent "$1.app" "$1.zip" xcrun notarytool submit "$1.zip" --keychain-profile "Notary Profile for DeepSkyStacker" --wait xcrun stapler staple $1.app rm -f $1.zip How can I export that "keychain-profile" (notary profile) so I can use it in CI/CD actions? Clearly I don't wish to expose the full invocation of xcrun notarytool store-credentials.

I’m running into an issue where the com.apple.developer.storekit entitlement is not being included in provisioning profiles, even though my App ID is properly configured for In-App Purchase. Entitlements file: explicitly includes <key>com.apple.developer.storekit</key> <true/> Capability: In-App Purchase is enabled in the Apple Developer Portal and shows as “Enabled.” What I’ve tried: Automatic signing in Xcode → profiles generated, but missing com.apple.developer.storekit Manual signing → deleted and recreated provisioning profiles multiple times; entitlement still missing. Waited several hours for possible propagation. Verified that my in-app purchase products are set up correctly. Error message: Provisioning profile "iOS Team Provisioning Profile: zu.inniu" doesn't include the com.apple.developer.storekit entitlement Question: Has anyone else encountered this? Is there a step I might be missing to get StoreKit entitlements included in provisioning profiles, or could this be a backend issue that needs escalation through Apple DTS? This is blocking me from building my app for physical devices, so any guidance would be greatly appreciated. Thanks in advance!

Unable to notarize Electron-based application. All notarization attempts fail with "The signature of the binary is invalid" for main executable and Electron Framework, despite passing local codesign verification. ENVIRONMENT: macOS: 24.6.0 (Sequoia) Hardware: Apple M4 Max (arm64) electron-builder: 26.0.12 Electron: 36.9.5 (also tested 37.10.2, 38.2.0) Certificate: Developer ID Application: AS LIVE MEDIA SP Z O O Team ID: 2KJ532SU3G Certificate validity: Oct 7 2025 - Oct 8 2030 PROBLEM: Every notarization submission fails with identical error for two binaries: Contents/MacOS/PresentClic Desktop Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework Error message: "The signature of the binary is invalid." Architectures affected: Both x86_64 and arm64 CRITICAL CONTRADICTION: ✅ Local verification PASSES: $ codesign --verify --deep --strict "PresentClic Desktop.app" Result: valid on disk, satisfies Designated Requirement ❌ Apple notarization service FAILS: Error: "The signature of the binary is invalid" LATEST SUBMISSION ID: 11e1a452-4ea7-4562-ac8e-5e76c39eeb6c Local verification output shows all components validated: Electron Framework: validated ✅ All helper apps: validated ✅ All frameworks: validated ✅ Main executable: valid on disk ✅ Authority chain: Developer ID Application → Developer ID CA → Apple Root CA ✅ Timestamp: Present ✅ Runtime Version: 15.4.0 ✅ CONFIGURATION: Entitlements (build/entitlements.mac.plist): com.apple.security.cs.allow-jit: true com.apple.security.cs.allow-unsigned-executable-memory: true com.apple.security.cs.disable-library-validation: true com.apple.security.cs.allow-dyld-environment-variables: true com.apple.security.automation.apple-events: true Standard device/network/file entitlements Build configuration: hardenedRuntime: true gatekeeperAssess: false (tested both true and false) entitlements and entitlementsInherit: properly configured TROUBLESHOOTING STEPS ATTEMPTED (ALL FAILED): ✅ Updated electron-builder from 24.13.3 to 26.0.12 ✅ Downgraded Electron 38 → 37 → 36 ✅ Tested x86_64 and arm64 separately ✅ Regenerated certificate via Xcode (new cert generated 23/11/2025) ✅ Configured App Store Connect API for notarization ✅ Tested multiple entitlements combinations ✅ Manual component-by-component re-signing ✅ Removed all metadata files (._ files) ✅ Tested both ZIP and DMG formats ✅ Automatic electron-builder notarization ✅ Manual notarization via xcrun notarytool ✅ Custom afterSign hooks for re-signing ✅ gatekeeperAssess true and false ✅ Clean builds (removed dist/ directory) ALL attempts result in identical failure. Local codesign verification ALWAYS passes. QUESTIONS: Why does local codesign --verify pass but Apple notarization service fails? Is there a known issue with Electron Framework notarization on macOS Sequoia + Apple Silicon? 3. Are there undocumented requirements for Electron apps that could cause this? 4. Could this be a bug in the notarization service for this specific configuration? ADDITIONAL CONTEXT: Multiple notarization attempts over 24+ hours Different certificates, configurations, architectures - all fail identically No similar reports found in forums or GitHub issues Application functions correctly when Gatekeeper is bypassed This is blocking production distribution to macOS users This appears to be either: A bug in Apple notarization service for Electron apps An incompatibility between electron-builder 26 + Electron 36/37 + macOS Sequoia + Apple Silicon The fact that local verification passes but notarization fails suggests the issue is with the notarization service validation logic, not the actual code signatures. REQUEST: Need guidance on resolving this issue. Standard documentation and troubleshooting steps have not resolved the problem. Thank you for any assistance. Staszek Pliszko