Hello I build an application in Xcode for MacOS. But the exported app I cannot open on different Mac systems. I get the message 'The application X can't be opened'. I can only run the application on the Mac where Xcode is installed. I used different signing certificates: Apple Distribution, Developer ID application (this should be the one), Mac App Distribution. I archive the application, then use Direct Distribution, then after complished the notary service, I export the app.

I am creating a macOS app with the following requirements: Automatic Startup: After initial installation, the app should automatically start, even after the OS restarts. Notarized Installation: The installation package (.pkg) should be notarized to avoid user have to make security exception. In my current setup I’ve created a script, ci_scripts/ci_post_xcodebuild.sh, which uploads the package file $CI_APP_STORE_SIGNED_APP_PATH/<appName>.pkg to GitHub via Xcode Cloud. While I can successfully download the app, I’m encountering two main issues: Notarization (I assume): I’m unsure how to get Xcode Cloud to notarize the .pkg file. Currently, upon opening the .pkg file for the first time, users have to go to System Settings > Privacy & Security to allow an exception for the package, after which installation proceeds successfully on second try. I’d like to automate the notarization process to eliminate this extra step. Adding Additional Files to PKG installer: My current .pkg file only includes the app binary. I need to configure Xcode Cloud to include a postinstall script and a launchd daemon configuration file within the package. This would ensure that necessary files are set up on installation and that the app is properly registered as a launch daemon.

Hi all, I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because "it's damaged", even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app. I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done? I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation. Maybe there's a more elegant way? Thanks!

In the past, I used to export a developer-signed test version of my macOS app in Xcode, create a zip archive from the Finder, upload it to my website and share the link to the testers. The last time I did this with macOS 14 the tester was still able to download the test app and run it. But it seems that with macOS 15 the trick to open the context menu on the downloaded app and click Open to bypass the macOS warning that the app couldn't be checked when simply double-clicking it, doesn't work anymore. Now I'm always shown an alert that macOS couldn't check the app for malware, and pushes me to move it to the bin. In this StackOverflow topic from 10 years ago they suggested to use ditto and tar to compress and uncompress the app, but neither worked for me. How can I share macOS apps that I signed myself with testers without physically handing them a drive containing the uncompressed app?

Hi, my app's direct distribution archive is stuck at "In progress" state in Organizer window. What is wrong with it? What should I do? Thank you.

I am packaging an app with QtWebEngine in it, after codesign the app and the QtWebEngine Framework, the app can run properly. The codesign result is: valid on disk staisfies its Designated requirements Then I notarized and stapled the dmg file, after the dmg installed on Mac, gatekeeper still failed the check. Here is the result for spctl: spctl -a -t open -vvv --context context:primary-signatue Remote\ Graphics\ Workstation_.dmg Remote Graphics Workstation_.dmg: rejected source=Insufficient Context Need help to identify the codesign process and the root cause why gatekeeper fail here, thanks.

We have a native ARM64 application. The application is a development environment and native compiler for the language Common Lisp. CL has a foreign function interface, which allows loading of .dylib files into CL and calling functions in them from CL. For this reason, we add certain entitlements. See below. It is notarized and installed on macOS 14.7. When I run spctl on it I get this: $ spctl --assess -v /Applications/AllegroCL64.app /Applications/AllegroCL64.app: rejected (the code is valid but does not seem to be an app) That’s before I run it. Which is odd because the app is notarized. When I run the app, it asks for a license file and installs it into /Applications/AllegroCL64.app/Contents/Resources/ and after that, the spctl shows this: $ spctl --assess -v /Applications/AllegroCL64.app /Applications/AllegroCL64.app: a sealed resource is missing or invalid I assume the mere act of copying the license (a file called devel.lic which is a small text file) is causing this. Why does it say it “does not seem to be an app”? This self-modification of the files in the Contents/Resources directory is a huge feature. We allow downloading of patches, which add features and fix bugs in the product. Is this going to be a problem, going forward? I don’t remember seeing this result from spctl before and I have a feeling it’s a new , due to tightening of security policies, etc. All of this is quite worrying to us. More details of the app: $ codesign -vvvv mlisp mlisp: valid on disk mlisp: satisfies its Designated Requirement $ codesign -d --entitlements - /Applications/AllegroCL64.app Executable=/Applications/AllegroCL64.app/Contents/MacOS/AllegroCL64 [Dict] [Key] com.apple.security.cs.allow-dyld-environment-variables [Value] [Bool] true [Key] com.apple.security.cs.allow-jit [Value] [Bool] true [Key] com.apple.security.cs.disable-library-validation [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true $ Other details: The app was built with the Command Line tools version 2395 on macOS 12.x.

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

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 Gatekeeper Problems Gatekeeper strives to ensure that only trusted software runs on a user’s Mac. It’s important that your code pass Gatekeeper. If not, you’re likely to lose a lot of customers, and your users’ hard-won trust. There are four common Gatekeeper problems: App blocked by a dangling load command path Broken code signature Lack of notarisation Command-line tool blocked by Gatekeeper The first problem is by far the most common. For the details, see Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. For general information about Gatekeeper, read Apple > Developer > Signing Mac Software with Developer ID and Apple > Support > Safely open apps on your Mac. IMPORTANT This post focuses on Developer ID-signed code. Gatekeeper should not block App Store apps. If an app downloaded from the App Store fails to run, it’s likely to be some other trusted execution issue. For more about this, read Resolving Trusted Execution Problems. macOS 14 introduced gktool, a very minimal interface to Gatekeeper. Run the tool with the help argument to learn more: % gktool help Verify Your Signature A good first step in any Gatekeeper investigation is to verify that your code is signed correctly. Use the codesign tool for this: % codesign -v -vvv --strict --deep MyApp.app The -vvv options increase verbosity to the point where codesign will give you useful diagnostics. For example: % codesign -v -vvv --strict --deep "Munged.app" Munged.app: a sealed resource is missing or invalid file added: …/Munged.app/Contents/Resources/names/Adam.txt file modified: …/Munged.app/Contents/Resources/names/Morgan.txt file missing: …/Munged.app/Contents/Resources/names/Rhonda.txt This app was changed after it was signed in three different ways: Adam.txt was added. Morgan.txt was modified. Rhonda.txt was removed. You might see some results that make no sense. For example: Start with an app with a valid code signature: % codesign -v -vvv --strict --deep "NotNormal.app" NotNormal.app: valid on disk NotNormal.app: satisfies its Designated Requirement Use the Finder to create a zip archive (File > Compress). Use the Finder to unpack that archive. Check the code signature of the unpacked file: % codesign -v -vvv --strict --deep "NotNormal 2.app" NotNormal 2.app: a sealed resource is missing or invalid file added: …/NotNormal 2.app/Contents/Resources/names/Zoë Schrödinger.txt file missing: …/NotNormal 2.app/Contents/Resources/names/Zoë Schrödinger.txt There are two things to note here. First, just compressing and decompressing the app broke its code signature. Weird! Second, look at the error messages. It seems that the Zoë Schrödinger.txt file is was both added and removed. Weirder! To see what’s going on here you have to look at a hex dump of the file name: % ls "NotNormal.app/Contents/Resources/names" | xxd 00000000: 5a6f c3ab 2053 6368 726f cc88 6469 6e67 Zo.. Schro..ding 00000010: 6572 2e74 7874 0a er.txt. % ls "NotNormal 2.app/Contents/Resources/names" | xxd 00000000: 5a6f 65cc 8820 5363 6872 6fcc 8864 696e Zoe.. Schro..din 00000010: 6765 722e 7478 740a ger.txt. The names are not the same! The app started out with the ë in precomposed form and the ö in decomposed form. Compressing and decompressing the app converted the ë to its decomposed form, and that change broke the code signature. Programs that deal with Unicode are expected to ignore differences in normalisation. Sadly, Apple’s code signing implementation missed that memo (r. 68829319). For more details see this post but the executive summary is that it’s best to stick to ASCII when naming files in a bundle. Identify a Notarisation Problem Gatekeeper requires that your app be notarised. If not, it will block the execution of your app with a generic, user-level message. If you find your app blocked by Gatekeeper, check if this is a notarisation issue by looking in the system log for an entry like this: type: info time: 2022-05-11 14:57:21.812176 -0700 process: syspolicyd subsystem: com.apple.syspolicy category: default message: ticket not available: 2/2/8b7410713591e6c79ea98f0132136f0faa55d22a Note If the ticket details show as <private>, enable private data in the system log. For information on how to do that, see Recording Private Data in the System Log. For general information about the system log, see Your Friend the System Log. The long hex number is the code directory hash, or cdhash, of the offending code. In this example, it’s the cdhash of the app itself: % codesign -d -vvv /Applications/NotNotarised.app … CDHash=8b7410713591e6c79ea98f0132136f0faa55d22a … However, in some cases it may be the cdhash of some library referenced by the app. For more information about cdhashes, see TN3126 Inside Code Signing: Hashes. Resolve a Notarisation Problem The obvious cause of this problem is that you haven’t notarised your app. For information on how to do that, see Notarizing macOS Software Before Distribution. If you have notarised your app and yet you still see this problem, something more subtle is happening. For example, your app might reference a dynamic library that wasn’t seen by the notary service. To investigate this: Fetch the notary log for your app. For advice on that, see Fetching the Notary Log. Confirm that the notary log matches the app you installed. Look in the notary log for the sha256 property. Its value is a SHA-256 hash of the file received by the notary service. Check that this matches the SHA-256 hash of the file you used to install your app. If not, see Hash Mismatch, below. Search the notary log for the cdhash value from the Gatekeeper log message. If the notary log doesn’t contain that cdhash, that code wasn’t included in the notarised ticket. It’s possible that you failed to submit the code to the notary service, that it was switched out with a different version after you notarised your app, that it was package in some way that the notary service couldn’t see it, or that something went wrong within the notary service. Hash Mismatch If you stapled your notarised ticket to the file used to install your app then the hashes in step 2 of the previous section won’t match. What to do depends on the file type: If the file used to install your app was a zip archive (.zip), you definitely have the wrong file. Zip archives don’t support stapling. If the file used to install your app was a signed disk image (.dmg), compare the disk image’s cdhash with the cdhash for the disk image in the notary log. If those match, you know you’re working with the same disk image. To dump a disk image’s cdhash, run the codesign tool as follows: % codesign -d -vvv DISK_IMAGE … CDHash=d963af703ac2e54af6609e9ad309abee7b66fae2 … Replace DISK_IMAGE with the path to your disk image. If the file used to install your app was a disk image but it wasn’t signed, switch to a signed disk image. It’s generally a better option. If the file used to install your app was an installer package (.pkg), there’s no good way to know if this is the correct package. In this case, modify your notarisation workflow to retain a copy of the file before it was modified by stapler. Tool Blocked by Gatekeeper If your product includes a command-line tool, you might notice this behaviour: When you double click the tool in Finder, it’s blocked by Gatekeeper. When you run the tool from within Terminal, it works. This is a known bug in macOS (r. 58097824). The issue is that, when you double click a tool in the Finder, it doesn’t run Gatekeeper’s standard execution logic. Rather, the Finder passes the tool to Terminal as a document and that opens a window (and associated shell) in which to run that document. This triggers Gatekeeper’s document logic, and that logic always blocks the tool. There are two ways around this: Embed your tool in an application. If the user runs the application first, Gatekeeper runs its normal application check. If the user allows the app to run, Gatekeeper records that decision and applies it to the app and any code within the app, including your tool. Install your tool using an installer package. When the user goes to install the package, Gatekeeper checks it. Assuming that check passes, Gatekeeper does no further checks on the content it installed. Revision History 2024-11-11 Added a mention of gktool. 2022-05-20 Added the Verify Your Signature section. Made other minor editorial changes.