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"

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

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)

On macOS 15.7.9 (24G830), arm64, using Xcode 16.4 (16F6), a locally built QA host fails to launch through LaunchServices using open -W. The recorded signature is ad hoc, with no TeamIdentifier; its only recorded effective entitlement is com.apple.security.app-sandbox=true. The historical launch returned -10810. Correlated logs report posix_spawn: Operation not permitted (errno 1). Host entry was not observed. A packaging revision embedded the same Info.plist in __TEXT,__info_plist. Recorded signature verification succeeded, but the next launch produced the same rejection. The responsible policy remains unidentified; these observations are not an independently validated minimal reproducer. What supported diagnostic procedure can identify the policy responsible for this rejection without disabling security protections or using an alternative launch route?

I'm a paid Apple Developer Program member. Apple Developer Support confirmed by phone that my account has no restrictions, but every development-signed app I install on my registered iPhone is rejected. Environment iPhone 17 Pro,1, iOS 27.0 (24A435), Developer Mode enabled Device registered and enabled in Certificates, Identifiers & Profiles Signed with Apple Development certificates (issuer: WWDR G3), iOS App Development profiles Error ApplicationVerificationFailed 0xe8008018: The identity used to sign the executable is no longer valid.On the device: "This app was not installed because its integrity could not be verified." Device log during installation installd(libmis): Performing online authorization. online-auth-agent: The server returned: {"actions":["REJECT_PROFILE"],"authorized":false,...} online-auth-agent: Permanently rejected profile: <hash, <profile UUID installd(libmis): No online authorization (0x2) installd(libmis): validation failed because of failing online authorization (-402620392)What I've ruled out Not certificate revocation: trustd reports OCSP status revoked=0 definitive=1 for the whole chain. Not app-specific: a brand-new, empty test app with a newly created App ID and a newly created development profile fails identically. Not certificate-specific: same result with two different Apple Development certificates, each in its own freshly generated profile (three profiles in total, all rejected). The provisioning profiles contain the device UDID and the signing certificate, and the app's entitlements are a subset of the profile's. Questions Under what conditions does the online authorization service return REJECT_PROFILE / authorized:false for a paid team whose account shows no restrictions? Is this a known issue with iOS 27 and development profiles? Since the device marks each profile as "permanently rejected", how can I restore authorization for my team on this device once the cause is fixed?

I would like to identify a supported, minimally scoped diagnostic method for a code-signature verification failure, without changing certificates, trust settings, or system protections. The command execution environment reported macOS 27.0.1, build 26A434. The following command was run against the standard system executable: /usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf It returned exit status 1 with: CSSMERR_TP_NOT_TRUSTED In architecture: arm64e.x1 The designated requirement displayed for the file was: identifier "com.apple.printf" and anchor apple The signature display reported Authority=(unavailable). Following TN3161, the CMS data was inspected structurally: it contained three certificate structures, whose recorded validity periods included the observation date. This was not a cryptographic or trust validation, and I do not treat the file as authenticated. My question is how to distinguish a certificate/trust rejection from inability to complete evaluation in the command's execution context. The documentation for SecStaticCodeCheckValidityWithErrors describes detailed errors, and kSecCodeInfoTrust describes access to the trust object used in code-signature evaluation. Is either a supported diagnostic route for this system executable and architecture? If so, please identify the required flags, prerequisites and minimum non-sensitive result fields. In particular, I do not want to change the strict or architecture coverage merely to obtain a passing result. No diagnostic using those APIs has been implemented or run. I am not asking to re-sign the system file, install certificates, reset trust settings, disable protections, or bypass validation. I would prefer an initial diagnostic that does not require private Keychain contents, broad system logs, or a full diagnostic archive. I understand that a diagnostic result or a successful information query would not by itself authorize execution or prove that the environment is safe.

Hello, We transferred an app from Team A to Team B. The app is live on the App Store, and every build currently in circulation was signed by Team A. Team B has not released any update — no App Store release and no TestFlight distribution — and the app may stay in that state for a considerable time. The distribution certificate and provisioning profile that Team A used to sign the build which is live right now will expire. We would like to confirm that this has no effect on sign-in and no effect on payments for the version that users already have installed from the App Store. Reasoning that applies to both The App Store re-signs the app as part of the distribution process, and the delivered build contains no embedded provisioning profile (TN3125), so neither Team A's certificate nor Team A's profile exists on the device. "Certificates overview" also states that an expired App Store distribution certificate does not affect existing App Store apps, and only prevents uploading new builds signed with it — which the transferor can no longer do in any case. Sign-in Login tokens live in the keychain under an access group whose name is prefixed with Team A's App ID Prefix. Our reading is that certificate and profile expiry has no bearing on keychain access at all, because the access check compares the group string in the binary's entitlements against the item's kSecAttrAccessGroup, and the signing certificate is not an input to that comparison. Is that correct? Payments Our reading is that payments are unaffected on both sides: StoreKit transactions — purchases, renewals, refunds — are handled by Apple's servers and do not depend on the app's signing certificate or provisioning profile; our server-side receipt validation relies on the app-specific shared secret, a 32-character hexadecimal string with no relationship to any certificate, so receipt validation keeps working. Is that correct, or does something break here? One consequence we would like confirmed If Team A ever needed to publish another build under its own account, we assume it would first have to issue a new, valid certificate and provisioning profile — that is, expiry does not affect the installed app, but it does affect Team A's ability to publish anything further. Is that right? Thanks!

iOS app installation fails with 0xe8008018 for company team, but succeeds with another Apple Account Hello Apple Developer Community, We are facing a persistent code-signing issue while installing iOS development builds on a physical iPhone. We have contacted Apple Developer Support multiple times, but we have not yet received a technical explanation for the root cause. Environment Xcode: 26.6 (Build 17F113) macOS: 26.5.2 (Build 25F84) Device: iPhone 12 Pro Max (iPhone12,5) iOS: 26.5 (Build 23F77) Company Team ID: T6MQ4RXG46 Development certificate: Apple Development: Muthoot Money Limited (3MH4U8W7M5) Error message When installing the app through Xcode, installation fails with: 0xe8008018 — The identity used to sign the executable is no longer valid. The full error also contains: MIInstallerErrorDomain Code=13 CoreDeviceError Code=3002 IXUserPresentableErrorDomain Code=14 ApplicationVerificationFailed Troubleshooting performed Verified that the development certificate is within its validity period. Checked the provisioning profile's expiration date and confirmed that the test device UDID is included. Verified the app signature locally using codesign --verify --deep --strict. Confirmed that the app's signing authority and TeamIdentifier match our company team. Tested both our existing application and a newly created minimal iOS project named SigningTest. Important finding The newly created SigningTest app also fails to install when signed using our company team. However, the same test app installs successfully on the same iPhone when signed using another Apple Account's team. This suggests that the issue may be related to the company team's signing configuration or another team-specific factor, although we have not identified the root cause. Questions What could cause iOS to reject a locally valid app signature with error 0xe8008018? How can we identify the specific certificate, provisioning, trust, or device-verification check that is failing during installation? Is there any additional diagnostic command or device log we should collect? Could this indicate a team-specific signing issue that requires investigation by Apple? We would appreciate any technical guidance from developers who have encountered and resolved the same error. 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

Hello everyone, I’m running into a code signing validation failure when delivering a .NET MAUI Mac Catalyst app to App Store Connect via Transporter. I’d appreciate any help in figuring out what is misconfigured. Environment: .NET 9 MAUI (net9.0-maccatalyst) Build host: Mac Delivery tool: Transporter (App Store Connect) Issue: The packaging process itself appears to succeed and produces a .pkg file, but Transporter fails during validation with the following error: text The product archive package's signature is invalid. Ensure that it is signed with your "3rd Party Mac Developer Installer" certificate. (90237) Publish command: I’m publishing and signing from the command line, following Microsoft’s documentation for publishing .NET MAUI Mac Catalyst apps to the Mac App Store. bash dotnet publish -f net9.0-maccatalyst -c Release -p:EnableCodeSigning=true -p:EnablePackageSigning=true -p:CodesignKey="Apple Distribution: Ping Zhang (*********D)" -p:CodesignProvision="AideApp_MacCatalyst" -p:CodesignEntitlements="Platforms/MacCatalyst/Entitlements.plist" -p:PackageSigningKey="3rd Party Mac Developer Installer: Ping Zhang (Y2K7Q6HU4D)" -p:CreatePackage=true What I’ve checked so far: The 3rd Party Mac Developer Installer certificate is present in my keychain. The certificate has not expired. The certificate matches the correct team and App ID. The generated .pkg is what I’m uploading through Transporter. Questions: Is there anything wrong with the PackageSigningKey or CodesignKey parameters in the command above? Does .NET MAUI actually apply the 3rd Party Mac Developer Installer signature to the .pkg when EnablePackageSigning=true and CreatePackage=true are used? Should the CodesignKey be an Apple Distribution certificate, or should it also be a 3rd Party Mac Developer Application certificate for Mac App Store distribution? Are there any additional steps required to ensure the .pkg is signed correctly before uploading with Transporter? How can I verify whether the .pkg was signed with the correct installer certificate? For example, would pkgutil --check-signature be sufficient? Any guidance would be greatly appreciated. Thank you!

I just purchased the Apple Developer Paid Account on the 3rd of October to start development on an App and hasn't been able to use it even once I’m having an iOS code-signing/provisioning issue where development/Ad Hoc builds complete successfully, but the app cannot be installed on my registered iPhone. The same issue occurs with builds produced through both Xcode and Expo EAS Build, so at this point I don’t think this is specific to EAS. When installing the app on the device, iOS shows: Unable to Install “Sencard” This app cannot be installed because its integrity could not be verified. The device logs give a much more specific error. Environment Apple Developer account type: Individual Team ID: 26K9NDX728 Main bundle identifier: com.sencard.mobile Widget extension bundle identifier: com.sencard.mobile.widgets App Group: group.com.sencard.mobile Physical iPhone registered in the Apple Developer portal Expo SDK: 57 EAS distribution: Internal / Ad Hoc The same device is included in both provisioning profiles The issue also occurs when building/installing through Xcode The application contains a WidgetKit extension, so there are two targets: Sencard com.sencard.mobile ExpoWidgetsTarget com.sencard.mobile.widgets Both targets use the same Apple Distribution certificate, with separate provisioning profiles as expected. Current signing configuration I completely reset the signing credentials and let EAS regenerate them. Both targets now use the same distribution certificate: Distribution Certificate Serial: 64FE74F9A8F0091A81671D9CDE9F7CDB The main application has its own active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile Provisioning Profile: 7D9CS7B97R Status: active Registered device: included The widget extension has a separate active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile.widgets Provisioning Profile: DY3D63UHPX Status: active Registered device: UDID: 00008130-************001C EAS reports: All credentials are ready to build @sencard/sencard (com.sencard.mobile, com.sencard.mobile.widgets) The build itself completes successfully. Device-side failure I captured the device system log while reproducing the installation failure. The important part appears to be Apple’s online provisioning authorization service rejecting the profile: online-auth-agent: The server returned: {"actions":["REJECT_PROFILE"],"authorized":false,...} online-auth-agent: Permanently rejected profile This is immediately followed by: installd(libmis.dylib): No online authorization (0x2) installd(libmis.dylib): validation failed because of failing online authorization (-402620392) Then MobileInstallation reports: The identity used to sign the executable is no longer valid. and: Failed to verify code signature of .../Payload/Sencard.app 0xe8008018 (The identity used to sign the executable is no longer valid.) Finally: Verification stage failed and the installation fails. What seems particularly significant is that the device contacts the online authorization service successfully, but the response is explicitly: "actions":["REJECT_PROFILE"] "authorized":false Things I have already tried I have done a fairly extensive clean reset of the signing configuration: Deleted the existing Ad Hoc provisioning profiles. Removed the existing distribution certificates from EAS. Revoked the corresponding distribution certificates in the Apple Developer portal. Created a completely new Apple Distribution certificate. Generated completely new Ad Hoc provisioning profiles. Verified that the provisioning profiles show as active in EAS. Verified that both profiles contain the physical iPhone being used for testing. Verified that both targets belong to Apple Team 26K9NDX728. Configured both the main app and widget extension to use the same distribution certificate. Created separate provisioning profiles for: com.sencard.mobile com.sencard.mobile.widgets Confirmed the App IDs still exist in the Developer portal. Confirmed the App Group exists and is assigned correctly. Confirmed the registered iPhone is present in the Developer portal. Rebuilt the app from scratch after regenerating all credentials. Confirmed that the EAS build succeeds. Reproduced the installation failure again on the physical device. Captured the iPhone system logs using idevicesyslog. Reproduced the problem with Xcode as well as EAS. Initially, before resetting the credentials, I also encountered a build-time error similar to: Provisioning profile ... doesn't include signing certificate "iPhone Distribution: ... (26K9NDX728)" I then deleted and regenerated the certificates/profiles and ensured both targets shared the same distribution certificate. That resolved the build failure — the application now builds successfully — but the resulting application is still rejected by iOS during installation with the REJECT_PROFILE / 0xe8008018 error above. What I’m trying to determine Is there some server-side state associated with my Apple Developer team/account that can cause a newly generated, apparently valid Ad Hoc provisioning profile to be returned as: REJECT_PROFILE by Apple’s online authorization service? Specifically: What causes online-auth-agent to return REJECT_PROFILE for a newly created provisioning profile? Can an Apple Developer team/account get into a state where newly generated Development/Ad Hoc profiles are rejected by device-side online authorization? Is there any additional server-side reset or validation Apple Developer Support can perform for Team ID 26K9NDX728? Is error -402620392 associated with a specific provisioning/profile authorization condition? Is there anything else I should inspect in the .mobileprovision file or code signature to determine exactly why Apple is rejecting it? Since I can reproduce this with both Xcode and EAS, is there any known issue affecting Ad Hoc/Development profile authorization rather than the build tooling itself? At this point I’m reluctant to keep generating new certificates and provisioning profiles because I’ve already done a complete signing reset and the newly generated profiles are still being rejected. Any guidance on what REJECT_PROFILE means internally, or what Apple Support should check on the Developer account/team, would be greatly appreciated.

Hello, What is the supported revocation-status source or documented validation procedure for the following exact intermediate certificate, encountered in signatures on Apple-supplied Command Line Tools Python 3.9? This concerns first-party Apple code signing, not Developer ID, public TLS, or S/MIME. Certificate details Subject: CN=Apple Code Signing Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Serial: 0x21 (33 decimal) DER SHA-256: 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562 Validity: 2011-10-24 17:39:41 UTC to 2026-10-24 17:39:41 UTC Issuer: Apple Root CA Issuer DER SHA-256: b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024 Embedded CRL distribution point: http://www.apple.com/appleca/root.crl This intermediate has no Authority Information Access extension. Retained observations from 1 October 2026 At approximately 16:59 UTC, one request to: https://www.apple.com/appleca/root.crl recorded HTTP 200 and returned a 511-byte CRL with: thisUpdate: 2025-03-10 21:28:16 UTC nextUpdate: 2025-07-23 21:28:16 UTC SHA-256: 02b300d7e2edc09a33c0e98c0291da47932320761f6060ea8d7624f6e344f1dd At approximately 20:02 UTC, a separate request to: https://crl.apple.com/root.crl recorded HTTP 404 and returned a 287-byte HTML error body. This was an alternative HTTPS candidate; it does not establish the behavior of its HTTP counterpart. Neither request followed redirects or retried. Response bodies and normalized collector records were retained, but raw HTTP headers and stderr were not retained. These are limited observations from that date, not a claim about global service availability or key compromise. Questions Which current Apple-published source provides signed revocation-status evidence covering this exact intermediate? If the distribution point has moved, what is the authoritative replacement and how is its scope established? Which CP/CPS or documented first-party validation mechanism applies to this certificate? In particular, does Apple Certificate Policy v7.0 (20 March 2026), sections 2.1 and 4.10, cover this chain? If a public revocation-status service is no longer supported for this legacy first-party CA, what documented verification approach should be used, or which Apple team handles this question? I am not treating an expired CRL or an HTTP error as evidence that the certificate is revoked. I am also not assuming that a standalone CRL lookup reproduces macOS trust evaluation. I am asking for the supported source and verification procedure, not for a way to bypass validation, change trust settings, or re-sign Apple binaries. Thank you.

Hi everyone, I’m trying to get my iOS app running on a physical iPhone for real-device testing, but I’m blocked by a persistent code-signing issue in Xcode. The project compiles successfully, but when I select my physical iPhone as the destination, the build fails during the signing stage: errSecInternalComponent Command CodeSign failed with a nonzero exit code The app therefore never gets installed on the device. What I’ve checked: Xcode recognises my Apple Development certificate. security find-identity -v -p codesigning reports the identity as valid. The certificate is present in my login keychain. Keychain Access shows the certificate with its private key underneath it. My login keychain is unlocked. The keychain search list contains my login keychain and the System keychain. I checked both keychains for the corresponding private key. There are no custom trust settings. The particularly strange part is that signing fails outside Xcode too. I tested signing /usr/bin/true directly using the same Apple Development identity, and that also fails with: errSecInternalComponent I also attempted to repair the private key’s signing access/partition list, but received: The specified item is no longer valid. It may have been deleted from the keychain. Certificate situation Xcode → Manage Certificates currently shows two Apple Development certificates: One current certificate One older certificate marked “Not in Keychain” When I try to create a new Apple Development certificate, Xcode says: You already have a current Development certificate or a pending certificate request. This is the only Mac I have used with this Apple Developer account, so there isn’t another Mac from which I can recover or export the original private key. What should I do? I’m trying to understand the safest next step without making the certificate/keychain situation worse. Should I: Revoke the older certificate and create a new development certificate/private-key pair? Try to repair the existing signing identity/private key? Take another Apple-supported approach? The immediate goal is to get the app onto a physical iPhone so I can begin real-device testing, followed by QA/beta testing and App Store launch. Any advice on what is actually causing errSecInternalComponent in this situation, and the safest way to resolve it, would be greatly appreciated. I can provide additional Terminal output, screenshots, or Xcode logs if helpful. Thanks!

I am seeing a reproducible Developer ID code-signing issue on an Apple Silicon Mac running macOS 26.6.2. A Universal macOS app and its Quick Look extension (arm64 + x86_64) are signed with a newly issued Developer ID Application certificate using Hardened Runtime and a secure timestamp. Immediately after signing, all verification succeeds, including: codesign --verify --strict --verbose=4 and architecture-specific verification for both arm64 and x86_64. At this point, codesign reports: valid on disk satisfies its Designated Requirement The expected Developer ID authority chain and TeamIdentifier are present. However, after some time, without modifying the bundle or executable, the exact same Quick Look extension starts failing verification for both architectures: invalid signature (code or signature have been modified) codesign -d then reports: Authority=(unavailable) Info.plist=not bound The executable SHA-256, size, and mtime remain unchanged. I also copied the now-invalid extension to a different directory, creating completely new inodes. The copy remains invalid. I verified that: all regular files in the original and copy are byte-for-byte identical executable SHA-256 is identical _CodeSignature/CodeResources is identical there are no hard links (link count is 1) there are no extended attributes anywhere in the extension com.apple.provenance, com.apple.quarantine, and com.apple.FinderInfo are absent copying the bundle to a new inode does not restore signature validity The affected extension executable currently has: SHA-256: 3b36d1aca258a371311a9c94e93d10606edc184ea120dd252cf230a251c67243 CDHash arm64: 178ff5b7b2cedbed00ec6bc07536d168e22d9ba5 CDHash x86_64: ada914101f5b107704b78958520c904c4f022894 Signing environment Developer ID Team ID: XY2B8MLPV8 The Developer ID Application certificate is newly issued with a new RSA 2048-bit private key. I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK No new occurrence of that error is logged when subsequently verifying the already-invalid extension. Troubleshooting already performed I have: issued a completely new Developer ID Application certificate with a new RSA 2048-bit private key verified the certificate chain and code-signing policy successfully reproduced related Keychain/identity problems in a fresh macOS user account tested with a newly created independent Keychain tested in Safe Mode reinstalled macOS without erasing user data Before reinstalling macOS, even security find-identity -v -p codesigning eventually failed to recognize otherwise valid Developer ID identities. After reinstalling macOS, security find-identity -v -p codesigning correctly reports all identities again. I then performed a durability test using the new Developer ID identity on a minimal Universal Mach-O binary. Verification succeeded: immediately after signing after approximately 2 minutes after approximately 5 minutes after copying the binary to a different directory The minimal binary remained valid throughout. However, the problem subsequently reproduced with the actual Quick Look extension. Notarization The application was packaged in a Developer ID Installer-signed PKG and submitted to Apple Notary Service. The submission was Accepted, stapling and validation succeeded, and Gatekeeper accepted the notarized PKG. Notarization submission ID: 54dc0de7-5089-4b8c-9c10-b5a74df8df97 I initially suspected the packaging process, but I subsequently found that the original pre-PKG Quick Look extension itself had become invalid. Therefore, this does not appear to be caused by PKG creation or extraction. Questions What could cause a Developer ID signature that initially verifies successfully to become invalid later when the signed files themselves have not changed? Is there a Security.framework / codesign diagnostic that can show exactly which part of the CMS signature or CodeDirectory validation is failing? Are there any known macOS 26.x issues involving code-signing validation or CSSMERR_CSP_INVALID_KEYATTR_MASK that could explain this behavior? I would be happy to collect additional Security logs, codesign diagnostics, or a sysdiagnose if that would help identify the cause.

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively. Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established. Observed results: The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates. It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network activity is absent. One SecTrustEvaluateWithError call returns false. The top-level CFError and its single kCFErrorUnderlyingErrorKey child both report NSOSStatusErrorDomain / -26276. The child has no further underlying-error key. This designated key chain was collected completely; other userInfo and localized descriptions were not collected. A prior recorded evaluation returned a chain containing only the signer. The latest diagnostic did not request another evaluated chain. Supplied certificates and the evaluated/trusted chain are distinct observations. Separate metadata collection found three distinct supplied certificates within their validity intervals at the observation time. Issuer/subject names matched signer → supplied issuer → third certificate, and the third had equal issuer/subject names. This does not verify issuer signatures, CA purpose, or root trust. Existing independent codesign --verify --deep --strict verification exits 1 with CSSMERR_TP_NOT_TRUSTED for arm64; it does not identify the failing certificate. The extraction/trust helper does not validate the CMS/CodeDirectory signature. The public SecTrust header allows false both for denied trust and for an evaluation that cannot complete. The inspected installed SecBase header defines errSecInternalComponent as -2070 and errSecDecode as -26275; it provided no name for -26276. I am not treating -26276 as either code or as proof of certificate/profile damage, sandbox denial, or trust-service failure. Questions: What supported interpretation or specific conditions explain -26276 on this public Code Signing API path, including the underlying error repeating the same domain/code? What smallest independent public field or observation distinguishes policy rejection from evaluation failure while keeping the policy, intermediate-fetch=false, and trust settings unchanged? The underlying key chain supplies no more specific code. How should this be interpreted alongside CSSMERR_TP_NOT_TRUSTED from strict verification of an archived iOS app? What specific evidence separates an embedded-signature/signing-input defect from a local trust or evaluation-context failure and justifies a targeted correction? No certificate names, fingerprints, DER, profile identifiers, account details, private paths, raw payloads, or attachments are included.

My two apps, com.qrafter.Qrafter and com.qrafter.QrafterPro, have been on the iOS App Store since 2011, and their App IDs still use my team's unique App ID prefix 99T3FA87E9 instead of the Team ID GH4CGS3B5H. I'm adding native Mac versions to the same App Store records (universal purchase), so the bundle IDs can't change. Every profile Apple generates for these App IDs pairs com.apple.application-identifier = 99T3FA87E9.com.qrafter.Qrafter with com.apple.developer.team-identifier = GH4CGS3B5H. iOS uploads are accepted, but Mac App Store validation (xcrun altool --validate-app -t macos) rejects even a minimal one-window app with exactly two errors: Invalid code signing entitlements. … the "99T3FA87E9.com.qrafter.Qrafter" value for the com.apple.application-identifier key … isn't supported. This value should be a string that starts with your Team ID, followed by a dot ("."), followed by the bundle ID. (90286) Invalid Provisioning Profile. … Invalid 'com.apple.application-identifier' entitlement value. (91130) Following "Code Signing Identifiers Explained" (thread 811970), I requested the prefix migration through Contact Us on 4 September (case 102953576372). On 20 September Developer Support asked me to confirm the one-time keychain data loss described in "App ID Prefix Change and Keychain Access" (thread 706128), and I confirmed. Since then the case has had no reply despite follow-ups on 24 and 29 September, and as of 6 October both App IDs still show 99T3FA87E9. Two questions: Is there anything else I need to do to get case 102953576372 completed, or a better route to escalate it? Is there any way to ship a Mac App Store build for these App IDs before the migration, or is the migration the only path? I have a minimal sample project and the full validation log if that helps.

Summary A third-party PKG installer that ships a custom Installer Plugin no longer displays one of its selection panes. The plugin bundle appears not to be loaded, so the pane that it provides is silently skipped and the user cannot choose the intended installation option. This behavior started with recent macOS releases and did not occur on the immediately preceding versions, so it looks like a regression. Environment Machine: MacBook Pro 14-inch (M3) Affected builds: macOS 27.0 (26A428) macOS 26.7 (25G229) macOS 15.8 (24H23) Not affected: macOS 26.6 and earlier macOS 15.7 and earlier Reproducibility: every time Plugin binary: Mach-O 64-bit bundle, x86_64 only (no arm64 slice) Steps to Reproduce Download the Epson iProjection Ver.4.04 installer from the vendor support site: https://support.epson.net/setupnavi/?LG2=EN&OSC=MI&PINF=vpapp&MKN=EB-770Fi Mount the downloaded disk image and run the PKG installer. Step through the installer GUI and observe the pane transitions. Expected Result The installer GUI shows the "Application type" selection pane provided by the bundled Installer Plugin. Actual Result The "Application type" pane is never shown. The installer proceeds as if the plugin did not exist, and the user cannot select the installation type. What I Checked 1. The plugin is present inside the PKG pkgutil --expand-full PKG_PATH DEST_DIR The expanded payload contains the plugin bundle and its Mach-O executable under Contents/MacOS. 2. Architecture of the plugin binary file DEST_DIR/PluginName.bundle/Contents/MacOS/PluginName Result: Mach-O 64-bit bundle x86_64. It is a single-architecture binary with no arm64 slice. 3. The plugin is actually touched at install time sudo fs_usage -w -f filesys InstallerRemotePluginService-x86 opens the plugin executable inside the installer's temporary directory (a path under /private/tmp/com.apple.installer* ). So the plugin is reached as a load target, but the pane still does not appear. 4. Code signature validation When the installer is launched directly from the mounted disk image, code signature validation fails with: Too many levels of symbolic links My working theory is that the bundle contents are turned into symbolic links when the plugin is expanded, and that this causes codesign validation to fail, so the plugin is rejected before it can register its pane. 5. Code evaluation by syspolicyd log stream --info --debug --predicate 'process == "syspolicyd"' GK package assessment, GK process assessment and GK performScan entries are present, so Gatekeeper evaluation itself is running. The following also appears: Error Domain=NSOSStatusErrorDomain Code=-67062 Unsigned code in: PST: (path: REDACTED), (team: (null)), (id: (null)), (bundle_id: (null)) The PST path is anonymized in the log, so I could not confirm that this particular assessment refers to the plugin bundle. 6. XProtect evaluation results differ between versions log stream --info --debug --predicate 'process == "syspolicyd"' On the versions where the installer works correctly, the GK Xprotect results lines explicitly include a file URL pointing at the plugin bundle inside the installer temporary directory. On the affected builds, searching the same log for the plugin bundle name returns zero matches. That suggests the bundle is not being processed as an XProtect evaluation target at all on the newer builds. Question Was there a change in how Installer Plugins are expanded or validated in these releases, in particular around symlinked bundle contents or single-architecture x86_64 plugins? Any guidance on the supported way to ship an Installer Plugin so that it is still loaded on current macOS would be appreciated.

Hi everyone, I am developing an iOS companion app with an integrated watchOS component (a golf swing tracking tool using CoreMotion). I have run into an issue where the watchOS app gets stuck indefinitely in the "Installing..." state and never finishes installing on the physical Apple Watch. Environment (All on latest public releases): Xcode Version: Latest release (Xcode 18.x) macOS Version: Latest release (macOS Sequoia / latest version) iOS Version: Latest release (iOS 20.x) watchOS Version: Latest release (watchOS 13.x on Apple Watch Ultra 2) Deployment Target: Matched to latest minimum deployments Signing: "Automatically manage signing" enabled with an active Apple Developer Program account Steps to Reproduce: Connect the iPhone to the Mac via a physical cable. Select the iOS target in Xcode and successfully run/install the companion app onto the iPhone. Launch the stock Watch app on the paired iPhone. Scroll down to the "Available Apps" section, locate the development app, and tap "Install". The circular progress indicator starts spinning with the status "Installing...", but it remains in this state indefinitely (waited over 2 hours) without ever completing, timing out, or surfacing an error alert on either the iPhone or the Apple Watch. Troubleshooting Already Verified: Bundle ID Hierarchy: iOS App: com.company.appname Watch App: com.company.appname.watchkitapp Both targets share the exact same Development Team, signing certificate, and provisioning profiles. Developer Mode: Explicitly enabled and rebooted on the Apple Watch (Settings -> Privacy & Security -> Developer Mode). Also verified as enabled on the host iPhone. Connectivity & Cache: Cleared Xcode DerivedData (rm -rf ~/Library/Developer/Xcode/DerivedData). Performed hard reboots on both the iPhone and the Apple Watch to terminate any hung background sync daemons (installd / CoreDevice). Ensured both devices and the Mac are on the same Wi-Fi network with Bluetooth turned on. Questions: Under the current CoreDevice architecture, is installing local debug builds via the iPhone's stock Watch app still supported, or does it silently fail because the physical Apple Watch's UDID is not directly provisioned during an iOS-only build? Which subsystem in macOS Console.app (e.g., com.apple.dt.CoreDevice, com.apple.StreamingExtractor, or installd) is best for tracking the exact error/timeout code when the watch installation hangs? What is the currently recommended workflow to deploy and debug a paired watchOS target directly onto physical hardware? Any insights from the team or community would be greatly appreciated!

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.

I prepare a private project in Xcode, use Archive, Distribute/Copy, save the application somewhere. Copy it to my other computer, run. Works perfectly with normal MacOS applications. With Catalyst ones though it does not; whatever I try, all I get is “The application XXX cannot be opened”. What do I do wrong and how to fix the problem? Thanks!

I'm asking about how to ask for an addition to a managed entitlement, where we already have a grant of that entitlement (with a different value) and we already have other managed entitlements granted. This post https://developer.apple.com/forums/thread/789176 tells me I can request entitlements at the Requests tab here: https://developer.apple.com/account/resources/, which leads me to this form: https://developer.apple.com/contact/request/system-extension/ The form URL doesn't specify a particular App Identifier, but is the Identifier implied with this form submission? Or, put another way, is the entitlement we're asking for attached only to the Team ID, or also to the bundle ID of the app which is going to use the entitlement? So if I made another app which talks to my dext, I'd have to ask again for userclient-access to the same dext, but from a different bundle ID? The form says "Which DriverKit entitlements do you need" and "select all that apply", but I'm unclear about whether I need to request ALL the DriverKit entitlements we need for all our apps, or only for the specific App Identifier I reached this form from. It also isn't clear if I need to check both the USB Transport and the UserClient Access boxes in my case. We already have UserClient Access granted for at least one bundle ID, and I want to add another. We already have USB. Transport granted for two different vendor IDs. Do I need to mention that in my request here, and also check the USB Transport box, although I'm not requesting any new vendor ID values? I don't want to end up with new profiles which break new builds of existing apps which were relying on previously-granted entitlements that are now missing from the newly-generated profiles. Here: https://developer.apple.com/forums/thread/822652 user JackLongbow submitted a request for UserClient Access for two bundle IDs, presumably in the form of a simple two-line string like this: com.turing.TuringTouch com.turing.TuringTouch.TouchDriver but the resulting provisioning profile was malformed, it contained this value under com.apple.developer.driverkit.userclient-access <string>com.turing.TuringTouch com.turing.TuringTouch.TouchDriver</string> the Forum post said that the approved entitlement looks like this: <array> <string>com.turing.TuringTouch</string> <string>com.turing.TuringTouch.TouchDriver</string> <string>com.turing.TuringTouchDriver</string> <string>com.turing.virtualpad</string> <string>com.turingdraw.DigidrawTouch.DigidrawDriver</string> </array> Should I be formatting my request as above, as a chunk of xml, or is a plain text list of bundle IDs, one per line, acceptable? Is there a way for us to get a summary of all the managed entitlements already granted to our team? At present, it seems like I have to pick a particular profile, download it, and QuickLook at it - but not all profiles contain all entitlements, just as apps don't have to claim all the entitlements the profile offers .