Can someone please describe what is necessary to perform signing using codesign in a system that runs as LaunchDaemon. All workarounds like placing the codesigning cert + private key a custom keychain and unlock it in the session of the LaunchDaemon doesn't work anymore on Sequoia. Or are there alternatives for signing MachO binaries without codesign?

Hi All. I'm having a notarization issue trying to get a product built. Starting around the beginning of April, I have a notarization process failing every time with an invalid server certificate. The returned error is: Error: HTTPError(statusCode: nil, error: Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “notary-artifacts-prod.s3.amazonaws.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x107810200) s: *.s3.amazonaws.com i: Amazon RSA 2048 M01>", "<cert(0x107810c00) s: Amazon RSA 2048 M01 i: Amazon Root CA 1>", "<cert(0x107811400) s: Amazon Root CA 1 i: Starfield Services Root Certificate Authority - G2>", "<cert(0x107811c00) s: Starfield Services Root Certificate Authority - G2 i: Starfield Class 2 Certification Authority>" The problem certificate appears to be "Amazon RSA 2048 M01" which appears to be expired. The error fires in response to an 'xcrun notarytool log' command. The initial ' xcrun notarytool submit' has already worked. The build server in this case is running Jenkins, with a Makefile driven notarization stage. It all worked perfectly until a build on April 3rd, all builds have failed since. I have tried using '--no-s3-acceleration'. But that fails even faster with: Conducting pre-submission checks for ICFA.zip and initiating connection to the Apple notary service... Submission ID received id: d50a2157-7acb-4bd6-b1d1-6d0b1d52d5c9 Error: The operation couldn’t be completed. (Network.NWError error 2.) Any help or suggestions would be appreciated. Right now I have folks needing a valid build. Thanks in advance.

I'm new to notarizing applications. I'm building an Electron application using electron-packager. The signing looks solid: codesign -vvv --deep --strict path/to/app.app # satisfies its Designated Requirement But checking notarization, looks like it didn't work. spctl --assess -vv path/to/app.app # source=Unnotarized Developer ID # origin=Developer ID Application: Tyson XXXX (XXXXX) I'm wondering how to fix the "Unnotarized Developer ID". Thanks!

Hi, I'm doing Java 22 experiments with open source package "wgpu-macos-aarch64-release" on my Mac M3. This library contains a .dylib file and a .a file. In Java you can load native dynamic libraries using JNI. I used that in the past. Now in MacOS 15 this stopped working. Currently, I compile my Java file and run the binary file on the command line, including the library directory. The application would load the library from that directory. This should normally works but the library is not loaded. After some investigation it seems the .dylib is rejected by MacOS. Calling spctl --assess --verbose=4 libwgpu_native.dylib gives libwgpu_native.dylib: rejected without any extra reason message. Using sudo xattr -rd com.apple.quarantine libwgpu_native.dylib doesn't solve the problem. I also can't "accept" it in "Privacy & Security" because it's run as a command line call. I know that code signing should be done for "complete" applications. But these are just experiments and working with single dynamic libraries. How should this be done, to be able to load those libraries in a Java command line program? Or in general, how can you load an unsigned dylib in an application (apart from using Java as a tool). Kr, J

When building to macOS on GameMaker, I get the error "this identity cannot be used for signing code" when using the Developer ID Installer certificate. The certificate was neither expired nor revoked, but nonetheless I created new certificates to start fresh but am still getting that error. I don't get issues building to iOS via GameMaker, just to macOS. If it makes any difference, I only noticed this issue started happening after I converted my Apple Developer Program account from an individual account to an organizational account, although it was weeks to months before I built to macOS via GameMaker before then, so I don't know if it correlates with that.

My command line tool with a JIT entitlement is failing to run on Sequoia. 2025-05-26 14:17:09.758 E taskgated-helper[91764:3ab7036] [com.apple.ManagedClient:ProvisioningProfiles] Disallowing DecisionRuleTool because no eligible provisioning profiles found 2025-05-26 14:17:09.758 Df amfid[576:3ab6d6b] /Users/jim/DecisionRuleTool not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Users/jim/DecisionRuleTool, NSLocalizedDescription=No matching profile found} 2025-05-26 14:17:09.759 Df kernel[0:3ab7031] (AppleMobileFileIntegrity) AMFI: When validating /Users/jim/DecisionRuleTool: 2025-05-26 14:17:09.759 Df kernel[0:3ab7031] mac_vnode_check_signature: /Users/jim/DecisionRuleTool: code signature validation failed fatally: When validating /Users/jim/DecisionRuleTool: 2025-05-26 14:17:09.759 Df kernel[0:3ab7031] proc 91763: load code signature error 4 for file "DecisionRuleTool" 2025-05-26 14:17:09.759 Df kernel[0:3ab7032] (AppleSystemPolicy) ASP: Security policy would not allow process: 91763, /Users/jim/DecisionRuleTool Codesign isn't giving me any clues as to why. It validates. Asking it what the entitlements are on the binary: % codesign --display --entitlements - /Users/joconnor/MACEP-9852-2/tools/detection/DecisionRuleTool Executable=/Users/jim/DecisionRuleTool [Dict] [Key] com.apple.application-identifier [Value] [String] XXXXXXXXX.com.mycompany.drt [Key] com.apple.developer.team-identifier [Value] [String] XXXXXXXXX [Key] com.apple.security.cs.allow-jit [Value] [Bool] true https://developer.apple.com/documentation/Xcode/signing-a-daemon-with-a-restricted-entitlement This makes it look like this may be hopeless, that I can't create a command line took with proper entitlements.

I'm trying to get an app notarized, which fails with this error: The signature of the binary is invalid. However, locally checking the signature does succeed: $ codesign -vvv --deep --strict TheApp.app […] TheApp.app: valid on disk TheApp.app: satisfies its Designated Requirement Performing this check on every single item in the app's MacOS folder also succeeds. Context: embedded prebuilt binaries Now, the app has something unusual about it: it embeds prebuilt binaries, arranged in various nested folders. So, the app bundle's MacOS folder actually contains another folder with a whole tree of executables and libraries: Removing these (before building) does fix the notarization issue, but obviously I'd like to keep them in. I did my best to properly sign these items: At build time, they're copied into the product by a Copy Files phase (but not signed), then signed by a script phase That signing uses the same signing identity as the running Xcode build, and enables the hardened runtime The app builds and runs correctly, even as a release build The app has runtime hardening and app sandbox enabled How should I go about diagnosing the notarization issue?

Can you please revoke my developer id application and installer certs? So i may recreate. I deleted the private key by mistake before realizing i cannot recreate everything using the developer website portal. I dont have macos backup or did i backup my certs with attached pkey. I just did not realize this was important until now. Please help as Im now blocked. I opened a case too but i have not yet got a response. its been 3 days now. case id: 20000093632858

Hi all, I've submitted multiple notarization requests for an Electron app using notarytool since (april 12) at 6:30. All are stuck in the "In Progress" state Successfully received submission history. history -------------------------------------------------- createdDate: 2025-04-13T12:38:56.866Z id: 51897340-9547-4172-bad4-ae15f78e1ab0 name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:38:55.790Z id: ebcd8a15-613c-41e0-b8cc-6895a0a6785a name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:14:33.553Z id: 59a078dc-e613-4933-b440-8695e2204eac name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-13T12:14:32.108Z id: 987879aa-db15-405b-bd1d-76db31218f49 name: theAIParalegal.zip status: In Progress -------------------------------------------------- createdDate: 2025-04-12T22:06:30.869Z id: b1f4231c-6d13-4292-88f0-e8ce53cb0141 name: theAIParalegal.zip status: In Progress nicolasserna@Mac ~ %

I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts. Is it possible to write a script that automates the entire process of codesigning the app? To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution? Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning? If possible, I’d appreciate a step-by-step explanation and a sample command-line script to: Codesign the app properly Package it into a signed .dmg Remove the quarantine attribute for local testing or distribution Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?

My app is a Safari extension. When trying to validate the app, I get the following error: App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "app.rango.Rango.pkg/Payload/Rango for Safari.app/Contents/MacOS/Rango for Safari" )] Refer to App Sandbox page at https://developer.apple.com/documentation/security/app_sandbox for more information on sandboxing your app. I don't know why this is happening. I have app sandbox enabled in both the app and the extension target. I have both entitlement files. When executing codesign -d --entitlements :- /path/to/binary I get the following: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.files.user-selected.read-only</key><true/><key>com.apple.security.get-task-allow</key><true/><key>com.apple.security.network.client</key><true/></dict></plist> If I check on Activity Monitor, on the sandbox column it shows true. I have no idea why I keep getting this error when all indicates that the app is actually sandboxed.

Hello, For my macOS app, on Xcode version 15.4 (15F31d) on macOS 14.5 (23F79) I follow Organizer > Distribute App > Direct Distribution, and I get a Notary Error "The operation couldn't be completed. (SotoS3.S3ErrorType.multipart error 1.)" It's been happening since 3 days. In the IDEDistribution.verbose.log file I see: https://gist.github.com/atacan/5dec7a5e26dde0ec06a5bc4eb3607461

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

Hello! I'm suddenly having some difficulty debugging a Flutter-based app. When I run an app from VS Code, it launches Xcode and builds & installs the app on an iPhone running 18.1. However, once the app is installed on the phone, it disappears and in Xcode, a dialog appears with: Failed to install embedded profile for : 0xe800801f (Attempted to install a Beta profile without the proper entitlement.) However, when I look at the provisioning profile being used, it seems to have the correct entitlement: I've also tried enabling automatic signing (instead of the current manual signing using match), as well as generating an adhoc profile and re-adding the device UDID in developers.apple.com. None of these have worked. This issue appeared within the past day or so and was working fine yesterday with no code changes, so I've been stumped. All my certs are relatively new and were issued within the past few months. I've tried regenerating the provisioning profiles using match, but this gives the same thing. What's odd is that I can run the build and upload to testflight, then download and install the app just fine through there. But this obviously makes debugging an issue.

We have a MacOS application that we plan on distributing standalone (it'll be installed through MDM or directly, not through the app store). We utilize endpoint security and full disk access for this (enterprise) app. I have a makefile that uses codesign to sign the app inside-out. All that appears to work (i.e., when I try to run the app directly it functions as I expect it to). What's the recommended way to allow the developers in my team to also sign the app for local development so it functions as close as possible to production? My first thought is to distribute the developer identity to their machines using MDM. However, ideally i'd like to rule out the ability for a developer who has the MDM profile assigned to export the keys. That really only leaves a centralized solution in place or disabling SIP on their system (which I don't want to do). Alternatively, would creating a separate identity for production make more sense, so that in the case the developer certificate is revoked, the production releases continue to function as normal (however, I assume this would also require creating two different profiles for the endpoint security entitlement--one for each certificate). Thanks! Derek

Hello, I recently had my Electron app notarized by Apple and then performed the following steps: Stapling the Notarization Ticket: xcrun stapler staple "appPath/Aiparalegal.app" Zipping the App for Distribution: ditto -c -k --keepParent "appPath/Aiparalegal.app" theAIParalegal.zip However, after unzipping and attempting to launch the app, macOS displays the following message: Apple could not verify "theAIParalegal" is free of malware that may harm your Mac or compromise your privacy. Yet, when I run validation using: xcrun stapler validate "theAIParalegal.app" I receive confirmation: The validate action worked! spctl -a -vvv -t install "theAIParalegal.app" theAIParalegal.app: accepted source=Notarized Developer ID origin=Developer ID Application: NIPartnership LLC (M92N2796Q9) Could you help me understand why the notarization validation appears successful, yet macOS still displays this security warning? Any advice on how to resolve this would be greatly appreciated. Thank you!

Hello, I recently had my Electron app notarized by Apple and then performed the following steps: Stapling the Notarization Ticket: xcrun stapler staple "appPath/Aiparalegal.app" Zipping the App for Distribution: ditto -c -k --keepParent "appPath/Aiparalegal.app" theAIParalegal.zip However, after unzipping and attempting to launch the app, macOS displays the following message: Apple could not verify "theAIParalegal" is free of malware that may harm your Mac or compromise your privacy. Yet, when I run validation using: xcrun stapler validate "theAIParalegal.app" I receive confirmation: The validate action worked! I then tried restarting my computer but the problem persist Could you help me understand why the notarization validation appears successful, yet macOS still displays this security warning? Any advice on how to resolve this would be greatly appreciated. Thank you!

Howdy, I thought this would be an easy question, but it turns out it's really not! In fact, it flies in the face of how the Apple ecosystem is set up. That said, I still need an answer to be able to inform our customers of what their app update options are. The question: Does app store provisioning ever expire? Based on the very limited information I can find, it either expires in one year, two years, or never. Anecdotal evidence seems to indicate that the answer could be never, but I need to confirm this. The use case: Some of our customers are very old school. They tend to find a technical solution and stick with it. As such, they do not update apps regularly on their field iPads. They generally only update when they are forced to. They use MDM to deploy the app, and would set the MDM not to pull updated apps from the app store when available, essentially keeping the same version of the app in use for as much as 3 years or more. If this were to happen, I need to know if the provisioning for the old version of the app will ever expire if they get it from the app store. I know with an enterprise deployment of .ipa files via MDM, the app provisioning/certificate will expire after 1 or 2 years (can't remember which atm), but I can't find an answer about app store provisioning. Hopefully someone can provide me with an answer on this forum. Thanks in advance, Mapguy

We had an issue with IDrive Online Backup which has started discussing on the Developer forum at https://developer.apple.com/forums/thread/756904 and as suggested raised a technical support ticket Case-ID: 7747625. At last the old legacy bundle ID prefix changed to to the new Team ID prefix. As a result  one-time loss of keychain data occurs, however we requested and were granted an additional keychain capability that allowed access to keychain data stored under the old legacy prefix, even after transitioning to the new Team ID prefix. We are currently facing a similar challenge with our other application, IBackup. As with the earlier case, we had a mismatch between the App ID prefix and the Team ID, which we resolved by updating the prefix to match the Team ID. Again now encountered a blocker with Keychain data recovery. We have already requested the additional Keychain capability that would allow access to keychain data stored under the old legacy prefix, even after transitioning to the new Team ID prefix. Unfortunately, the team responsible for this has some uncertainty about the process. Please review the details under case 102398017929 and extend this capability to our application to ensure a seamless user experience.

Background I've repeatedly run into codesigning (and missing provisioning profile) issues for my Ruby/Glimmer app and am looking for ways to troubleshoot this outside of Xcode. The app structure is as follows: PATHmanager.app └── Contents ├── Info.plist ├── MacOS │   └── PATHmanager ├── PkgInfo ├── Resources │   └── AppIcon.icns ├── _CodeSignature │   └── CodeResources └── embedded.provisionprofile Architecture I have a Mac mini Apple M2 Pro with macOS Ventura 13.4. Xcode is not used directly, but the underlying command line tools (e.g., codesign, productbuild, pkgutil, xcrun) are run from a custom Ruby script. xcodebuild -version Xcode 14.3.1 Build version 14E300c Questions Is the .app directory and file structure/naming sufficient? If not, can you point me in the direction of a minimal example that does not use Xcode? Info.plist is an XML text document (not binary), which I believe is in an acceptable format, but how do I lint this file and determine if it contains all of the necessary key/value pairs? <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>en</string> <key>CFBundleDisplayName</key> <string>PATH manager</string> <key>CFBundleExecutable</key> <string>PATHmanager</string> <key>CFBundleIconFile</key> <string>AppIcon.icns</string> <key>CFBundleIdentifier</key> <string>com.chipcastle.pathmanager</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>PATHmanager</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>1.15</string> <key>CFBundleSupportedPlatforms</key> <array> <string>MacOSX</string> </array> <key>CFBundleVersion</key> <string>1.15</string> <key>ITSAppUsesNonExemptEncryption</key> <false/> <key>LSApplicationCategoryType</key> <string>public.app-category.developer-tools</string> <key>LSMinimumSystemVersion</key> <string>12.0</string> <key>LSUIElement</key> <false/> <key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict> <key>NSHumanReadableCopyright</key> <string>© 2025 Chip Castle Dot Com, Inc.</string> <key>NSMainNibFile</key> <string>MainMenu</string> <key>NSPrincipalClass</key> <string>NSApplication</string> </dict> </plist> PATHmanager is a Mach-O 64-bit executable arm64 file created by using Tebako. Does this executable need to be codesigned, or is codesigning the .app folder sufficient? Does the .app directory need an entitlements file? Here's how I codesign it: codesign --deep --force --verify --verbose=4 --options runtime --timestamp --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app' Does the PATHmanager binary need an entitlements file? Here's how I codesign it: codesign --deep --force --verify --verbose=4 --options runtime --timestamp --entitlements '/Users/chip/Desktop/PATHmanager.entitlements' --sign 'Apple Distribution: Chip Castle Dot Com, Inc. (BXN9N7MNU3)' '/Users/chip/Desktop/distribution/PATHmanager.app/Contents/MacOS/PATHmanager' How can I verify what entitlements, if any, are required for codesigning the binary? The PATHmanager.entitlements file is an XML text file containing only the following: <?xml version="1.0" encoding="UTF-8"?> <!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.app-sandbox</key> <true/> </dict> </plist> Is the embedded.provisionprofile necessary, and if so, how do I know determine if it matches the certificate or entitlements that I'm using? Additionally, is it named and located properly? I submitted this to the AppStore several weeks ago and the reviewer reported that the executable would not load on their machine (even though it worked on mine.) Is it better for me to release via TestFlight for testing, and if so, do I need to following a separate process for codesigning (i.e., using different entitlements, profiles, certs, etc) when doing so? I've been playing whack-a-mole with this for too long to mention and am hoping to nail down a better deployment flow, so any suggestions for improvement will be greatly appreciated. Thank you in advance.