General: DevForums 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 Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained DevForums post --deep Considered Harmful DevForums post Don’t Run App Store Distribution-Signed Code DevForums post Resolving errSecInternalComponent errors during code signing DevForums post Finding a Capability’s Distribution Restrictions DevForums post Signing code with a hardware-based code-signing identity DevForums post Mac code signing: DevForums 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 DevForums post The Care and Feeding of Developer ID DevForums post TestFlight, Provisioning Profiles, and the Mac App Store DevForums 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 am working with a compiler that produces native binaries, It's really meant for servers so it's not integrated with Xcode or the Xcode build system. As such the output binaries get the default ad-hoc signatures the linker makes. After (re)compiling such a binary, there is a delay whilst running it. This is because macOS notices it's an unknown binary and goes off to ask notarization servers/Xprotect if it's known malware. Fine, I understand the need for this and why it happens. From the logs it's clear that macOS is now tracking the "provenance" of binaries. This means where they came from. This raises the question of whether it could know that my local dev binaries are coming from this compiler, if it was in turn properly signed and notarized. And if so, whether there is some security policy I could set to say "if binary X produces binary Y, then trust Y". Yes I know this would be a security exploit if it were done that way by default, but I am willing to take the risk of special malware that compiles itself first using this special compiler that isn't installed by default then runs the output, as presumably any such malware would be so targeted Xprotect/notarization wouldn't know about it anyway. The provenance mechanism is some internal security thing and isn't documented, but I'm curious if anyone knows more about it and whether it's usable for this? Or alternatively if there's a way to stop macOS doing these slow checks for certain binaries e.g. under specific paths?

I have signed and notarized a single executable file command line tool developed outside Xcode, and distributed outside of the App store by way of a download from a website as follows below, but nevertheless gatekeeper blocks running the tool with the usual message, just like without signing or notarization. If I remove the com.apple.quarantine xattr, the tool runs as it should without gatekeeper interference, as expected. I have browsed countless posts here, with similar issues, but in the end I can't find what's wrong with the process. From what I gather, as long as the target Mac is connected to the Internet, stapling should not be required (I do understand I can't staple a single file executable command line tool), although Gatekeeper would be expected to complain in the case of the first run being done without Internet connection. The certificate is a "Developer Id Application" certificate, installed and valid on the machine doing the signing. It is unclear to me what the distinction is between "Developer Id Application" and "Developer Id Installer" certificates, but it's confusing that using -t install with spctl will actually accept the app. The app is open source and available on GitHub (although the full distribution packaging is done in a separate build environment with some additional logic). The app used below as the target for signing and notarization is available to download from https://www.axantum.com/ in a .tar.gz archive. Here follows a log of commands and output: XecretsCli.plist: (This was necessary to add to the signing to avoid corruption of the executable by the code signing) codesign -s GCXRMT5SQC -f --timestamp -s 0CF6800E595AA6DE9EBB905066619A9BFDD17A77 --entitlements XecretsCli.plist -o runtime XecretsCli codesign -d -vvv --entitlements :- XecretsCli Executable=/Users/svante/Downloads/XecretsCli-Osx-2.3.567 3/XecretsCli Identifier=XecretsCli Format=Mach-O thin (x86_64) CodeDirectory v=20500 size=271478 flags=0x10000(runtime) hashes=8473+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b2 CandidateCDHashFull sha256=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b20c9e3c17e107f08c7ae75c5a Hash choices=sha256 CMSDigest=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b20c9e3c17e107f08c7ae75c5a CMSDigestType=2 CDHash=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b2 Signature size=8987 Authority=Developer ID Application: Axantum Software AB (GCXRMT5SQC) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Jun 20, 2024 at 13:26:05 Info.plist=not bound TeamIdentifier=GCXRMT5SQC Runtime Version=13.1.0 Sealed Resources=none Internal requirements count=1 size=172 Warning: Specifying ':' in the path is deprecated and will not work in a future release codesign -v -vvv --strict --deep XecretsCli XecretsCli: valid on disk XecretsCli: satisfies its Designated Requirement zip XecretsCli.zip XecretsCli adding: XecretsCli (deflated 63%) xcrun notarytool submit "XecretsCli.zip" --keychain-profile "Notarize" --wait Conducting pre-submission checks for XecretsCli.zip and initiating connection to the Apple notary service... Submission ID received id: e5990902-3101-42de-a1a6-b9ea40b944b8 Upload progress: 100.00% (12.4 MB of 12.4 MB) Successfully uploaded file id: e5990902-3101-42de-a1a6-b9ea40b944b8 path: /Users/svante/Downloads/XecretsCli-Osx-2.3.567 3/XecretsCli.zip Waiting for processing to complete. Current status: Accepted........ Processing complete id: e5990902-3101-42de-a1a6-b9ea40b944b8 status: Accepted spctl -a -vvv XecretsCli XecretsCli: rejected (the code is valid but does not seem to be an app) origin=Developer ID Application: Axantum Software AB (GCXRMT5SQC) spctl -a -vvv -t install XecretsCli XecretsCli: accepted source=Notarized Developer ID origin=Developer ID Application: Axantum Software AB (GCXRMT5SQC) Trying to run the executable: "XecretsCli" can't be opened because the identity of the developer cannot be confirmed. Your security preferences allow installation of only apps from the App Store and identified developers. Chrome downloaded this file today at 10:37. OK

Hello, I use setCodeSigningRequirement: in sandboxed XPCService and it seems that no matter what I always get errSecCSNoSuchCode[1] when the app is signed with development certificate. The same application signed with DeveloperID is fine. I use following CSR for development signed builds. identifier com.example.app and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.1] exists and certificate leaf[field.1.2.840.113635.100.6.1.12] exists But also tried to simplify to identifier com.example.app or just true. If I validated the CSR with codesign -R I get "explicit requirement satisfied". I spotted this log line: Sandbox: com.example.app(67058) deny(1) file-read-data /Users/(...)/example-app/build/arm64-mac/src/mac/app/Debug/Example App.app/Contents/MacOS/ExampleApp So I disabled the sandbox for XPCService and now everything works. But then why the DeveloperID signed build works with XPCService sandboxed? ...or does it really? :) Just for completeness the CSR which I use in production build are: identifier com.example.app and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists and certificate leaf[subject.OU] = EXAMPLE

I was developing an electron based app, and I want to embed a system extension in it, everything works fine with SIP disabled. But for normal cases, I found out: Notarization require hardened runtime enabled. The container is an electron based app, which has JIT related feature, so it requires hardened runtime relaxation entitlements (some exception) But System extension disallow these entitlements, this error message is captured from the log system: Hardened Runtime relaxation entitlements disallowed on System Extensions So does this mean we can't embed a system extension in an Electron-based app?

Hello,I have released macOS version of my game before iOS Version, after releasing macOS version, cannot run & debug my game on Xcode getting error ; Provisioning profile "iOS Team Provisioning Profile: com.codepad.motorush" doesn't include the com.apple.application-identifier entitlement. please take a look to screenshot view.

Hi, I want to resign my app with a different certificate. Is it possible to keep the entitlements (including com.apple.application-identifier)? I want to resign the whole app including the plugins and frameworks, but I saw --deep was considered harmful. Sorry, I'm a bit confused. Any help would be appreciated.

When I build with Flutter, XCODE returns an error:error: exportArchive: "Runner.app" requires a provisioning profile with the Associated Domains and Push Notifications features. I use the automatic management signing, and the provisioning profiles include related features. What should I do?

We have requested an additional capability called "User Assigned Device Name" for my application to Apple and got approved the same on for debug/adhoc/release environments . Since then we are facing issues on code signing. We are always getting the compiler error "* Provisioning profile "xxxxxxxxxxx" doesn't support the User Assigned Device Name capability." on both Debug and Release environment. There is another capability "contacts notes entitlements" that we got approved long back when it was not apart of Apple ID(additional capabilities) rather we got approved as a part of our provisioning profile. Suppose we removed "contacts notes entitlements" from the profile and deleted it from the entitlement folder the project compiled without any error. So we are strongly believes the conflicts on the "contacts notes entitlements" is the root cause. We are about to release the version and which is blocked due to this error. So kindly look in to this issue and do the needful asap. STEPS TO REPRODUCE Added user assigned device name capability from Signing & Capability Tab in project in settings. Added the team, valid provisioning profiles and try to sign in manually. Getting the error “Provisioning profile xxxxxxxxxxxx" doesn't support the User Assigned Device Name capability." Note: Already got approval for the “user assigned device name” . Which is listed under the app id.

Hello, I've developed an application using ElectronNET with C# and Blazor Server. I have managed to deploy to both Windows and the web but having trouble deploying the application to my Mac users. It's my first time deploying an application for Mac but feel like I'm stuck at the last hurdle and out of ideas so I'm reaching out for help. My application is successfully signing but during the build and when my Notarize.js is running it seems to get stuck indefinitely. I can check and see the status of the Notarize attempts but they seem to be stuck "In Progress". Here are the logs. Successfully received submission history. history -------------------------------------------------- createdDate: 2024-06-12T22:16:35.362Z id: 26192605-001b-46ae-b622-9a79c20e1e93 name: CustomerSupportDashboard.zip status: In Progress -------------------------------------------------- createdDate: 2024-06-12T18:51:21.772Z id: 6a34501c-8f48-4986-ae5e-82a99320dcbc name: CustomerSupportDashboard.zip status: In Progress -------------------------------------------------- createdDate: 2024-06-12T15:13:44.722Z id: ea5cd928-8207-4d25-b74a-45b04960dbe0 name: CustomerSupportDashboard.zip status: In Progress -------------------------------------------------- createdDate: 2024-06-12T14:24:48.776Z id: 00ccd1f9-daa4-4bba-9a86-9f577c51f26b name: CustomerSupportDashboard.zip status: In Progress -------------------------------------------------- createdDate: 2024-06-12T14:07:43.116Z id: bf5dfa9c-9702-413b-8fbb-94017e930bcf name: CustomerSupportDashboard.zip status: In Progress These have been running for over 6hours now and it's my understanding it should take minutes, correct me if I'm wrong? Here is my Notarize script if it helps diagnose what might be happening. Although the requests seem to be going through ok so it doesn't seem likely. const { join } = require('path'); const fs = require('fs-extra'); exports.default = async function notarizing(context) { const { electronPlatformName, appOutDir } = context; if (electronPlatformName !== 'darwin') { console.log("Not a macOS platform, skipping notarization."); return; } const appName = context.packager.appInfo.productFilename; const appPath = `${appOutDir}/${appName}.app`; const zipPath = `${appOutDir}/${appName}.zip`; console.log(`Zipping the app at path: ${appPath} to: ${zipPath}`); // Zip the app await new Promise((resolve, reject) => { execFile('zip', ['-r', zipPath, appPath], (error, stdout, stderr) => { if (error) { console.error(`Failed to zip app: ${stderr || stdout}`); reject(new Error(`Failed to zip app: ${stderr || stdout}`)); } else { console.log(`Successfully zipped app: ${stdout}`); resolve(); } }); }); console.log(`Notarizing the app with Apple ID: *************.*****@*******.****`); await new Promise((resolve, reject) => { execFile('xcrun', [ 'notarytool', 'submit', zipPath, '--apple-id', '*************.*****@*******.****', '--password', '****-****-****-****', '--team-id', '**********', '--wait', '--output-format', 'json' ], (error, stdout, stderr) => { if (error) { console.error(`Notarization failed: ${stderr || stdout}`); reject(new Error(`Notarization failed: ${stderr || stdout}`)); } else { console.log(`Successfully notarized: ${stdout}`); resolve(); } }); }); }; ```

When I trusted my certificate in 'Setting'->'VPN & Device Management', my device reboot automatically. After reboot, it showed that "developer of My Team is not trusted in this iPhone", but the app is "verified" in the second column. The UI looks like: iOS18 beta: First Col: Trust "My Team" Second Col: MyApp Verified Other versions: First Col: Delete App Second Col: MyApp Verified What's more, my app has plugins(extensions), my app can run normally while the extension is not able to be pulled up on iOS18 beta.

No Proxy for Xcode 15: _with Xcode 14 You can modify this file : /Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/java/conf/net.properties and set the following property to true ( false by default ) java.net.useSystemProxies=true_ With Xcode 15, I don't found any solution **Utilisation of environment variables http_proxy and https_proxy it's useless because it's ignored #** how I can define a proxy in order to sign with Xcode command lines ?

I have a bizzare issue with my Apple TV that is shown as "iPod" in Apple developer portal. It's correctly visible in Xcode as Apple TV, but when I add it to developer portal it says "iPod". The problem is since it's there as an iPod I can't use it to my provisioning profile to build on the device Anyone has any idea how this can be solved? [Edited by Moderator]

Hi, I am trying to release a small application which bundles a conda environment and a python script. I am using Platypus to turn it into a .app, and I include all necessary resources (libraries, binaries etc) inside the Resources directory. My application works correctly before code signing, and is portable between machines (so I don't think it is the case that the conda environment is missing something). However, after signing, it crashes when it runs one of the programs within the conda environment. I am first signing all .so, .dylib and all files in conda_env/bin as follows: # Within the conda environment directory in Resources find bin -type f | xargs -n1 codesign -f -o runtime --timestamp --sign "Developer ID Application: Whatever (123456789)" find . -name "*.dylib" -o -name "*.so" -type f | xargs -n1 codesign -f -o runtime --timestamp --sign "Developer ID Application: Whatever (123456789)" I am then signing the .app itself codesign -f -o runtime --timestamp --sign "Developer ID Application: Whatever (123456789)" my_app.app Finally, I convert it into a .dmg (with appdmg) and sign that. codesign -f --sign "Developer ID Application: Whatever (123456789)" --timestamp my_app.dmg I submit to the notary service, which succeeds, and then I staple the ticket to the .dmg: xcrun notarytool submit my_app.dmg --keychain-profile my_notarytool_keychain_id --wait xcrun stapler staple my_app.dmg spcl is happy with the signed .app and .dmg and accepts them both. spctl -a -vv my_app.app # my_app.app: accepted # source=Notarized Developer ID # origin=Whatever (123456789) spctl -a -vv -t install my_app.dmg # my_app.dmg: accepted # source=Notarized Developer ID # origin=Whatever (123456789) I have a valid Developer Application ID. All good, right? Except, during execution, the signed .app crashes. When I look in the Console, the error log always looks similar - something like: Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Termination Reason: Namespace CODESIGNING, Code 2 Invalid Page Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x186e15848 sys_icache_invalidate + 40 1 libllvmlite.dylib 0x2a022f8e8 llvm::sys::Memory::protectMappedMemory(llvm::sys::MemoryBlock const&, unsigned int) + 384 2 libllvmlite.dylib 0x29d765528 LLVMPY_TryAllocateExecutableMemory + 92 3 libffi.8.dylib 0x103abc04c ffi_call_SYSV + 76 etc I think all the .dylib, .so, and binaries are signed in my codesign scripts, except for the libsystem_platform.dylib mentioned in the first line of the log. Could this be the problem? How can I find if I am not signing something that is being used? Are there other types of files that I should be signing that I am missing? I've been trying to fix this for several days and I feel I have tried everything (constructing the conda env in different ways, signing in different ways, e.g. with/without --deep, with/without signing each type of library/binary) to no avail... Any help would be greatly appreciated! All the best, George

Hi, I'm having some problems signing my application. Everything was working fine until recently when the certificates expired and I got these kinds of errors when I try to upload the app to AppStoreConnect. I can build the app in dev and production mode without any issue and I can create an archive. Problems occur when uploading to AppStoreConnect. The idea would be to let Xcode take care of signing everything necessary by checking the "Automatically manage signing" box. All my targets are in "Automatically manage signing" mode. I tried to delete all the certificates and provisioning profiles that I found on the Apple portal and then generate them again, but the problem is the same. There are two of us on the team, plus a CI machine (this should be the CI that takes care of signing everything needed to send a release to AppStoreConnect). If you have an idea, I'm interested! Thanks in advance, Alexandre

I am having a peculiar issue with an app I am developing. I am trying to upload it onto App Store Connect but I am getting one error, and a very odd behavior. The error message I am getting is: /Users/user/Documents/GitHub/MyApp/MyApp/DerivedData/MyApp.pub/Build/Intermediates.noindex/ArchiveIntermediates/MyApp.pub/InstallationBuildProductsLocation/Applications/MyApp.pub.app: resource fork, Finder information, or similar detritus not allowed Command CodeSign failed with a nonzero exit code I have cleaned built the directory, I have removed the Derived Data, but this always gets thrown. It was working fine a few months ago, I have only just got back to working on it. The other issue I am havving, when I set to archive the app, I set the target as Any iOS Arm Device (arm64), but when it is archiving it switches to my iPhone as the target. I don't prompt it to do this, it just does it. This is very frustrating. I'm using a MacBook Air M1, with a macOS Sonoma. I updated my Xcode the other day, that's Version 15.4 (15F31d). My App has a minimum target of iOS 15 and a project target of Xcode 13. Any help is appreciated.

Hi Devs, i have a question concerning the security set-key-partition-list -S command. I want to use it to enable a code signing certificate being used by codesign and productbuild to sign without sudo or a password prompt. Some sources indicate i need to add codesign: as partition but some don't even mention this. So my question is what partitions are even possible to add? What does partitions in this context mean? How can i find out which i need for productbuild and codesign? Thanks in advance Paul

I have an app developed using ElectronJS that requires Accessibility permission to monitor mouse and keyboard events through the iohook package. I want to publish it on the Mac App Store, but it seems that: The Mac App Store mandates Sandboxing, and Sandboxing prohibits Accessibility permission. As a result, it seems that an app on the Mac App Store cannot obtain Accessibility permission. Can someone confirm if this is accurate or if there's a workaround?

(Skippable) Backstory: I have an app that customers initially install by: Going to our website in a browser, downloading a (notarized) disk image, mounting it, opening the (Developer ID-signed) installer package therein, and following the prompts to completion. Once installed, this app has a button you can click that will check for updates and possibly install them. When you click this button: Our app contacts an HTTPS API on our servers to see if there is an update If there is an update, the API responds with a download URL to the aforementioned notarized disk image, and the SHA-512 hash of the disk image Our app downloads the disk image, and verifies the SHA-512 hash of the download Our app mounts the DMG Our app uses /usr/sbin/pkgutil --check-signature (although I do hope to switch to SecStaticCodeCheckValidity() in the future) to verify that the OS thinks that the installer package is properly signed, and also that the organization unit on the leaf certificate for the code signing key used to sign the installer is exactly equal to our Apple Team ID Our app uses /usr/sbin/installer -package ... -volinfo to verify that the installer package thinks it can install onto the host Our app uses /usr/sbin/installer -package ... -target / to install the software update For 98%+ of our users, this update process works great. For a tiny portion of users, we're seeing that hdiutil reports that it failed to attach the disk image. For the even tinier portion of users from whom we have obtained debug logs, one of the errors we've seen is "not recognized"; however, I don't know if that's the most common error, due to the small sample size. Before I get much further, I think it's prudent to acknowledge that the above system we're using today is pushing a decade old now, and it's probably wise to verify the foundations. So... For a Developer-ID-signed macOS app that is distributed outside the Mac App Store using an installer package, what is the "best" container/packaging system for an automated system to obtain and consume the installer package with the goal of a user-initiated self-update? For example: Notarized disk image (and failures to attach the image need to be bug reports to Apple) Just the installer package (If I understand correctly, this is bad because it bypasses the automatic propagation (normally performed by macOS) of the DMG's notary ticket to the pkg, right?) Something else? Secondly, what are some common developer mistakes to avoid? For example, these come to mind: When saving the DMG to disk, explicitly enable quarantine on the DMG, so that macOS runs appropriate security checks as intended (is this correct?) When running the installer package, do not use low-level tools (like cp) to copy the pkg out of the DMG, because macOS won't be able to automatically find the notary ticket when the pkg is installed (is this correct?) Anything else? Additional context: We currently support macOS 10.13+, but we will soon support only macOS 10.15+. Thank you!

I'm assisting a customer with an iOS app. He has a personal (non-company) Apple Developer account. I know that this kind of account didn't used to support collaborators, but I'm not sure what the current status is. He was able to add me to his account and give me permissions (Developer, App Manager). However when I run Xcode, his account does not appear in the list of Teams under my Apple ID, which is preventing me from working. Is this a bug or temporary problem or is the fact that his account is a personal account preventing me from doing this?

I have added an additional capability called "User Assigned Device Name" into my application(The provisions for Development, Ad hoc & App Store Connect etc already received from Apple). Since then we are facing issues on code signing. We are trying to Sign in Automatically and getting the below error always. /.xcodeproj Provisioning profile "iOS Team Provisioning Profile: com..*******" doesn't include the com.apple.developer.contacts.notes entitlement. Contact notes entitlements are not a part of our additional capabilities as we requested separately with Apple and received it in the provisioning profile long back. Actually that time the same(contacts notes entitlements) was not a part of the additional capabilities. Please advise if any one has gone through such a conflict and resolved.