According to the new requirements for binary XCFrameworks they should be code signed. I watched the WWDC23 video 10061-Verify app dependencies with digital signatures and while it helpfully provides the command to sign the framework after building, it doesn’t mention how to sign it when your distribution certificates are of the Cloud managed kind, and therefore not actually in the macOS Keychain. My question is how can I sign a binary XCFramework when the only distribution certificate we have is in the cloud? I am a part of a team in App Store Connect, if that’s relevant. Thanks 🙌

I have a macOS app which contains a dext. I'd like to distribute it to external testers using TestFlight, so it has to pass Mac App Store review. It failed, because the App Sandbox entitlement was missing. I checked the app, it has the entitlement, but the dext does not. However, the .entitlements file used by the dext does contain App Sandbox set to true. I tried adding a "fake-entitlement" value to the .entitlements file, and that made it into the dext's code signature, but the App Sandbox entitlement appears to be stripped out by the build process? For a dext target, it isn't possible to add the App Sandbox capability in Xcode's Signing and Capability section. I have to add the entitlement manually in the .entitlement file (or it was put there by the Xcode driver template, I don't remember). I've tried clean building several times, I've tried Xcode 15.0.1, 15.2 and 15.3, but the result is always the same. I'm inspecting the entitlements using codesign -dvvv --entitlements - Does anyone know what I can do to put the App Sandbox entitlement into my dext's signature? Is this happening to anyone else?

Hi All, We use a small group of Mac mini units running VMs for our Apple CI system. Since you can't login to an Apple ID on an Apple Silicon VM we wanted to use an App Store Connect API token to handle all the authentication for us. In the past this has not worked but I wanted to see if it could now. The answer is no, you can not use an API token with Developer ID Cloud certificates. The reason is that, even on an Admin role token, the DevID certificates are not enabled by default. When you are using an Apple ID this is no big deal as you can check the box to allow access, but with tokens they are minted with only the default settings for the role. This means that the option for Access to Cloud Managed Developer ID Certificates is always disabled and you can't enable it. If we could continue logging in with an Apple ID we could stumble along with that still, but even this ability is gone on AS VMs. Right now this pretty much means that we either give up on using stateless VMs to build or we go back to manually managing all of our code signing materials. The longer term solution would be to move to Xcode Cloud, but that will take us quite some time. I filed FB13687073 to see if there is any way to create a token that can use this checkbox.

We use CocoaPods to manage third-party SDKs, so how should we sign and use these third-party SDKs

Hello, I am setting up a build (Gitlab CICD) runner. I create a keychain and imported certificate and my signing key. $ security find-identity -v XXXXXX "Developer ID Application: XXXXXX, INC. (XXXXXX)" (CSSMERR_TP_NOT_TRUSTED) 1 valid identities found $ security find-identity -p codesigning -v XXXXXX "Developer ID Application: XXXXXX, INC. (XXXXXX)" 1 valid identities found Codesign fails with unable to build chain to self-signed root for signer "Developer ID Application: XXXXXX, INC. (XXXXXX)" errSecInternalComponent On the local machine everything is fine. I think the point is that the identity is both valid and CSSMERR_TP_NOT_TRUSTED. What can I do about it?

The current structure of my SDK xcframework is XXXX-Release.xcframework. Inside that, I have an XXXX.xcframework and a LICENSE.md file. Currently, this structure works fine in Swift Package Manager, dropping the XXXX-Release.xcframework file into Xcode and CocoaPods. When I sign my xcframework as per Apple's requirements, I need to sign XXXX.xcframework, which is on the second level. Signing this works fine. Will this meet Apple's requirements for signing an xcframework? I just want to make sure the current structure of my SDK does not need to change. Thanks

Xcode Cloud succeeds in building the Release configuration of the app, but whenever deployment preparation is set to "TestFlight and App Store" the last step fails with: ITMS-90035: Invalid Signature. Code failed to satisfy specified code requirement(s). The file at path “{AppName}.app/{AppName}” is not properly signed. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose “Clean All” in Xcode, delete the “build” directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/support/code-signing. When I build for release (with manual signing) everything works as expected and uploading to TestFlight for external testing works. I have tried to removed every imported framework, library, file etc. only keeping the bare minimum and still Xcode Cloud fails with the same error. I even created a new empty project but I still get the same error. My only guess is that something is off with the automatically generated certificates (or provisioning profiles) that Apple creates. Is there any way to figure out what specifically makes the signing fail? Is there a way to reset Xcode Cloud to clear all data and caches, revoke all certificates and remove all accosiated provisioning profiles?

Hi, we are working on an application which will perform scheduled backup tasks in macOS 14. The app has been granted full disk permission. Recently we updated the code signing for the executable (/Applications/MyApp.app/Contents/MacOS/MyApp below) for passing the new notarization. After that, we found launchctl unable to load the plist for the schedule job <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <key>Label</key> <string>com.MyApp.scheduler</string> <key>ProgramArguments</key> <array> <string>/Applications/MyApp.app/Contents/MacOS/MyApp</string> <string>/Applications/MyApp.app</string> </array> <key>RunAtLoad</key> <true/> <key>AbandonProcessGroup</key> <true/> <key>WorkingDirectory</key> <string>/Applications/MyApp.app/bin</string> </dict> </plist> Related error message found in /var/log/com.apple.xpc.launchd/launchd.log* 2023-12-13 13:59:34.639672 (system/com.MyApp.scheduler [13434]) <Notice>: internal event: SOURCE_ATTACH, code = 0 2023-12-13 13:59:34.644530 (system/com.MyApp.scheduler [13434]) <Error>: Service could not initialize: posix_spawn(/Applications/MyApp.app/Contents/MacOS/MyApp), error 0x1 - Operation not permitted 2023-12-13 13:59:34.644545 (system/com.MyApp.scheduler [13434]) <Error>: initialization failure: 23C64: xpcproxy + 38300 [1097][925DE4E7-0589-3B33-BB64-7BC2F8629897]: 0x1 2023-12-13 13:59:34.644548 (system/com.MyApp.scheduler [13434]) <Notice>: internal event: INIT, code = 1 2023-12-13 13:59:34.644915 (system/com.MyApp.scheduler [13434]) <Notice>: xpcproxy exited due to exit(78) We have tried to update the entitlements for library and main executable files while still not success on make it works again. We have no idea what else could do for troubleshooting this. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> <key>com.apple.security.cs.debugger</key> <true/> <key>com.apple.application-identifier</key> <string>...</string> <key>com.apple.developer.team-identifier</key> <string>...</string> </dict> </plist> Appreciate for any suggestions. Thank you.

Electron-Builder Version: 24.12.0 Electron-Builder-notarize Version: 1.5.1 Node Version: v15.14.0 Electron Version: 11.3.0 Electron-updater version: ^4.3.5 Target: Mac Apple Store (mas) Hello, I am trying to build and sign a new version of my electron app for the mac apple store (mas), but when I get to the final step of uploading the RenderTune.pkg file to the mac transporter app, I get a failed status with 22 errors all the same formatting like so: Asset validation failed (90284) Invalid Code Signing. The executable 'com.martinbarker.digifyunique.pkg/Payload/RenderTune.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/etc....dylib' must be signed with the certificate that is contained in the provisioning profile. (ID: abc-abc-abc-abc-abc) In order to build and sign this RenderTune.pkg file, first I run the command npm run build-mas locally while on branch v1.1.5 ( code here ) Which runs the following command: "build-mas": "electron-builder build --mac && sh signmasscript.sh", So first it runs electron-builder build --mac and gives this output: Martins-MacBook-Air:rendertune-v1.1.5-feb-24 martinbarker$ npm run build-mas > rendertune@1.1.5 build-mas > electron-builder build --mac && sh signmasscript.sh • electron-builder version=24.12.0 os=20.6.0 • loaded configuration file=package.json ("build" field) • writing effective config file=dist/builder-effective-config.yaml • packaging platform=darwin arch=x64 electron=11.3.0 appOutDir=dist/mac • signing file=dist/mac/RenderTune.app platform=darwin type=distribution identity=ACBACBACBACBACBACBACBACBACB provisioningProfile=none • skipped macOS notarization reason=`notarize` options were not provided • building target=DMG arch=x64 file=dist/RenderTune-mac.dmg • building target=macOS zip arch=x64 file=dist/RenderTune-mac.zip • building block map blockMapFile=dist/RenderTune-mac.dmg.blockmap • building block map blockMapFile=dist/RenderTune-mac.zip.blockmap Completes without issue. The next part is running the signmasscript.sh file, which does complete but gives these errors: Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 Failed to parse entitlements: AMFIUnserializeXML: syntax error near line 1 productbuild: Adding component at /Users/martinbarker/Documents/projects/rendertune-v1.1.5-feb-24/dist/mas/RenderTune.app productbuild: Signing product with identity "3rd Party Mac Developer Installer: Martin Barker (LV6WXG529F)" from keychain /Users/martinbarker/Library/Keychains/login.keychain-db productbuild: Adding certificate "Apple Worldwide Developer Relations Certification Authority" productbuild: Adding certificate "Apple Root CA" productbuild: Wrote product to /Users/martinbarker/Documents/projects/rendertune-v1.1.5-feb-24/RenderTune.pkg productbuild: Supported OS versions: [10.10.0, ) The final output RenderTune.pkg file gives 22 error messages saying `` when I try to deliver it via the mac os transport app. Asset validation failed (90284) Invalid Code Signing. The executable must be signed with the certificate that is contained in the provisioning profile Is my app even being signed correctly? Or is there just one file that I need to fix? Please help me out !

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

After confirming an order for an Apple Developer account, the bottom of the page says: Need some help? Chat now or call 1‑800‑MY‑APPLE. Question 1: Why make your developers translate from 1-800-MY-APPLE to a phone number manually? It would cost no more to say call 1-800-MY-APPLE or 1-800-555-5555 or whatever the translation is. It's just one example where Apple could provide a bit more information and make it better for the developers than they do. The whole Apple Developer enrollment / account / team / certification process is astonishingly unintuitive and could be helped so much by simply providing additional information as we work through the process. You say "Sign in to run locally" but offer no info about where to sign in. (A place for name and email appeared briefly, I entered my password incorrectly and now it doesn't seem to show up at all?) Question 2: That number seems to go to support for hardware orders (iPhones, machines, etc.). Is there a different number for developer account issues? Question 3: I paid $99 to renew the dev account, but I still can't build my SwiftUI XCode project due to Signing & Certificate Issues, and there's a bit of conflicting feedback. Feedback 1: When I click my order, it says: Apple Developer Program - Membership for one year Enrollment Complete Order Placed(Completed) Electronically Delivered (Completed) Thanks for being a part of the Apple Developer Program. Feedback 2: When I go to https://developer.apple.com/enroll/purchase, it says: Complete your purchase. Once you complete your purchase, you’ll receive a purchase acknowledgement and a membership confirmation email, and it wants me to pay $99 again. Seems unnecessarily challenging just to be able to build and run my XCode app on my own machine. Many of the involved options have little help associated to resolve issues. XCode recognizes my account, and I have a cert for running on my machine but it appears to be "in progress" so I'm dead in the water for now. Question 4: Any ideas how many days it takes before the payment will clear and I can play with my app again?

I am working on an open source app. I have been testing the package installer, and something unexpected is happening: the .pkg won't run on my test machine and will instead show a banner saying "myApp.app can't be opened because Apple cannot check it for malicious software"; nevertheless, if I wait some minutes, the installer will run just fine! After reading through many of ekimo's posts, I assumed it may have something to do with stapler. I was not stapling my .dmg originally, so that's something I may be missing (my app is installed by a .pkg inside a .dmg). Nevertheless, the computer where I am testing the app has internet connection, meaning stapler should not even come into play. Regardless, I decided to staple my .dmg. Running xcrun stapler staple -v myApp.dmg after notarizing produces this result: builder ~ % xcrun stapler staple -v /Users/builder/Data/HEAD/installation/Packages/myApp.dmg Processing: /Users/builder/Data/HEAD/installation/Packages/myApp.dmg Properties are { NSURLIsDirectoryKey = 0; NSURLIsPackageKey = 0; NSURLIsSymbolicLinkKey = 0; NSURLLocalizedTypeDescriptionKey = "Disk Image"; NSURLTypeIdentifierKey = "com.apple.disk-image-udif"; "_NSURLIsApplicationKey" = 0; } Creating synthetic cdHash for unsigned disk image, myApp.dmg. Humanity must endure. Signing information is { cdhashes = ( {length = 20, bytes = 0xdd018313b1c574a403f01dccc96c21705987d76c} ); "cdhashes-full" = { 2 = {length = 32, bytes = 0xdd018313 b1c574a4 03f01dcc c96c2170 ... 918d33f3 d5a74dc3 }; }; cms = {length = 0, bytes = 0x}; "digest-algorithm" = 2; "digest-algorithms" = ( 2 ); flags = 2; format = "disk image"; identifier = ADHOC; "main-executable" = "file:///Users/builder/Data/HEAD/installation/Packages/myApp.dmg"; source = "explicit detached"; unique = {length = 20, bytes = 0xdd018313b1c574a403f01dccc96c21705987d76c}; } Stored Codesign length: 12 number of blobs: 0 Total Length: 12 Found blobs: 0 JSON Data is { records = ( { recordName = "2/2/dd018313b1c574a403f01dccc96c21705987d76c"; } ); } Headers: { "Content-Type" = "application/json"; } Domain is api.apple-cloudkit.com Response is <NSHTTPURLResponse: 0x600003b85ba0> { URL: https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup } { Status Code: 200, Headers { Connection = ( "keep-alive" ); "Content-Encoding" = ( gzip ); "Content-Type" = ( "application/json; charset=UTF-8" ); Date = ( "Mon, 26 Feb 2024 15:34:15 GMT" ); Server = ( "AppleHttpServer/78689afb4479" ); "Strict-Transport-Security" = ( "max-age=31536000; includeSubDomains;" ); "Transfer-Encoding" = ( Identity ); Via = ( "xrail:st53p00ic-qujn15041902.me.com:8301:24R11:grp60,631194250daa17e24277dea86cf30319:59e17ac665e1de7388b8f4e69e92e383:defra2" ); "X-Apple-CloudKit-Version" = ( "1.0" ); "X-Apple-Edge-Response-Time" = ( 99 ); "X-Apple-Request-UUID" = ( "9fc0fe2d-49fd-4e74-b718-660c56edb3bb" ); "X-Responding-Instance" = ( "ckdatabasews:16306401:st42p63ic-ztfb05112901:8807:2409B432:afc827b7b1ebf24829e9c4856d4b69205f23804f" ); "access-control-expose-headers" = ( "X-Apple-Request-UUID,X-Responding-Instance,Via" ); "x-apple-user-partition" = ( 63 ); } } Size of data is 165 JSON Response is: { records = ( { reason = "Record not found"; recordName = "2/2/dd018313b1c574a403f01dccc96c21705987d76c"; serverErrorCode = "NOT_FOUND"; } ); } CloudKit query for myApp.dmg (2/dd018313b1c574a403f01dccc96c21705987d76c) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/dd018313b1c574a403f01dccc96c21705987d76c The staple and validate action failed! Error 65 What does this show? Thank you.

Hello! I'm dealing with a strange code signing issue which is preventing me from distributing a game through Steam. I'm able to sign and notarise the app in Xcode without any issues. I can verify that the app and all frameworks in /Contents/Frameworks/ are signed, and Gatekeeper allows the app to run without complaining. $ spctl --assess -vvv ~/Temp/CodeSigningTest/GoodApp.app /Users/ruairi/Temp/CodeSigningTest/GoodApp.app: accepted source=Notarized Developer ID origin=Developer ID Application: Ruairi Dorrity (3F97UA4BF8) $ codesign --verify -vvv ~/Temp/CodeSigningTest/GoodApp.app --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/mpg123.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/mpg123.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/libmodplug.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/libmodplug.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/freetype.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/freetype.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/Lua.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/Lua.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/vorbis.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/vorbis.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/OpenAL-Soft.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/OpenAL-Soft.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/theora.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/theora.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework/Versions/Current/. --prepared:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/SDL2.framework/Versions/Current/. --validated:/Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/SDL2.framework/Versions/Current/. /Users/ruairi/Temp/CodeSigningTest/GoodApp.app: valid on disk /Users/ruairi/Temp/CodeSigningTest/GoodApp.app: satisfies its Designated Requirement However, if I zip the app and upload it to Steam, the app that the Steam client downloads is blocked by Gatekeeper ("damaged and can't be opened") and re-running the above commands shows that the code signing seal has been broken somehow on the downloaded app: $ spctl --assess -vvv ~/Temp/CodeSigningTest/BadApp.app /Users/ruairi/Temp/CodeSigningTest/BadApp.app: cannot find code object on disk $ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app /Users/ruairi/Temp/CodeSigningTest/BadApp.app: code object is not signed at all In subcomponent: /Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/love.framework The second command can be re-run, showing a seemingly random framework from /Contents/Frameworks/ each time e.g. $ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app /Users/ruairi/Temp/CodeSigningTest/BadApp.app: code object is not signed at all In subcomponent: /Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/ogg.framework Further investigation shows that these frameworks are now unsigned, when they were signed before uploading and downloading: $ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/ogg.framework /Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/ogg.framework: code object is not signed at all $ codesign --verify -vvv ~/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/love.framework /Users/ruairi/Temp/CodeSigningTest/BadApp.app/Contents/Frameworks/love.framework: code object is not signed at all ... $ codesign --verify -vvv ~/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework /Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework: valid on disk /Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/ogg.framework: satisfies its Designated Requirement $ codesign --verify -vvv ~/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework /Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework: valid on disk /Users/ruairi/Temp/CodeSigningTest/GoodApp.app/Contents/Frameworks/love.framework: satisfies its Designated Requirement I'm stumped as to what's happening here. Is is possible that the app is being modified being the scenes by Steam, which breaks the code signing? This seems unfathomable because it would surely break code signing on every Mac game on Steam, but I really can't understand what else would be going on. I'm sure I need to expand my knowledge on code signing; any pointers, suggestions or assistance is greatly appreciated! Thank you!

I am migrating my project from Xcode 13 to Xcode 14.3.1. My project has five subproject that contains few command line toll and dylibs. I have a custom build script that runs on VSO pipeline. Pipeline failing on 'building submodules and build App' stage. This is my build script snapshot- Pipeline only build my application successfully when I am passing 'CODE-SIGN-REQUIRED' ='NO' But I need a signed build for further action. Please help me how can I get a signed build. Note - Using same certificate I am able to build, run and archive app in my Xcode.

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) IMPORTANT Most developers never see a code signing crash because they use Xcode to build and sign their product. Xcode’s code signing infrastructure detects problems that could cause a code signing crash, and its automatic code signing fixes them for you! If you’re having problems with code signing crashes and you can use Xcode but aren’t, consider making the switch Xcode. The most common code signing crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available If you see valid thread backtraces this is not a crash on launch. Go back to Resolving Trusted Execution Problems and read through the Code Signing Crashes After Launch section. If you see no thread backtraces, your code didn’t run at all. The trusted execution system has blocked it. In most cases there is some evidence of the problem in the system log. For example: type: error time: 2022-05-19 06:29:17.640331 -0700 process: taskgated-helper subsystem: com.apple.ManagedClient category: ProvisioningProfiles message: com.example.apple-samplecode.OverClaim: Unsatisfied entitlements: com.apple.overclaim This indicates that the OverClaim app, with bundle ID com.example.apple-samplecode.OverClaim, claimed a restricted entitlement, com.apple.overclaim, that wasn’t authorised by a provisioning profile. For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. Specifically, the Entitlements on macOS section discusses the concept of restricted entitlements. For general information about the system log, see Your Friend the System Log. Normalise the Entitlements Property List Entitlement property list files look like text and so it’s tempting to edit them with a text editor. This can lead to all sorts of problems. If you have code whose entitlements property list contains comments, non-Unix line endings, or other weird formatting, the trusted execution system may block it. To avoid such problems, normalise your entitlements property list before passing it to codesign. For example: % plutil -convert xml1 MyApp.plist % codesign -s III --entitlements MyApp.plist MyApp.app Problems like this typically show up on older systems. Modern systems use DER-encoded entitlements, as discussed in The future is DER section of TN3125. A related gotcha is line breaks. Consider this entitlements property list file: % cat MyApp.plist … <plist version="1.0"> <dict> <key> com.apple.security.cs.disable-library-validation</key> <true/> </dict> </plist> This is a valid property list but it doesn’t do what you think it does. It looks like it claims the com.apple.security.cs.disable-library-validation entitlement but in reality it claims \ncom.apple.security.cs.disable-library-validation. The system treats the latter as a restricted entitlement and thus requires it to be authorised by a profile. Of course no such profile will authorise that entitlement, and so the app is blocked by the trusted execution system. Similarly, consider this: % cat MyApp.plist … <plist version="1.0"> <dict> <key> com.apple.security.cs.disable-library-validation</key> <true/> </dict> </plist> This claims com.apple.security.cs.disable-library-validation, note the leading space, and that’s also blocked by the trusted execution system. Check for Unauthorised Entitlements Sometimes the system log may not make it obvious what’s gone wrong. It may be easier to work this out by looking at the built program. The most common cause of problems like this is the app claiming a restricted entitlement that’s not authorised by a provisioning profile. To start your investigation, dump the entitlements to check for restricted entitlements: % codesign -d --entitlements - "OverClaim.app" …/OverClaim.app/Contents/MacOS/OverClaim [Dict] [Key] com.apple.application-identifier [Value] [String] SKMME9E2Y8.com.example.apple-samplecode.OverClaim [Key] com.apple.developer.team-identifier [Value] [String] SKMME9E2Y8 [Key] com.apple.overclaim [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true In this case all the entitlements except com.apple.security.get-task-allow are restricted. Note If there are no restricted entitlements, something else has gone wrong. Go back to Resolving Trusted Execution Problems and look for other potential causes. Now check that the provisioning profile was embedded correctly and extract its payload: % ls -l "OverClaim.app/Contents/embedded.provisionprofile" … OverClaim.app/Contents/embedded.provisionprofile % security cms -D -i "OverClaim.app/Contents/embedded.provisionprofile" -o "OverClaim-payload.plist" Check that the profile applies to this app by dumping the com.apple.application-identifier entitlement authorised by the profile: % /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.application-identifier" OverClaim-payload.plist SKMME9E2Y8.com.example.apple-samplecode.* This should match the com.apple.application-identifier entitlement claimed by the app. Repeat this for all the remaining restricted entitlements: % /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.developer.team-identifier" OverClaim-payload.plist SKMME9E2Y8 % /usr/libexec/PlistBuddy -c "print :Entitlements:com.apple.overclaim" OverClaim-payload.plist Print: Entry, ":Entitlements:com.apple.overclaim", Does Not Exist In this example the problem is the com.apple.overclaim entitlement, which is claimed by the app but not authorised by the profile. If that’s the case for your program, you have two choices: If you program doesn’t need this entitlement, update your code signing to not claim it. If you program relies on this entitlement, update your profile to authorise it. The entitlement allowlist in the profile is built by the Apple Developer website based on the capabilities enabled on your App ID. To change this allowlist, modify your App ID capabilities and rebuild your profile. Some capabilities are only available on some platforms and, within that platform, for some distribution channels. For these details for macOS, see Developer Account Help > Reference > Supported capabilities (macOS). Some capabilities require review and approval by Apple. For more on this, see Developer Account Help > Reference > Provisioning with capabilities. Check for Required Entitlements If your app claims any restricted entitlements, it must also claim the com.apple.application-identifier entitlement, with its value being your app’s App ID. macOS uses this value to confirm that the embedded provisioning profile is appropriate for your app. Without this, macOS might not use this profile, which means there’s nothing to authorise your app’s use of restricted entitlements, which prevents your app from launching. IMPORTANT macOS 12 and later will use an embedded provisioning profile even if the app doesn’t claim the com.apple.application-identifier entitlement. So, if your app works on macOS 12 and later but fails on macOS 11, this is likely the cause. If you claim the com.apple.application-identifier entitlement then I recommend that you also claim the com.apple.developer.team-identifier entitlement. That’s what Xcode does, and my experience is that it’s best to stay on that well-trodden path. Check the Signing Certificate If your program’s entitlements look good, the next most likely problem is that your program was signed by a signing identity whose certificate is not authorised by the profile. To debug this, first extract the certificate chain from your program: % codesign -d --extract-certificates=signed-with- "OverClaim.app" … % for i in signed-with-* ; do mv "${i}" "${i}.cer" ; done The first certificate is the one that matters: % certtool d "signed-with-0.cer" Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25 … Subject Name : Other name : UT376R4K29 Common Name : Apple Development: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … Now check this against each of the certificates authorised by the profile. Start by extracting the first one: % plutil -extract DeveloperCertificates.0 raw -o - OverClaim-payload.plist | base64 -D > "authorised0.cer" % certtool d "authorised0.cer" Serial Number : 46 A8 EF 2C 52 54 DE FD D1 76 9D 3A 41 7C 9E 43 … Subject Name : Other name : UT376R4K29 Common Name : Mac Developer: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … That’s not a match. So try the next one: % plutil -extract DeveloperCertificates.1 raw -o - OverClaim-payload.plist | base64 -D > authorised1.cer % certtool d "authorised1.cer" Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25 … Subject Name : Other name : UT376R4K29 Common Name : Apple Development: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … This matches, which means the profile applies to this code. IMPORTANT When checking for a match, look at the Serial Number field. Don’t just rely on the Common Name field. A common mistake is to have two signing identities whose certificates have identical common names but the profile only lists one of them. If you get to the end of the list of certificate list in the profile and don’t find the certificate that the program was signed with, you know what the problem is: Your program is signed with a signing identity whose certificate is not listed in its profile. To fix this, either: Reconfigure your code signing to use a signing identity whose certificate is listed. Or update the profile to include the certificate of the signing identity you’re using. Check for Expiration If your certificates aren’t the problem, check that nothing has expired. Start with the certificate from the app’s signature: % certtool d "signed-with-0.cer" Serial Number : 53 DB 60 CC 85 32 83 DE 72 D9 6A C9 8F 84 78 25 … Not Before : 10:52:56 Apr 21, 2022 Not After : 10:52:55 Apr 21, 2023 … Also check the expiry date on the profile: % plutil -extract ExpirationDate raw -o - OverClaim-payload.plist 2023-04-21T11:02:58Z If either has expired, update it and re-sign your product. IMPORTANT Developer ID-signed code and installers include a secure timestamp. When the system checks the expiry date on a Developer ID certificate, it only checks that the certificate was valid at the time that the code was signed, base on that secure timestamp. Thus, an old Developer ID-signed app will continue to run after it’s certificate has expired. To learn more about secure timestamps, see TN3161 Inside Code Signing: Certificates. Check the Supported Devices If everything else checks out, the last thing to check is that the profile authorises the code to run on this machine. There are two cases here: Developer ID profiles authorise the code on all machines. Other profiles authorise the code on a specific list of machines. If you think you have a Developer ID profile, confirm that by looking for the ProvisionsAllDevices property: % plutil -extract "ProvisionsAllDevices" xml1 -o - "OverClaim-payload.plist" … No value at that key path or invalid key path: ProvisionsAllDevices If that’s not the case, get the ProvisionedDevices property and verify that the current machine’s provisioning UDID is listed there: % plutil -extract "ProvisionedDevices" xml1 -o - "OverClaim-payload.plist" … <array> … <string>A545CA26-80D7-5B38-A98C-530A798BE342</string> … </array> </plist> % system_profiler SPHardwareDataType … Provisioning UDID: A545CA26-80D7-5B38-A98C-530A798BE342 … If you get to the end any everything looks OK, your provisioning profile is not the cause of this crash. Return to Resolving Trusted Execution Problems for more suggestions. Revision History 2024-02-20 Added the Check for Required Entitlements section. Added a link to TN3161. Fixed the Developer Account Help links. 2022-06-08 Added the Normalise the Entitlements Property List section. 2022-05-20 First posted.

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"

IMPORTANT I’m very pleased to report that, due to the hard work of a number of folks at Apple, this DevForums post has been replaced by official documentation: Packaging Mac software for distribution. I’m leaving this post in place as a historical curiosity, but please consult the official documentation going forward. This post is one of a pair of posts, the other one being Creating Distribution-Signed Code for Mac, that replaces my earlier Signing a Mac Product For Distribution post. For more background on this, see the notes at the top of Creating Distribution-Signed Code for Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Packaging Mac Software for Distribution Build a zip archive, disk image, or installer package for distributing your Mac software. Overview Xcode is a great tool for creating and distributing Mac apps. Once you’ve written your code you can upload it to the App Store with just a few clicks. However, Xcode cannot do everything. For example: Some Mac software products are not apps. You might, for example, be creating a product that includes a daemon. Some Mac products include multiple components. Your daemon might include an app to configure it. Some Mac products ship outside of the App Store, and so need to be packaged for distribution. For example, you might choose to distribute your daemon and its configuration app in an installer package. Some Mac products are built with third-party developer tools. If your product cannot be built and distributed using Xcode alone, follow these instructions to package it for distribution. Note If you use a third-party developer tool to build your app, consult its documentation for advice specific to that tool. To start this process you need distribution-signed code. For detailed advice on how to create distribution-signed code, see Creating Distribution-Signed Code for Mac. If you ship your product frequently, create a script to automate the distribution process. Decide on a Container Format To get started, decide on your container format. Mac products support two distribution channels: The Mac App Store, for apps Independent distribution, for apps and non-apps, using Developer ID signing A Mac App Store app must be submitted as an installer package. In contrast, products distributed outside of the Mac App Store use a variety of different container formats, the most common being: Zip archive (.zip) Disk image (.dmg) Installer package (.pkg) You may choose to nest these containers. For example, you might ship an app inside an installer package on a disk image. Nesting containers is straightforward: Just work from the inside out, following the instructions for each container at each step. IMPORTANT Sign your code and each nested container (if the container supports signing). For example, if you ship an app inside an installer package on a disk image, sign the app, then create the installer package, then sign that package, then create the disk image, then sign the disk image. Each container format has its own pros and cons, so choose an approach based on the requirements of your product. Build a Zip Archive If you choose to distribute your product in a zip archive, use the ditto tool to create that archive: Create a directory that holds everything you want to distribute. Run the ditto tool as shown below, where DDD is the path to the directory from step 1 and ZZZ is the path where ditto creates the zip archive. % ditto -c -k --keepParent DDD ZZZ Zip archives cannot be signed, although their contents can be. Build an Installer Package If you choose to distribute your product in an installer package, start by determining your installer signing identity. Choose the right identity for your distribution channel: If you’re distributing an app on the Mac App Store, use a Mac Installer Distribution signing identity. This is named 3rd Party Mac Developer Installer: TTT, where TTT identifies your team. If you’re distributing a product independently, use a Developer ID Installer signing identity. This is named Developer ID Installer: TTT, where TTT identifies your team. For information on how to set up these installer signing identities, see Developer Account Help. Run the following command to confirm that your installer signing identity is present and correct: % security find-identity -v 1) 6210ECCC616B6A72F238DE6FDDFDA1A06DEFF9FB "3rd Party Mac Developer Installer: …" 2) C32E0E68CE92936D5532E21BAAD8CFF4A6D9BAA1 "Developer ID Installer: …" 2 valid identities found The -v argument filters for valid identities only. If the installer signing identity you need is not listed, see Developer Account Help. IMPORTANT Do not use the -p codesigning option to filter for code signing identities. Installer signing identities are different from code signing identities and the -p codesigning option filters them out. If your product consists of a single app, use the productbuild tool to create a simple installer package for it: % productbuild --sign III --component AAA /Applications PPP In this command: III is your installer signing identity. AAA is the path to your app. PPP is the path where productbuild creates the installer package. The above is the simplest possible use of productbuild. If you’re submitting an app to the Mac App Store, that’s all you need. If you have a more complex product, you’ll need a more complex installer package. For more details on how to work with installer packages, see the man pages for productbuild, productsign, pkgbuild, and pkgutil. For instructions on how to read a man page, see Reading UNIX Manual Pages. Build a Disk Image If you choose to distribute your product in a disk image: Create a directory to act as the source for the root directory of your disk image’s volume. Populate that directory with the items you want to distribute. If you’re automating this, use ditto rather than cp because ditto preserves symlinks. Use hdiutil command shown below to create the disk image, where SSS is the directory from step 1 and DDD is the path where hdiutil creates the disk image. Decide on a code signing identifier for this disk image. If you were signing bundled code, you’d use the bundle ID as the code signing identifier. However, disk images have no bundle ID and thus you must choose a code signing identifier for your image. For advice on how to do this, see the Sign Each Code section in Creating Distribution-Signed Code for Mac. Use the codesign command shown below to sign the disk image, where III is your Developer ID Application code signing identity (named Developer ID Application: TTT, where TTT identifies your team), BBB is the code signing identifier you chose in the previous step, and DDD is the path to the disk image from step 3. % hdiutil create -srcFolder SSS -o DDD % codesign -s III --timestamp -i BBB DDD For more information on code signing identities, see the Confirm Your Code Signing section in Creating Distribution-Signed Code for Mac. IMPORTANT Sign your disk image with a code signing identity, not an installer signing identity. There are various third-party tools that configure a disk image for distribution. For example, the tool might arrange the icons nicely, set a background image, and add a symlink to the Applications folder. If you use such a tool, or create your own tool for this, make sure that the resulting disk image: Is signed with your Developer ID Application code signing identity Is a UDIF-format read-only zip-compressed disk image (type UDZO) Submit Your App to the Mac App Store If you’re creating an app for the Mac App Store, submit your signed installer package using either the altool command-line tool or the Transporter app. For detailed instructions, see App Store Connect Help > Reference > Upload tools. Notarize Your Product If you’re distributing outside of the Mac App Store, notarize the file you intend to distribute to your users. For detailed instructions, see Customizing the Notarization Workflow. Skip the Export a Package for Notarization section because you already have the file that you want to submit. If you’re using nested containers, only notarize the outermost container. For example, if you have an app inside an installer package on a disk image, sign the app, sign the installer package, and sign the disk image, but only notarize the disk image. The exception to this rule is if you have a custom third-party installer. In that case, see the discussion in Customizing the Notarization Workflow. Staple Your Product Once you’ve notarized your product, staple the resulting ticket to the file you intend to distribute. Staple the Ticket to Your Distribution discusses how to do this for an app within a zip archive. The other common container formats, installer packages and disk images, support stapling directly. For example, to staple a tick to a disk image: % xcrun stapler staple FlyingAnimals.dmg Stapling is recommended but not mandatory. However, if you don’t staple a user might find that your product is blocked by Gatekeeper if they try to install or use it while the Mac is offline. Revision History 2024-02-19 Added a preamble that links to the official documentation, Packaging Mac software for distribution. 2022-03-01 First posted.