I am working on releasing my macOS arm64 app. My problem is that after the user downloads the dmg, double-clicking my.app in the dmg, a Gatekeeper pop-up box will appear with a warning that the developer cannot be verified. Question: Can an application signed with "com.apple.security.cs.disable-library-validation" be published as trusted? If yes, what steps have I missed? If not, can I get an official response from Apple? （Because I referred to this post, it seems to mention that it is possible to publish trusted software.I have looked up similar questions on the forum and tried many things, but nothing works. ） Here are my steps: Use the codesign to sign my.app. Because my app needs to access third-party dynamic libraries, entitlements.plist contains a "com.apple.security.cs.disable-library-validation". After the "codesign -dvvv" check, the signature was successful.✅ Use the "xcrun notarytool" command to notarize my app, and the status is displayed as accepted.✅ Use "xcrun stapler staple" to attach the notarization to my app, and it returns success.✅ Use the "spctl -a -v " command to verify whether my app has passed Gatekeeper, and it returns that it has passed.✅ Then I packaged my.app into a dmg, and then attached the notarization mark to the dmg, which was successful.✅ I completed the above steps and distributed the dmg. When I downloaded the dmg as a user test and double-clicked my.app in it, the Gatekeeper pop-up box still appeared, and the developer cannot be verified.❌

We get a "The application "Finder" does not have permission to open "(null)“" error message in macOS 15.1 when trying to open unsigned applications. Is this a known bug in macOS 15.1 ? If so any indications of whether it will be fixed in the future. In macOS 15.0.1 the workaround for launching unsigned applications still worked.

Adobe says that Animate works with the latest Mac OS. When I publish apps with Animate, they work on my computer. With a self-signed certificate, they work on some older Mac OS versions, but not on the 2 most recent. How can I test my apps on others' Mac computers? Robert

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.

Hi, I've recently observed a sudden increase in support requests for one of my apps on the Mac App Store, reporting the error " is damaged and can't be opened. Please re-download it from the Mac App Store", all on different systems: macOS 12, macOS 13, and macOS 15 Sequoia. Re-downloading does not resolve the issue most of the time. One user reported that being connected to the internet resolved it - perhaps this is an OCSP issue again? I myself cannot reproduce this issue. Has there been a change in code-signing recently? Have some certificates changed? Anything else I should be aware of? What is the best course of action to have users take who experience this, when re-downloading the app from the Mac App Store does not work? Thank you, – Matthias

I have tried to manually install binaries using Finder by clicking and dragging from the Desktop into "/usr/local/bin/". The binaries come with a collection of frameworks etc. All the binaries are adhoc signed. macOS asks for Admin credentials which is fine. But then, when I execute the binaries in Terminal, Gatekeeper shows the now expected "'[binary"] Not Opened Apple could not verify ........" etc. It shows that dialog for every component and requires user input 2-3 times to allow each component of which there are perhaps dozens. BUT, none of that happens if I install those binaries using AppleScript. So, it might have a call like this: do shell script "curl -L " &amp; download_URL &amp; " -o " &amp; download_binary_zip with administrator privileges do shell script "unzip -o " &amp; download_binary_zip &amp; " -d " &amp; usr_bin_folder with administrator privileges The resulting installs work perfectly. Is this intended ? Using both install methods requires Admin credentials. Why does using a script work but using Finder does not ?

Hello all, I am building a macOS application that I codesign and notarize for distribution. I am able to download my zip, unzip and run my application successfully, but when I attempt to update to a new version I hit an error with ditto that "operation not permitted" when attempting to replace my .app with the new version. For example, here is a sample output of the failure: Update failed: binary update failed during ditto: ditto: /Applications//tooler.app/Contents/_CodeSignature/CodeResources: Operation not permitted ditto: /Applications//tooler.app/Contents/MacOS/tooler: Operation not permitted ditto: /Applications//tooler.app/Contents/Resources/icons.icns: Operation not permitted ditto: /Applications//tooler.app/Contents/Info.plist: Operation not permitted My application code updates the user to a new version by executing a curl command to download the versions zip and then uses ditto to unzip. I am able to successfully download the zip with the curl command and remove the file with the rm command, but when I try to use ditto to copy and replace my application contents it fails. Here is my application code that does that (The directories are correct for the application and the zip is downloaded): // Download the zip (Works) homeDir, _ := os.UserHomeDir() downloadPath := filepath.Join(homeDir, "Downloads", "tooler.zip") err := exec.Command("curl", "-L", "-H", "Accept: application/octet-stream", "-H", "Authorization: Bearer REMOVED_TOKEN", "-H", "X-GitHub-Api-Version: 2022-11-28", release.AssetURL, "-o", downloadPath).Run() if err != nil { return fmt.Errorf("binary update failed during curl: %v", err) } // Get the executeable path (Works) cmdPath, err := os.Executable() appPath := strings.TrimSuffix(cmdPath, "tooler.app/Contents/MacOS/tooler") if err != nil { appPath = "/Applications/" } // Cleanup function to remove the downloaded .zip (Works) defer func() { err = exec.Command("rm", downloadPath).Run() if err != nil { // return fmt.Errorf("binary update failed during removal: %v", err) } }() // Update application contents (This fails from the operation not permitted) cmd := exec.Command("ditto", "-xk", downloadPath, appPath) var out bytes.Buffer var stderr bytes.Buffer cmd.Stdout = &amp;out cmd.Stderr = &amp;stderr err = cmd.Run() if err != nil { return fmt.Errorf("binary update failed during ditto: %v \n Args: %v \n CmdPath: %v \n AppPath %v", stderr.String(), cmd.Args, cmdPath, appPath) } return nil Also, here are my entitlements: &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.network.client&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.network.server&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.files.user-selected.read-write&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.files.downloads.read-write&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; &lt;/plist&gt; Anyone have any ideas on why the ditto command won't let me update the application contents and returns operation not permitted?

Hey all, I am working on my self updater and I am hitting an error replacing my binaries. Basically, when there is a new release my self updater checks and prompts the user to update. When the user accepts to update my applicaiton will download the .zip for the specified version and for the operating system, which is darwin in this case. Then, once the .zip has been download I use ditto to replace the existing binaries, but I am hitting the error "Operation not permitted" on darwin. Here is my code for updating: // Download zip of latest version (Works) homeDir, _ := os.UserHomeDir() downloadPath := filepath.Join(homeDir, "Downloads", "tooler.zip") err := exec.Command("curl", "-L", "-H", "Accept: application/octet-stream", "-H", "Authorization: Bearer REMOVED_TOKEN", "-H", "X-GitHub-Api-Version: 2022-11-28", release.AssetURL, "-o", downloadPath).Run() if err != nil { return fmt.Errorf("binary update failed during curl: %v", err) } // get executable path for where we need to replace (Works) cmdPath, err := os.Executable() appPath := strings.TrimSuffix(cmdPath, "tooler.app/Contents/MacOS/tooler") if err != nil { appPath = "/Applications/" } // Cleanup zip after everything executes defer func() { err = exec.Command("rm", downloadPath).Run() if err != nil { // return fmt.Errorf("binary update failed during removal: %v", err) } }() // Replace .app contents, but hits "operation not permitted" (Does not work) cmd := exec.Command("ditto", "-xk", downloadPath, appPath) var out bytes.Buffer var stderr bytes.Buffer cmd.Stdout = &amp;out cmd.Stderr = &amp;stderr err = cmd.Run() if err != nil { return fmt.Errorf("binary update failed during ditto: %v \n Args: %v \n CmdPath: %v \n AppPath %v", stderr.String(), cmd.Args, cmdPath, appPath) } return nil The first message before the line break is my application logging where the failure was and the rest of "ditto:" messages are the errors output by ditto. Update failed: binary update failed during ditto: ditto: /Applications//tooler.app/Contents/_CodeSignature/CodeResources: Operation not permitted ditto: /Applications//tooler.app/Contents/MacOS/tooler: Operation not permitted ditto: /Applications//tooler.app/Contents/Resources/icons.icns: Operation not permitted ditto: /Applications//tooler.app/Contents/Info.plist: Operation not permitted Here are my entitlements &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.network.client&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.network.server&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.files.user-selected.read-write&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.files.downloads.read-write&lt;/key&gt; &lt;true/&gt; &lt;/dict&gt; &lt;/plist&gt; Could this ditto error that the operation is not permitted be related to my entitlements? My .app is signed and notarized before distribution. I am able to download the zip, unzip and run the application without problems other than when I try to run the self update and it fails due to "operation not permitted".

I've successfully uploaded my macos app to tesflight (it's a game based on Unreal Engine5). It has passed all checks and is now in testflight, but when i launch it it says "The application can't be opened. -10673" And pops up another windown : "The beta app, , is no longer available. The provisioning profile is invalid" The provisioning profile doesn't specify OS versions - it's signed with distribution and installation certificates for AppStore. What would cause this? How can I fix this? MacOS version 14.5

I’ve got a run of the mill Drag&amp;Drop DMG installer. It works as expected when the drop target is /Applications. However I deliver plugins which I want to be copy to somewhere below /Library/Aplication Support/. Here too, everything works fine until I upload and download the dmg to my webserver. Now when dropping the plugins onto the target alias they just slide back. No error, no dialog asking for permissions, no nothing… just silently sliding back. And I haven’t the faintest idea how to address this. Would somebody please be my hero of the day and point me into the right direction, pretty please? The plugins and the dmg are codesigned and notarized. They work as expected when moving them to the plugins folder directly. It’s only the alias that will not work. The alias btw. is a soft link created using ln - s. Not sure this is the right category to post in. But it feels like it’s a probably a permission/entitlements issue.

Due to changes in macOS 15 Sequoia with respect to container privacy/privileges, I have observed warnings with one of my apps (non-sandboxed) when its subsidiary crash reporter process tries to access the host app's data folder. I THINK I've worked around this issue by granting the crash reporter and the host app access to the same application group. I'm not 100% sure how all this works except that the problem went away :) The problem is, once the problem goes away on a given system, it goes away for good! Even with subsequent attempts to open a version of the app before the fix was in place, the system warning is not presented. I've tried to reset SystemPolicyAppBundles on the app via tccutil, but it makes no difference. Using the wisdom from one of Quinn's posts (https://developer.apple.com/forums/thread/706442) I set up a log stream invocation to try to gather clues, and I notice that when I launch my app now, I see messages like: Found provenance data on process: TA(82542d1beaf132a6, 2), 51084 Process was already in provenance sandbox, skipping: 51084, TA(82542d1beaf132a6, 2) I suspect this "provenance" may reflect the change in how the system treats my application. First: I wonder if it's a bug that any change in "provenance" should retroactively apply to versions of the app before the change was made. Second, I wonder if there's some way to RESET this provenance so that I can reproduce the bug again? I might be able to reproduce it by changing the bundle ID for the app but for purposes of testing against existing, shipped versions of the app, I'd love to be able to reset things for sanity-checking.

We have a test tool our engineers use to launch various versions of our application during development and verification. Each daily build of our application is stored on a server. As well, each push of a change generates a new build of our application that is stored on a server. These are added to a database and the developer application accesses the server via REST to find the desired version to run, retrieves a server path and launches the application. This tool is valuable in finding pushes that introduced regressions. The developer application (Runner) is using the launchApplicationAtURL:options:configuration:error: (deprecated I know) to launch the app. Prior to Catalina, this was working great. However, as of Catalina, this process is taking a VERY long time due to the app needing to be "verified". the app seems to need to be copied to the users machine and verified. It only occurs the first launch, but as most of the time the users are running new push or daily builds, it has made the app useless. With the new remote work environment it is even worse as VPN copy can take forever. I have switched to using NSTask with a shell script to open the executable in the bundle. If I add the developer tool (Runner) to the Developer Tools in Privacy this seems to launch the application without the need for verification. However this just seems wrong. It also provides little feedback to know when the application is up and running, which makes my user experience poor. As well many of the systems we use this tool on for verification do not have Developer Tools installed. They are VMs. Is there a way for me to use the launchApplicationAtURL:options:configuration:error: (or the new openApplicationAtURL:configuration:completionHandler:) to launch these versions of the application without the need for the lengthy verification process? Adding our application to the Developer Tools did not seem to help.