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’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.

We maintain a macOS product whose installer uses custom InstallerSection plugin bundles to show configuration panes during install. Starting with macOS 27 beta 6, all of our plugins stopped loading in Installer.app — the panes never appear and the install fails because our preinstall step depends on data the panes collect. The exact same .pkg works on macOS 26.6, and per thread 842811 the same bundles were fine on 27 betas 1–4(I have tested it from beta 6 onwards). While investigating we found what looks like the underlying cause, and it's reproducible by hand. THE FINDING During a failing install, look inside the extracted plugin bundle while the Installer window is still open: ls -la /private/tmp/com.apple.installer*/.bundle/Contents/ That layout fails code-signature validation. You can reproduce the failure manually, no Installer involved: codesign -vvv "/private/tmp/com.apple.installer"*/.bundle → .bundle: Too many levels of symbolic links WHAT THE SYSTEM LOGS SHOW amfid rejects the plugin executable: /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/ not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" with repeated "UNIX error exception: 62" (errno 62 = ELOOP, too many levels of symbolic links) in backtraces through BundleDiskRep::component → SecStaticCode::component → validateNonResourceComponents → staticValidateCore, and "Code failed basic validity check (error: 100062)". For a Developer ID–signed plugin the kernel then treats it as fatal: AMFI: When validating /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/: The code contains a Team ID, but validating its signature failed. mac_vnode_check_signature: ... code signature validation failed fatally check_signature[pid: N]: error = 1 The plugin is never dlopen'd and the pane never appears. QUESTIONS Is there a way to get Installer to deploy the bundle with real files — or any other workaround? Note : I have Filed via Feedback Assistant as FB24601496; this overlaps FB24415432 / thread https://developer.apple.com/forums/thread/842811, which we've cross-referenced I have experienced this issue on latest Beta 8 build also -27.0 Beta (26A5425a)

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.

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.

Since our 1.3.20 update reached users on Sept 11, 2026, a handful of devices terminate at launch right after the App Store auto-update. Restarting the device does not help; deleting the app and reinstalling it from the App Store does. Filed as FB24755993 with 9 crash reports, the delivered package's SC_Info/Manifest.plist and a per-binary fingerprint. What the crash reports say (all identical) Exception Type: EXC_CRASH (SIGABRT) Termination: namespace DYLD, code 1, "Library missing" (terminated at launch; ignore backtrace) Library not loaded: @rpath/FBSDKCoreKit.framework/FBSDKCoreKit Referenced from: <DDB434B7-...> /Volumes/VOLUME/*/Runner.app/Runner Reason: tried: '/private/var/containers/Bundle/Application/<UUID>/Runner.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit' (could not register fairplay decryption, mremap_encrypted() => -1) Backtrace: dyld4::prepare -> dyld4::halt -> abort_with_payload Devices so far: iPhone XR / iOS 18.7.10 (22H374), iPhone 16 / iOS 26.6, iPhone 16 / iOS 18.7.7, plus one more not yet identified. The same package launches normally on the large majority of the ~12,000 devices that updated that day. Delivered Info.plist: DTAppStoreToolsBuild 27A261, DTXcodeBuild 17F113, MinimumOSVersion 15.0. What we established The main executable decrypts fine (dyld reaches dyld4::prepare); the failure is on the first @rpath framework in the load order, which is also the first FairPlay-encrypted embedded binary. It is not specific to the Facebook SDK. The package Apple delivers (pulled with Apple Configurator) is structurally consistent: every binary with LC_ENCRYPTION_INFO_64 has cryptid 1 and SC_Info/<name>.supp/.supf/.supx/.v4.supp/.v5.supf (main executable, App, Flutter, FBSDKCoreKit, FBAEMKit, FBSDKCoreKit_Basics, objective_c, sqlite3, the widget appex); the Firebase/Google frameworks are cryptid 0. SC_Info/Manifest.plist has SinfPaths = [SC_Info/Runner.sinf] and SinfReplicationPaths for all 12 binaries. Only the main Runner.sinf ships; the framework-level .sinf files have to be produced at install time from SinfReplicationPaths. The symptom looks like that replication not being applied to the frameworks after the delta update on the affected devices, while a fresh full install performs it. Nothing in our bundle changed between 1.3.19 and 1.3.20 except Dart code (App.framework): same Xcode 26.6 (17F113), same Flutter engine, byte-identical Facebook SDK 18.1.1 binaries (the only fat arm64+arm64e binaries in the bundle), same Firebase SDK. Both versions run normally from TestFlight and Xcode. The 1.3.20 encrypted variant carries SC_Info timestamps about 18 h after Ready for Sale, coinciding with the start of the auto-update wave. We could not obtain the delivered 1.3.19 package for comparison. Questions Has anyone seen this class of failure since early September, or with packages processed by DTAppStoreToolsBuild 27A261? Is there anything about a bundle (fat arm64+arm64e embedded frameworks? many encrypted frameworks?) that makes the framework .sinf replication on the delta-update path fragile? Is there any developer-side mitigation other than telling users to delete and reinstall? The closest earlier report I found is thread 718950 (2022, iOS 15.7–16.1, ~1 in 200 installs, "reinstall fixes it"); this looks like the same failure but concentrated on one update. fingerprint-1.3.20.json

I am new here. I am trying to do a build and run in Xcode. I keep getting a popup that says: code sign wants to access key "Apple Development: David Smith (David Smith" in your keychain. I have already granted access in keychain access, yet this popup persists. I have tried entering the keychain password and my Apple ID password; neither one works. How do I get around this?

Hello, I am very new to programming for iPhone, so please excuse me if this question is ignorant and I'm missing something silly. I am trying to build an app for my phone (iPhone SE 3rd gen) using my Macbook Air (same Apple Account). I downloaded XCode and started with the default "Hello World!" template. I created a personal team and figured out all the settings on my phone (trusted the computer, turned on developer mode, trusted the account). However, after uploading, I get the following error: The weird part is that I have a stable internet and cell connection. Following the instructions given to me in the similar error on my Mac, I head to General -> VPN and Devices -> my account and click "Verify App". This gives me a pop-up: Clicking Verify, it loads for a second and absolutely nothing happens. Not sure how to proceed or what's wrong.

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

Hello, I am trying to use XCode to generate a 'embedded.provisionprofile' file. My Xcode macos project keeps giving me an error saying: Provisioning profile "BRandNewMebedded" doesn't include signing certificate "Apple Distribution: Martin Barker (LV6WXG529F)". When I download the Provisioning Profile file "BRandNewMebedded" from online, I make sure it has "Mac App Distribution" checked, but even if i edit it to use the first option "Distribution" and re-download it, my XCode keeps saying the same error in red.

Installing a development build on a physical iPhone fails with: 0xE8008018 - The identity used to sign the executable is no longer valid. On the same Mac, same iPhone, same codebase and same Xcode, switching to a free personal Apple ID team installs and runs with no error. Only builds signed with our paid organisation team fail. Nothing else changes between the two runs. We have already regenerated certificates and provisioning profiles, deleted the profiles folder, cleared DerivedData, removed old identities from the keychain, trusted the profile on device, and tried both automatic and manual signing. None of it changes the result. We have also gone through the existing threads on this error and none of the suggested fixes apply. The build validates locally but the device rejects the identity. Since the signing team is the only variable between success and failure, what should we be looking at? A support case is open with Developer Support but we have not had a technical response yet.

Hi Apple DTS and community, My developer account's app has been granted the Default Mail App managed capability (com.apple.developer.mail-client). The capability works for Development and App Store Connect distribution, but it is not enabled for Ad Hoc distribution. This prevents us from using our Xcode Cloud “Archive & TestFlight” workflow: The archive succeeds. Development and App Store Connect exports succeed. Xcode Cloud then automatically attempts an Ad Hoc export. The Ad Hoc export fails, causing the entire archive action to fail and the TestFlight post-action to be skipped. The export log reports: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We have reproduced this in two consecutive Xcode Cloud runs. We also confirmed that: The App ID has the Default Mail App capability enabled. The entitlement is present and correctly spelled in the app’s entitlements file. The App ID’s provisioning support lists Development and App Store Connect, but not Ad Hoc. Our Xcode Cloud workflow does not expose an option to disable the automatically attempted Ad Hoc export. This appears to match these previous reports: https://developer.apple.com/forums/thread/774506 — a DTS engineer enabled Ad Hoc support for the entitlement, after which the developer confirmed the issue was resolved. https://developer.apple.com/forums/thread/800072 — DTS confirmed that the Ad Hoc distribution option must be enabled for the Default Mail App managed capability. We also opened an Apple Developer Support case (102945477410). Developer Support directed us to the forums and indicated that this issue would need to be handled by DTS engineers. I can provide our Team ID, Developer Support case number, Xcode Cloud run identifiers, and any other account details privately if needed. Thank you!

I have an app for iOS already on the AppStore and I'm trying to add a macOS version of it. The AppID prefix for this app is different than my Team ID. This mismatch was always fine for submitting my iOS app. However for some reason, the macOS version gets rejected when I upload it. It tells me the AppID prefix must match my Team ID. I do not control my TeamID and I do not control my AppID prefix, they are both given to me by Apple. Yet the error message tells me they must match. How do I get past this? Here is the error message: Validation failed Invalid code signing entitlements. Your application bundle's signature contains code signing entitlements that aren't supported on macOS. Specifically, the "APPID_PREFIX.MY_BUNDLE_ID" value for the com.apple.application-identifier key in "MY_PACKAGE" isn't supported. This value should be a string that starts with your Team ID, followed by a dot ('"), followed by the bundle ID. (ID: 930b77ae-099f-4798-a14a-2803f2a9be9e) Thanks in advance for any pointer.

Hello, We are experiencing an issue where our recent notarization submissions are stuck indefinitely in the "In Progress" status, and no notarization logs are available to inspect. Here are the details for our impacted submissions: Team ID: 34AC638RKM Submission ID 1: 18020127-4742-4d5f-8f56-9742e1aab766 (Submitted: 2026-07-31 13:22 UTC) Submission ID 2: f00b0f39-8b6e-4b80-aaad-dd1690cc7d85 (Submitted: 2026-07-31 21:23 UTC) Prior submissions in June were accepted without issue using the same build pipeline and signing configuration. Is there a known backend delay with the notary service, or can an Apple engineer assist in checking the status of these submission tickets? Thank you!

Hi everyone, We're migrating our iOS app from Auth0 custom scheme callbacks to HTTPS Universal URLs using ASWebAuthenticationSession. We've configured everything correctly, but webcredentials only works when using ?mode=developer suffix in our entitlements, which is not allowed for App Store submissions. The Issue Without ?mode=developer: Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=1 "Application with identifier com.example.myapp is not associated with domain auth.example.com. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for auth.example.com." With ?mode=developer: webcredentials:auth.example.com?mode=developer Works perfectly! Questions Why does it work with ?mode=developer but not without it, even though Apple's CDN has the correct AASA? Is there a way to force iOS to re-verify associated domains without requiring users to delete and reinstall? How will this affect existing users who update the app? Will they need to reinstall? Is there a known propagation delay beyond the CDN showing correct data? Any guidance would be greatly appreciated. We cannot ship to the App Store with ?mode=developer, but without it, the authentication fails. Thank you!

I came across your contact on the Apple Developer Forums. I'm encountering an unusual issue during the notarization process. The error message states: "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions." Any guidance you could provide would be greatly appreciated. Here are the error details for reference: json { "logFormatVersion": 1, "jobId": "b6023a7c-dc85-4fa5-91dd-fba92c9ed831", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, "archiveFilename": "Bytemonk.dmg", "uploadDate": "2025-07-02T07:07:07.945Z", "sha256": "b9494170cc040a76045ed263de22e6b89a5455142af16ce502530e1c1ee72ddf", "ticketContents": null, "issues": null }

All our workflows started to fail today due to timeouts - the notarization process is unable to finish in under 1 hour. The latest submission ID that failed after 45mins: 7449abcb-0d24-441b-a992-d5c7e7d279e3 It has never been a problem for us for the past years - is there something off on Apple side?

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

I work for a company which develops as part of our product suite a System Extension implementing an Endpoint Security client. Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds in to a VM, where to get the System Extension to load and be accepted we need to disable SIP & AMFI. macOS 27 VM is refusing to allow me to disable SIP. Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioningprofile) developer certificate for local validation?

I have run into an interesting topic today. So far, I have been under the impression that when I am using the setCodeSigningRequirement() function on an NSXPCConnection, I am completely removing any chance of receiving AND sending messages to untrusted XPC Peers. However, I created a malicious replacement for my daemon, and I wanted to check if my application can still send and receive messages to it. I checked with codesign --verify that the replacement does NOT fulfil the code signing requirement. I put a system log instruction in the malicious tool's XPC function. When calling the XPC Peer, I expected to see: XPC connection to <redacted> failed! [Error Domain=NSCocoaErrorDomain Code=4102 "The code signature requirement failed." UserInfo={NSDebugDescription=The code signature requirement failed.}] and I did. However, I also saw the system log from the malicious tool's XPC function. Then, I checked all XPC documentation, and I found for the original C implementation - xpc_connection_set_peer_code_signing_requirement() - the following in the discussion section: All messages received on this connection will be checked to ensure they come from a peer who satisfies the code signing requirement. For a listener connection, requests that do not satisfy the requirement are dropped. When a reply is expected on the connection and the peer does not satisfy the requirement XPC_ERROR_PEER_CODE_SIGNING_REQUIREMENT will be delivered instead of the reply. (this is in xpc/connection.h) which seems to align with the observed results. However, this is (embarassingly?) new for me, I would have never expected this, given how in my head pre-checking before any connection is made seems straightforward, even with public Apple SDK APIs: Grab a SecCode (not SecStaticCode) object of the daemon (malicious or not). This is running code, so it cannot be substituted between the check and the outgoing message. Perform validations on the SecCode object in some form - on macOS 15.0+ it's pretty easy with LightweightCodeRequirement's SecCodeCheckValidityWithProcessRequirement(). Immediately drop the connection if the peer is untrusted, before any message is sent. Am I overlooking something or making wrong assumptions here? or Am I right and this is something that I have to accept that's implemented less than ideally and I can perform above steps 1-3 myself and make a difference? Thanks in advance!