I have an app Arpeggio.app which I build and then sign without errors: "electron-osx-sign dist/mac-arm64/Arpeggio.app --identity="Developer ID Application: XXXX (XXXXXX)" --hardened-runtime --no-gatekeeper-assess --entitlements=entitlements.plist". It returns "Application signed: dist/mac-arm64/Arpeggio.app". I then use "/usr/bin/ditto -c -k --sequesterRsrc --keepParent src dst" to make a zip with the same signatures. I then submit the zip for notarization: "xcrun notarytool submit dist/mac-arm64/Arpeggio.zip --apple-id XXXX etc" which returns "Waiting for processing to complete. Current status: Accepted.............. Processing complete id: xxx-xxx-xx-xx status: Accepted". Then I staple the notarization to the app and get "The staple and validate action worked!". Now it shows all validated and that the notarization is stapled. I then run "spctl --assess --type execute -vv 'dist/mac-arm64/Arpeggio.app'" as a last check and always get this: dist/mac-arm64/Arpeggio.app: unknown error 99999=1869f Why is this happening? I can't seem to debug the issue but out notarization and signing is always successful and the app works as expected. Pleas ehelp me get to the bottom of this.

One code signing issue I commonly see, both here on DevForums and in my Day Job™ with DTS, is that the codesign command fails with errSecInternalComponent. This issue crops up in a wide variety of circumstances and the correct fix depends on the specific problem. This post is my attempt to clarify the potential causes of this error and help folks resolve it. If you have any questions or comments about this, please start a new thread, tagging it with Code Signing so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving errSecInternalComponent errors during code signing In some circumstances the codesign command might fail with the error errSecInternalComponent. For example: % codesign -s "Apple Development" "MyTrue" MyTrue: errSecInternalComponent This typically affects folks who are signing code in a nonstandard environment, for example, when logged into a Mac via SSH or when signing code on a continuous integration (CI) server. This post explains how to resolve such issues, starting in the simplest case, signing from Terminal app, and then going on to discuss SSH and other contexts. IMPORTANT Before going further, make sure you understand the difference between a digital identity and a certificate. See TN3161 Inside Code Signing: Certificates for the details. Test from Terminal Code signing makes extensive use of the keychain, and that’s sensitive to the execution context in which it’s running. So, the first step in resolving this problem is to test your code signing from Terminal. To start, log in to the Mac using the GUI. Note If you don’t have access to the GUI, see Working without the GUI, below. Check that Keychain Access shows that your code signing identity’s certificate is trusted. Select the certificate and look for a green checkmark with the text “This certificate is valid”. If you see a red cross with an explanatory text like “… certificate is not trusted”, follow the instructions in Fixing an untrusted code signing certificate. Note macOS 15 moved Keychain Access out of the Utilities folder. The easiest way to find and launch Keychain Access is to use Spotlight. In Terminal, run the security tool to check that your code signing identity is available: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 valid identities found If the identity is missing from the Matching identities list, you don’t have a code signing identity to sign with. If you see your code signing identity’s certificate in the keychain, it’s possible that you’re missing its private key. See Certificate Signing Requests Explained for more about that issue. If the identity is shown in the Matching identities list but not in the Valid identities only list, see Fixing an untrusted code signing certificate. This example assumes that you’re testing with an Apple Development signing identity. If you’re using something else, you’ll see a different identity name in this list. Use that identity name in the codesign command below. Still in Terminal, make a copy of the true tool to use for this test: % cp "/usr/bin/true" "MyTrue" Try to sign it: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature The -f flag tells codesign to replace the existing signature. This command may display one or more keychain dialogs but, once you respond to those, it should correctly sign MyTrue. If it doesn’t, skip down to the Terminal failure section at the end of this post. Eliminate keychain alerts When you signed your code in the previous section, you may have seen one of two different types of keychain alerts: Keychain unlock dialog Access control list (ACL) dialog The keychain unlock dialog looks like this: codesign wants to use the … keychain. Please enter the keychain password. Password: [ ] [Cancel] [[OK]] The keychain containing your code signing identity is locked, and you must enter the keychain password to unlock it. You rarely see this dialog when logged in via the GUI because the system automatically unlocks the login keychain when you log in. However, the underlying cause of this alert will become relevant in the next section, when you log in via SSH. The ACL dialog looks like this: codesign wants to sign using key … in your keychain. To allow this, enter the … keychain password. Password: [ ] [Always Allow] [Deny] [[Allow]] The ACL for the your code signing identity’s private key prevents codesign from using the private key without your explicit approval. If you enter your password and click Allow, codesign can use the private key once. If you click Always Allow, the system adds codesign to the private key’s ACL so that it doesn’t have to ask again. To avoid this alert in the future, enter your keychain password and click Always Allow. Now repeat the codesign command from the previous section. It will sign the code without presenting any dialogs. Test over SSH Once you can sign your code in Terminal without seeing any dialogs, it’s time to repeat that process over SSH. To start, log out of the GUI and then log in via SSH. If you’re testing on a CI system, log in to that system by running ssh from Terminal on your Mac. If you want to test on your local Mac, choose one of these options If you have a second Mac, log in to that second Mac using the GUI, launch Terminal, and then run ssh to log in to your main Mac from there. If you have an iPad, use a third-party iPad SSH app to log in to your main Mac over SSH. Use a virtualisation app to run a macOS guest that you can treat like your CI system. Once you’re logged in over SSH, repeat the signing command from the earlier section: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature MyTrue: errSecInternalComponent This fails because: The system locked the keychain when you logged out of the GUI. Logging in via SSH does not unlock the keychain. When codesign tries to use your code signing identity, the system attempts to present the keychain unlock dialog. That fails because you’re logged in via SSH and thus don’t have access to the GUI. The system returns the errSecInternalComponent error to codesign, which reports it to you. To fix this, unlock your keychain using the security tool: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature IMPORTANT This assumes that your code signing identity is in your login keychain. If it’s in some other keychain, read the security man page to learn how to unlock a specific keychain. Best practice is to store both parts of your code signing identity (the certificate and the private key) in the same keychain. If you split the identity across two keychains, unlock the keychain that contains the private key. Test your CI job Once you have everything working on your CI system over SSH, try running exactly the same commands in your CI job. If your CI system manages user contexts correctly, those commands should just work. If they don’t, discuss this with your CI vendor. Note macOS has a complex execution context model. For background on this, see the Execution Contexts section of Technote 2083 Daemons and Agents. Some CI systems don’t correctly establish a user context when running jobs. For example, they might switch the traditional Unix execution context — the EUID, RUID, and so on — but not the security context. This mixed execution context causes problems for the keychain, which relies on the security context. Avoid doing code signing work as root. Some folks run everything as root because they think it’ll avoid problems. When working with the keychain the opposite is true: Running as root often causes more problems than it solves. These problems are most likely to show up when you use sudo, which creates a mixed execution context. Working without the GUI The instructions above assume you have access to the GUI so that you can test and resolve issues using GUI tools like Keychain Access. However, many CI systems don’t give you access to the GUI; at best you might have interactive access using SSH. Note If you CI system allows remote access using a screen sharing protocol, use that rather than messing around with the instructions here. If you don’t have access to the GUI of the machine on which you’re signing code, there are three issues to deal with: Avoiding the keychain unlock dialog Avoiding the ACL dialog Investigating an untrusted code signing certificate issue To unlock the keychain, use the unlock-keychain subcommand of the security tool, discussed in the Test over SSH section earlier. When logged in with the GUI, you can respond to ACL dialog by clicking Always Allow. This prevents that dialog showing up again. However, if you don’t have GUI access there’s no way to click that button. To get around this, import your signing identity and set its ACL to allow codesign to use it without extra authorisation. To do this, first unlock the keychain: % security unlock-keychain password to unlock default: KEYCHAIN_PASSWORD Then use the security tool to import the PKCS#12 file: % security import IDENTITY.p12 -T /usr/bin/codesign -P P12_PASSWORD 1 identity imported. Note the -T option, which adds codesign to the private key’s ACL. Finally, modify the partition list to allow access by Apple code: % security set-key-partition-list -S "apple:" -l "Apple Development: …" This example assumes you’re using an Apple Development signing identity to test with. If you’re using something else, replace Apple Development: … with that identity name. Finally, investigating an untrusted code signing certificate issue remotely is quite challenging. Your best option here is to set up a local test environment, run your investigation in that environment, and then apply the results to your CI environment. There are two good choices for your local test environment: Use a virtualisation app to create a ‘clean’ macOS guest, one that’s never seen your code signing setup before. Use System Settings > Users & Groups to create a new local user account and do your testing there. The first option is best because you can easily restore your VM to a clean state between tests. When running through the process described in Fixing an untrusted code signing certificate, you might end up performing two different remedial actions: Importing an intermediate Reseting trust settings. Once you understand these remediations, you need to apply them to your CI system. The first one is easy: To import an intermediate, run security with the import subcommand: % security import INTERMEDIATE.cer 1 certificate imported. Resetting trust settings is more of a challenge. It’s probably possible to do this with the security tool but, honestly, if you think that your CI system has messed up trust settings it’s easiest to throw it away and start again from scratch. Terminal failure The bulk of this post assumes that the process described in the Test from Terminal section works. If it doesn’t, something weird is happening and you should apply the following diagnostic suggestions. The first is to create a new local user account on your Mac — using System Settings > Users & Groups — and then retry there. The goal of this test is to isolate: A problem that affects your Mac as a whole From a problem that’s tied to your user account If the problem is with your user account, switch back to your original account and run: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. In most cases this should report that no trust settings were found. If it report trust setting overrides, remove them. See Check for a trust settings override in Fixing an untrusted code signing certificate. If that doesn’t resolve the issue, something else is afoot and I recommend that you seek dedicated help per the start of this post. Revision History 2024-10-05 Added the Terminal failure section. Made other minor editorial changes. 2022-08-12 Extended the unlock-keychain explanation to cover the split identity issue. 2022-08-11 First posted.

I am a developer on a project at work. I recently got a new laptop; however, since then I have been unable to build/deploy our application. I received a copy of the Developer ID Application certificate and Developer ID Installer certificate from a fellow developer. Note, everything works on their machine with these certificates. I have gone through the steps documented here https://developer.apple.com/forums/thread/712005 When I run security find-identity -p codesigning, I have two certificates that show up. one for my User and one for the Developer ID Application that my colleague gave me. Both show up as matching and valid identities. When I try to codesign "MyTrue", as documented in the link above, using "Apple Development" works; however, the "Developer ID Application" identity does not. I get a errSecInternalComponent error. ahenderson@ahendersonmacbook [17:29:23] [~/Downloads] -> % codesign -s "Apple Development" -f MyTrue -vvv MyTrue: replacing existing signature MyTrue: signed Mach-O universal (x86_64 arm64e) [MyTrue] ahenderson@ahendersonmacbook [17:30:48] [~/Downloads] -> % codesign -s "Developer ID Application" -f MyTrue -vvv MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Developer ID Application: SRS Pharmacy Systems, Inc. ([REDACTED])" MyTrue: errSecInternalComponent I have downloaded all of the intermediate certificates from the apple PKI and have them installed under my keychain in login. Having spent days on this, I am at the end of my rope. Laptop Specs: M3 Pro 36GB Ram MacOS Sequoia 15.1 It is worth noting that my colleagues laptop is not running Sequoia. Not sure if that makes any difference or not. It is also worth noting, that I can run the codesign manually with the Developer ID Application using sudo (I know I shouldn't do this, but I just wanted to see if that made any difference).

Hello, I was trying to solve the error "Command CodeSign failed with a nonzero exit code" that occurs when I try to archive and publish my app. I realized the Team IDs on the Portal (To right corner next to my name eg "Pete Park - ABC1D2E334") and my Mac Keychain Acces (eg "Pete Park - XYZ9W8V776") do not match. The number on KeyChain Access, is that's a Team ID. (clueless self learner here) If yes, do they need to match? Any suggestion for the CodeSign error? Is "errSecInternalComponent" the error? Sorry if these questions are obvious or stupid. Thanks so much for any advice.

Hi, I have been building a MacCatalyst versions of an iOS app for years using a separate build that included a specific .entitlements file that excludes the com.apple.security.device.camera. Yet when I now build with Xcode 16.1 that entitlement is included. I have double checked my signing entitlement for my MacCatalyst build it is configured properly. I have check my .entitlement file to ensusre com.apple.security.device.camera is not there. All is as it should be. I have changed nothing, my build flow is the same. App Store Review has prevented the Mac build to be release becuse the com.apple.security.device.camera is set. What can I do to correct this?

Hello Apple Community, many thanks in advance for your help. My macOS app embeds a Python interpreter, compiled from source, including the Python executable and its associated libraries. The top-level app is built with Xcode 16.1 and it's written 100% in Swift6. For test purposes we are running the app on MacOS Sequoia 15.0, 15.1 and Sonoma 14.4. The app can be downloaded via TestFlight and Console app shows the next errors: Crash Reports python3.11 Application Specific Signatures: Unable to get bundle identifier for container id python3: Unable to get bundle identifier because Info.plist from code signature information has no value for kCFBundleIdentifierKey. tccd process error Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for accessing={TCCDProcess: identifier=[IDENTIFIER]], pid=62822, auid=502, euid=502, binary_path=[PATH TO SAMPLEAPP]]}, requesting={TCCDProcess: identifier=com.apple.appleeventsd, pid=577, auid=55, euid=55, binary_path=/System/Library/CoreServices/appleeventsd}, The next documents were helping a lot to reach the current state althought sometimes I was not sure how to apply them in this python interpreter context: Signing a daemon with a restricted entitlement Embedding a command-line tool in a sandboxed app XPC Rendezvous, com.apple.security.inherit and LaunchAgent Placing content in a bundle There are a lot of details that I will try to explain in the next lines. Once archived the app, it looks like this: SampleApp.app SampleApp.app/Contents SampleApp.app/Contents/Info.plist SampleApp.app/Contents/MacOS SampleApp.app/Contents/MacOS/SampleApp SampleApp.app/Contents/Resources SampleApp.app/Contents/Resources/Python.bundle And this is how Python.bundle looks like: Python.bundle/Contents Python.bundle/Contents/Info.plist Python.bundle/Contents/Resources Python.bundle/Contents/Resources/bin Python.bundle/Contents/Resources/bin/python3.11 <- Python executable Python.bundle/Contents/Resources/lib Python.bundle/Contents/Resources/lib/python3.11 <- Folder with python libraries This is the Info.plist associated with Python.bundle: <dict> <key>CFBundleIdentifier</key> <string>com.sampleapp.app.Python</string> <key>CFBundleName</key> <string>Python</string> <key>CFBundleVersion</key> <string>1.0</string> <key>CFBundlePackageType</key> <string>BNDL</string> </dict> For some reason Bundle Identifier is ignored. Created a Python target and added to the main app, I selected the Bundle template. In Python target I made the next customizations: Enabled the Skip Install (SKIP_INSTALL) build setting. Disabled the Code Signing Inject Base Entitlements Added entitlements com.apple.security.inherit to it, with a Boolean value of true. Tried to set Other Code Signing Flags (OTHER_CODE_SIGN_FLAGS) build setting to: $(inherited) -i $(PRODUCT_BUNDLE_IDENTIFIER) But I had to remove it because I could not get rid of this error "-i com.sampleapp.app.Python: No such file or directory" Created a python.plist and set it in the Packaging Build Settings section. I set Generate Info.plist File to No In this document: Embedding a command-line tool in a sandboxed app Says: "Add the ToolX executable to that build phase, making sure Code Sign On Copy is checked." But I could not do it to avoid duplicates, since the bundle itself contains the executable too. I'm not sure how to handle this case. Tried to add python3.11 executable in the bundle MacOS folder, but bundle executableURL returned nil and I could not use python from the code. This is how I get Python bundle from code: static var pythonBundle: Bundle? { if let bundlePath = Bundle.main.path(forResource: "Python", ofType: "bundle"), let bundle = Bundle(path: bundlePath) { return bundle } return nil } Created Python.entitlements with the next key-values: <key>com.apple.security.app-sandbox</key> <true/> and it is used in an Archive Post-action of SampleApp, in order to sign the python executable of Python.bundle as follows: codesign --force --options runtime --timestamp --entitlements "$ENTITLEMENTS_PATH" --sign "$DEVELOPER_ID_APPLICATION" "$ARCHIVE_PATH" The reason of using an Archive Post-action is becauses signing from a Python.bundle Build phase was generating errors related to Sandboxing. These are the entitlements to codesign SampleApp: <dict> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-only</key> <true/> <key>com.apple.security.inherit</key> <true/> </dict> Most probably I was mixing concepts and it seems created some confusion. We would really love to get some advice, Thanks!

I am trying to set up a workflow where Apple Vision Pro users in my organization can install a signed enterprise .ipa file from an internal web page. The relevant link looks something like this: &amp;lt;a role="button" href="itms-services://?action=download-manifest&amp;amp;url=https://my.example.com/path/manifest.plist"&amp;gt;Click here to download&amp;lt;/a&amp;gt; After verifying that all the mime types were correct on the server and the certificate was valid, I finally attached my AVP headset to my Mac's console app and saw that the errors look like this: [com.example.myapp] Skipping due to incompatible platform: com.apple.platform.xros Could not load download manifest with underlying error: Error Domain=ASDErrorDomain Code=752 "Not compatible with this platform: com.apple.platform.xros" UserInfo={NSDebugDescription=Not compatible with this platform: com.apple.platform.xros} This manifest.plist was made by the "Distribute App" workflow in Xcode 16.0. Multipart question: Is installing VisionOS apps via manifest+ipa over a web connection a supported way of installing apps? If the issue is with com.apple.platform.xros, what should be the platform-identifier for VisonOS apps?

Creating CSR file from my Mac steps are :- Going to the Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority... Filling the required details in the field, save to desk then continue and save it desktop. Then going to the Developer account in Certification screen and creating a new certificate on click on plus icon then selecting Apple distribution > continue , Then uploading CSR file in the required box and continue. After this I have downloaded the “distribution.cer” file then double clicked on the file then going to the KeyChain Access to see the My Certificate section there is no certificate which I have installed but it showing in the Certificate section without Private key. This steps I have followed but not getting Private key in my certificate how to correct this issue System Configuration :- Mac OS- 14.5 Chip - Apple M1 Keychain Access version - Version 11.0 (55314)

Here is the situation: We are shipping an application bundle which is submitted to the notarization service for approval. The application bundle adheres to the notarization standards and is approved. Problem: We need to ship a zip file inside this application. This zip file has all the files that are signed. Most of the files are signed by us. However there are some 3P zip files which are not signed by us. We would rather not open these 3P zip files as there might be SLAs involved here. As a result we end up with a zip file which contains mixed signatures. This zip file needs to be part of that application that needs to be notarized. Question: What is the best way to do this in order for the notarization service to approve the application and ship the zip file as part of the application? Note: We don't know if all the files inside the 3P zips are correctly signed (example: With Hardened Runtime). They are all signed though Also, when the zip files contents are laid out onto the customer machine, they are all signed and validated. However, some files might not have hardened runtime. Thanks in advance.

Hi community! It is known that application designed for iOS may be launched on MacOS with arm chip. With XCode this is simple, you just choose to launch on current machine (Designed for iPad). As I can see, some magic happens: some tool wraps myproj.app into another app, which contains WrappedBundle link and Wrapper subdirectory. Does anybody know how to invoke this wrapping tool via command line? I am using CLion as IDE for my personal preferences, and I want to build app with CLion and wrap the result with external tool into a MacOS-compatible app to test if it works for MacOS as well. In other words, having the myproj.app I want to run something like "magictool -wrap /path/to/myproj.app" Best regards!

Hi, We have a series of apps all configured with Xcode managed signing. The only difference between them, except their code, is the build ID. In our CI, one app builds and exports without errors, while all the others fail. Authentication is done through keyID/keyFile/keyIssuerID triplet, but the Xcode installation on the CI machine has a bunch of those empty accounts in it as mentioned in this thread https://forums.developer.apple.com/forums/thread/764554. Looking at the xcodebuild archive logs, I have this for the "working" app : Default = "<_IDEProvisionableConfigurationSnapshot ✉️: name: Default, provisioningStyle: 0, certificateSigningStyle: 2, team: <IDEProvisioningBasicTeam: ✉️; teamID='<TEAMID>', teamName='MYTEAM'>, profileSupport: <IDEProvisioningProfileSupport: ✉️>, platform: <DVTPlatform:✉️:'com.apple.platform.iphoneos':<DVTFilePath:✉️:'/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform'>>, sdk: (null), sdkVariant: (null), bundleIdentifier: livetranslation.LiveTranslation, profileSpecifier: (null), certificateIdentifier: iPhone Distribution, entitlementsFilePath: (null), baseEntitlements: <IDEProvisionableEntitlements: ✉️; signedEntitlements='{\n}', simulatedEntitlements='(null)'>, entitlementsExpansion: <IDEDistributionProvisioningEntitlementsExpansion: ✉️>, entitlementsDestination: 1, allowSigningWithoutTeamSelection: 0, signingRequiresTeam: 0, appIDFeatures: <DVTPortalAppIDFeatures ✉️: Features: {\n}, Containers: {\n}>, provisioningPurpose: app-store, supportsIOSMac: 0>"; }, overrides: <IDEProvisionableOverrides ✉️: configuration: Default, profileSupport: <IDEProvisioningProfileSupport: ✉️>, provisioningStyle: (null), certificateSigningStyle: (null), provisioningPurpose: app-store, team: (null), platform: <DVTPlatform:✉️:'com.apple.platform.iphoneos':<DVTFilePath:✉️:'/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform'>>, sdk: (null), sdkVariant: (null), profileSpecifier: (null), certificateIdentifier: (null), bundleIdentifier: (null), entitlements: (null), entitlementsFile: (null), baseEntitlements: (null), entitlementsExpansion: (null), entitlementsDestination: (null), allowSigningWithoutTeamSelection: (null), signingRequiresTeam: (null), appIDFeatures: (null)>>>, configuration: Default, codesignParameterSnapshot: <IDECodesignParameterSnapshot: ✉️>: Identity: E1A91D4C347F60D4E8EFFAD9C8F2493AB99DFAFA Certificate <DVTSigningCertificate: ✉️; name='Apple Distribution: MYTEAM (TEAMID)', hash='E1A91D4C347F60D4E8EFFAD9C8F2493AB99DFAFA', serialNumber='1AE77EDC19294212C6AE6D5DC550D66C', certificateKinds='( "1.2.840.113635.100.6.1.7", "1.2.840.113635.100.6.1.4" ), issueDate='🕙''>>, errors: (null)> and this for the apps failing to sign : 🕙 [MT] Step failed: <IDEDistributionSigningAssetsStep: ✉️>: Error Domain=IDEDistributionSigningAssetStepErrorDomain Code=0 "Locating signing assets failed." UserInfo={NSLocalizedDescription=Locating signing assets failed., IDEDistributionUnderlyingErrors=( "Error Domain=DeveloperAPIServiceErrorDomain Code=5 \"Cloud signing permission error\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedRecoverySuggestion=You haven't been given access to cloud-managed distribution certificates. Please contact your team's Account Holder or an Admin to give you access. If you need further assistance, contact Apple Developer Program Support at https://developer.apple.com/contact/., NSLocalizedDescription=Cloud signing permission error}", "Error Domain=IDEProfileLocatorErrorDomain Code=1 \"No profiles for 'com.myteam.myapp' were found\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=No profiles for 'com.myteam.myapp' were found, NSLocalizedRecoverySuggestion=Xcode couldn't find any iOS App Store provisioning profiles matching 'com.myteam.myapp'.}" )} I've checked that the ID used to authenticate has cloud signing permissions (it obviously has them since it's working for one app). So what could be the problem here ?

I have a .NET MAUI iOS app where its provisioning profiles at first expired a few days ago. So I created new "Apple Development" and "Apple Distribution" certificates using an existing certificate signing request created on 19 October 2023 at 11:46 AM, included the new certificates in the expired provisioning profiles, regenerated and downloaded the provisioning profiles. In the "bundle signing" section of the "project properties" window of Visual Studio for Mac version 17.6.14 (build 413), I have made the following settings: Configuration: release Platform: any CPU Signing identity is not set to automatic I have selected the correct provisioning profile, but when deploying the app in release mode, the following error message is thrown so the app cannot be deployed to the device: ERROR: Failed to install the app on the device. (com.apple.dt.CoreDeviceError error 3002.) NSURL = file:///Users/intelligenthosting/Desktop/IMA-Attendance-App/maui/maui/bin/Release/net7.0-ios/ios-arm64/maui.app/ ---------------------------------------- Unable to Install ?IMA Attendance? (IXUserPresentableErrorDomain error 14.) NSLocalizedRecoverySuggestion = Failed to install embedded profile for com.imaedu.attendanceapp : 0xe800801f (Attempted to install a Beta profile without the proper entitlement.) NSLocalizedFailureReason = This app cannot be installed because its integrity could not be verified. ---------------------------------------- Failed to install embedded profile for com.imaedu.attendanceapp : 0xe800801f (Attempted to install a Beta profile without the proper entitlement.) (MIInstallerErrorDomain error 13.) SourceFileLine = 308 FunctionName = -[MIInstallableBundle _installEmbeddedProfilesWithError:] LibMISErrorNumber = -402620385 LegacyErrorString = ApplicationVerificationFailed 1%... 2%... 3%... 4%... 5%... 6%... 7%... 8%... 9%... 10%... 11%... 12%... 13%... 14%... 15%... 16%... 18%... 19%... 20%... 21%... 22%... 23%... 24%... 25%... 26%... 27%... 28%... 30%... 31%... 32%... 33%... 34%... 35%... 36%... 37%... 38%... 39%... 40%... 41%... 42%... 43%... 44%... 45%... 46%... 47%... 48%... 49%... 50%... 51%... 52%... 53%... 54%... 55%... 56%... 57%... 59%... 60%... 62%... 66%... 68%... error MT1045: Failed to execute 'devicectl': 'devicectl -j /var/folders/ny/qt1fm9zx063__j1b_nglx8pw0000gn/T/tmpFalYTp.tmp device install app --device "iPad (3)" /Users/intelligenthosting/Desktop/IMA-Attendance-App/maui/maui/bin/Release/net7.0-ios/ios-arm64/maui.app' returned the exit code 1. Application could not be uploaded to the device. What have I done wrong in the above process? What is the most appropriate method to update expired provisioning profiles? Thanks in advance

It requires a provisioning profile, and while I have one, I cannot select it within Signing & Capabilities since it is empty. On blank projects it works as intended, but whenever the Unity stuff gets imported, it just disappears entirely, making it impossible to export Unity Titles to visionOS.

App is signed, notarized and stapled, I send that dmg file with file transfer tool, it can open correctly on other mac without any warning or error. However, if I send that dmg file through IM to the same mac, it will produces the "cannot check it for malicious software" error. I check the transfered dmg with spctl -a -t open -vvv --context context:primary-signature MyApp.dmg, it show source=Notarized Developer ID; origin=XXX How can I resolve this issue?

Context/Project Idea: I'm currently developing a project that consists of a macOS application using Swift and a local Python backend that executes specific tasks such as processing data. The Python backend is the core of this project, while the Swift application is a mere interface to interact with it. These two project parts should be decoupled so the user can theoretically run their own backend and connect the Swift application to it. Likewise, the user should be able to connect to the shipped backend using, e.g. curl. Current plan: My main idea is to use launchctl to launch a launchd agent which runs the Python backend. The script launching the backend will generate an API key stored in a keychain access group. The Swift application can then get that key and access the backend. The user can always get that API key from the keychain if they want to connect to it programmatically. Here are the main questions I have currently: Python Interpreter Consistency: I'm exploring options such as cx_Freeze or PyInstaller to create a standalone Python executable for better system stability. Does anyone have experience with these tools in a macOS environment, or are there other reliable alternatives worth considering? Adding a Launchd Agent to Xcode: How can I add a launchd agent to my Xcode project to manage a Python executable built with cx_Freeze or PyInstaller? What steps should I follow to ensure it functions properly? Keychain Access for Launchd Agent: Is it feasible for a launchd agent to access a Keychain access group? What configurations or permissions are necessary to implement this? Thanks in advance!

When I try to launch my own Java app, I get the following error message. xpcproxy exited due to OS_REASON_CODESIGNING | Launch Constraint Violation, error info: c[5]p[1]m[1]e[0], (Constraint not matched) launch type 3, failure proc [vc: 1]: /bin/bash As far as I know, the failing process path is /bin/bash. This issue is only happening on macOS Sequoia. The Java app works without any issue on MacOS Sonoma or any previous macOS versions. I did not make any changes, including launch constraints or any other settings. After updating to macOS Sequoia, I started getting this error and can no longer launch my app. Thank you so much.

Hello, We are using automatic signing for a couple of projects, and we're struggling to get it to work in a CI with Xcode 16. It was working with Xcode 15 but with Xcode 16 we get the following errors : error: The operation couldn’t be completed. Unable to log in with account ''. The login details for account '' were rejected. error: Provisioning profile "iOS Team Provisioning Profile: com.bundleid.my" doesn't include signing certificate "Apple Development: Foobar (TEAMID)". Any ideas ?