Trusted execution is a generic name for a Gatekeeper and other technologies that aim to protect users from malicious code. General: Forums topic: Code Signing Forums tag: Gatekeeper Developer > Signing Mac Software with Developer ID Apple Platform Security support document Safely open apps on your Mac support article Hardened Runtime document WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04: 32), most notably app bundle protection WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46), namely, app container protection WWDC 2024 Session 10123 What’s new in privacy covers an important change in macOS 15 (starting at 12:23), namely, app group container protection Updates to runtime protection in macOS Sequoia news post Testing a Notarised Product forums post Resolving Trusted Execution Problems forums post App Translocation Notes forums post Most trusted execution problems are caused by code signing or notarisation issues. See Code Signing Resources and Notarisation Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I admit I am doing something unusual, and I would not be surprised if it didn't work. I am surprised, however, because after performing the equivalent operations on four bundles, all of the bundles work fine on macOS 15.6.1, but only two of them work on macOS 26.1 (beta 2). I don't know what causes the different outcomes. What I am trying to do is get Java to pass the macOS 26 AppKit UI SDK linkage checking without having to rebuild the JDK using Xcode 26. Rebuilding works for the latest SDK, but it is very inconvenient and may not work for older JDKs. It usually takes a while before the JDK build team successfully transitions to a new Xcode release. My approach is to use vtool to update the sdk version in the LC_BUILD_VERSION load command of $JAVA_HOME/bin/java, which is the launching executable for the JDK. I performed this operation on four JDKs: 25, 21, 17, and 11. (I ran vtool on macOS 15.) It was completely successful on JDK 25 and 21. The JDK launches correctly on macOS 15 and macOS 26. On macOS 26, AppKit uses the new UI, which is the desired outcome. The JDK runs despite that fact that I signed the modified $JAVA_HOME/bin/java with my developer ID, which is inconsistent with the JDK bundle signature. (Redoing the bundle signing is part of the JDK build process; if that were necessary, I would stick with rebuilding the JDK.) The operation was not successful on JDK 17 and 11. I noticed two problems, which are not obviously related. When vtool created the new version of the java program, it lost the tool definition. $ vtool -show-build-version java java: Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 11.0 sdk 11.1 ntools 1 tool LD version 609.8 $ vtool -set-build-version 1 10.0 26.0 -output a.out java /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool warning: code signature will be invalid for a.out $ vtool -show-build-version a.out a.out: Load command 22 cmd LC_BUILD_VERSION cmdsize 24 platform MACOS minos 10.0 sdk 26.0 ntools 0 Adding back the tool definition didn't seem to matter. When I try to run the revised executable (in the context of the JDK bundle), it works on macOS 15, but on macOS 26, it is rejected as damaged. If I run the revised executable outside the JDK bundle, it runs (but fails because it can't find the rest of the JDK, which is expected). In all cases, GateKeeper rejects the revised executable because it has not been notarized, but that doesn't seem to stop the program from executing.

We have an application which keeps throwing the error "application is damaged and cannot be opened. You should move it to Trash" I have already referred to the documentation: https://developer.apple.com/forums/thread/706379 and https://developer.apple.com/forums/thread/706442 I have checked the following possible root causes: Codesign of the application using the codesign command Notarization of the application using the spctl command Executable permissions Checked for the presence of "com.apple.quarantine" flag for the application using xattr -l <path to executables" Checked the bundle structure None of the above listed items seemed to be a problem and are as expected. Can you please help us understand what could cause this issue and how to resolve this without recommending an uninstall/reinstall of the application?

I have a Qt desktop app that I was shipping to users as a dmg on macOS. But now I'll need to kind of rebrand the app to different users, that rebranding involves changing the name and the icon of the app I'm not sure how feasible that is on macOS but here's what I'm thinking: First I'll include all apps for all brands inside the app resources, and instead of shipping the app directly, I will ship and installer (either .pkg or a custom made installer app) that will be responsible for downloading the main app and also setting some environmental variables somewhere so that I can choose the icon from the resources based on the env var values. And then either change the app icon and name from the installer itself, or implement something inside the app that makes it change the icon and name on launch (both icon in finder and in dock) but maybe one of those methods (or both) will break the codesign/notarization of the app so I want to avoid that too I'm not sure if someone has done this before or how feasible such scenario is. Is what I'm thinking valid? or is there a whole other way possibly easier than this to go about implementing such feature? The purpose of this is that I don't want to have to create multiple releases for multiple brands when they're all the same application with different icons/names, and also when releasing an update it will be just one update for all brands Thank you in advance and feel free to ask any further questions for clarification

Can you please help us with the scenario below, including details and Apple’s recommendations? I've already read through the Notarization and Gatekeeper documentation. The installed version of our application is 1.2.3, located in /Applications/XYZSecurity.app. We created an upgrade package for version 1.2.4. As part of the pre-install script in the 1.2.4 installer, we explicitly deleted some obsolete .dylib files from /Applications/XYZSecurity.app/Contents/Frameworks and some executable files from /Applications/XYZSecurity.app/Contents/MacOS that were no longer needed in version 1.2.4. The installation of version 1.2.4 completed successfully, but we see the below error logs in installer.log: PackageKit: Failed to unlinkat file reference /Applications/XYZSecurity.app/Contents/Frameworks/libhelper.dylib PackageKit: Failed to unlinkat file reference /Applications/XYZSecurity.app/Contents/MacOS/helper-tool Our Key Questions: Is it the right practice to remove obsolete files in the pre-install script during an upgrade? Is this approach recommended by Apple? Can this cause any issues with Apple Gatekeeper? Is there a possibility of my application getting blocked by Gatekeeper as a result?

I have an application that I have been signing, notarizing and distributing to beta testers for a year with no issues, note: I have never got stapling to work I always get a error 65 in the process. But up until yesterday that hasn't been an issue and online verification has always worked. Yesterday morning around 9am online gatekeeper verification has been failing with: APP not opened, apple cannot verify app is free of malware. etc this keeps happening, with every build I try. redownloading previously successful builds show the same behavior I know I can allow in privacy and security, but heading towards launch I dont want to have to tell users to do that. has there been a change in how gatekeeper works or issues with the service? any help with this or getting stapling working would be very appreciated!

productsign Command Appears to Succeed but Package has No Valid Signature Category: Security, macOS, Code Signing Question: productsign command, when signing a PKG created with productbuild, appears to succeed with a success message (Wrote signed product archive to ...) but spctl verification results in rejected, source=no usable signature, indicating that the signature was not actually applied. Details: Goal: To sign a distribution package created with productbuild using a Developer ID Installer certificate. Certificate Used: Developer ID Installer: [Company Name] ([Team ID]) This certificate was issued by Previous Sub-CA and is not the latest G2 Sub-CA recommended by Apple. We cannot create a new G2 Sub-CA certificate as we have reached the limit of 5. productsign Command: productsign --sign "Developer ID Installer: [Company Name] ([Team ID])" [input.pkg] [output.pkg] productsign Output: Wrote signed product archive to [output.pkg] (Appears as a success message). spctl Signature Verification: spctl -a -vv [output.pkg] Result: rejected, source=no usable signature Notarization Service Results (Behavioral difference between Macs): On Mac A, the submission status was Accepted. On Mac B, the status was Invalid, with the notarization log message being The binary is not signed.. Troubleshooting Steps Taken: We attempted to sign both component and distribution packages with productsign, and in both cases, the signature was not recognized by the system. We skipped productsign and relied on the notarization service's auto-signing, but the notarization log still reported The binary is not signed., and the notarization failed. We have confirmed that the certificate and private key are properly associated in Keychain Access. My Questions: Given that we are using an older Previous Sub-CA certificate and cannot create a new one, why does productsign appear to succeed when the signature is not being applied? What could cause the behavioral difference where notarization is Accepted on Mac A but Invalid on Mac B? Is this a known issue with Apple's tools, or is it possibly caused by the specific structure of our PKG? What is the recommended workflow or debugging method to successfully sign and notarize a PKG under these circumstances? Thank you for your assistance

A user of my AppKit, document-based app brought to my attention that when setting it as the default app to open a certain file with extension .md (by choosing in the Finder "File &gt; Open With &gt; Other", then selecting my app and enabling "Always open with"), trying to open it with a double-click displays the warning "Apple could not verify [file] is free of malware that may harm your mac or compromise your privacy". This is what happens for me: When keeping the default app for a .md file (Xcode in my case), the file opens just fine. When choosing my app in the "File &gt; Open With" menu, the file opens just fine in my app. But when setting my app as the default app (see above), the warning is displayed. From that moment on, choosing my app in the "File &gt; Open With" menu doesn't work anymore. Selecting Xcode doesn't work either. Only setting Xcode again as the default app allows me to open it in Xcode, but my app still isn't allowed to open it. Is this a macOS issue, or can I do anything in my app to prevent it? Where should I start looking for the issue in my code?

Hey, when I try to launch my app it prompts me with a "Apple could not verify" popup. The thing is the app has been signed and stapled. xcrun stapler validate .app for my app returns "The validate action worked!" If I also run syspolicy_check distribution .app it returns: "App passed all pre-distribution checks and is ready for distribution" Any idea?

We distribute our macOS products as a PKG downloaded from our website. To simplify configuration for our customers, we create a PKG for each customer that contains identifying data for that customer. We are currently doing this by notarizing the PKG for each customer and uploading the result. Since we sometimes exceed the notarization limit of 75/day, we began investigating other ways of including the identifying data. One avenue seemed to be the extended attribute com.apple.application-instance, but after experimentation it appears that this attribute does not persist through downloads. There are very few resources describing this attribute (TN2206) but a close reading seems to confirm that the attribute has to be set on the user’s machine. Can you confirm that this is the case? Is there any other way for customizing an installer PKG that won’t run afoul of notarization limits?

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Put it in the Code Signing > General subtopic and tag it with relevant tags like Gatekeeper, Code Signing, and Notarization — so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing content in a bundle Embedding nonstandard code structures in a bundle Embedding a command-line tool in a sandboxed app Creating distribution-signed code for macOS Packaging Mac software for distribution Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. Later sections of this post address the most common ones. But first, let’s see if there’s an easy answer. Run a System Policy Check macOS has a syspolicy_check tool that can diagnose many common trusted execution issues. To check an app, run the distribution subcommand against it: % syspolicy_check distribution MyApp.app App passed all pre-distribution checks and is ready for distribution. If there’s a problem, the tool prints information about that problem. For example, here’s what you’ll see if you run it against an app that’s notarised but not stapled: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: MyApp.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error … Note In reality, stapling isn’t always required, so this error isn’t really Fatal (r. 151446728 ). For more about that, see The Pros and Cons of Stapling forums. And here’s what you’ll see if there’s a problem with the app’s code signature: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Codesign Error File: MyApp.app/Contents/Resources/added.txt Severity: Fatal Full Error: File added after outer app bundle was codesigned. Type: Notary Error … The syspolicy_check isn’t perfect. There are a few issues it can’t diagnose (r. 136954554, 151446550). However, it should always be your first step because, if it does work, it’ll save you a lot of time. Note syspolicy_check was introduced in macOS 14. If you’re seeing a problem on an older system, first check your app with syspolicy_check on macOS 14 or later. If you can’t run the syspolicy_check tool, or it doesn’t report anything actionable, continue your investigation using the instructions in the following sections. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code on systems prior to macOS 26 beta. macOS 26 beta supports arm64e apps directly. Prior to that, third-party products (except kernel extensions) were limited to arm64, except for the purposes of testing. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running App Store distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2025-08-06 Added the Run a System Policy Check section, which talks about the syspolicy_check tool (finally!). Clarified the discussion of arm64e. Made other editorial changes. 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

Background We are using a Developer ID application certificate to sign our application. We lost the private key and we need to revoke it before we can receive a new one. Per documentation (https://developer.apple.com/support/certificates/), I know that previously installed applications will still be able to run, but new installations will not be able to work. I want to confirm what will happen when we revoke the certificate so we know how to prepare customers for this upcoming change. Questions Will existing installations of the application receive a notice that the certificate has been revoked? Will previously installed applications be able to launch again after they are closed? What will the user see when they try to install the application with the revoked certificate?

Hello everyone, I'm hoping to get some guidance on a frustrating codesigning issue. I have a macOS application that successfully completes the entire notarization and stapling process, but it is still rejected by Gatekeeper during the final verification step. The rejection only happens when I apply the entitlements that I believe are necessary for my app's functionality. The application is built with PyInstaller and has the following components: A main executable written in Python. A bundled Tcl/Tk instance for the GUI. Embedded Playwright components, which include the Node.js runtime and a full Chromium browser instance. These are located deep inside the .app bundle. The Problem The core of my application relies on Playwright to perform some automated tasks, and its bundled Chromium browser requires specific entitlements to function under the Hardened Runtime. Specifically, it needs com.apple.security.cs.allow-jit and com.apple.security.cs.allow-unsigned-executable-memory. My signing process is as follows: Prepare Entitlements: I use two separate .plist files: main_app_entitlements.plist: This is for the main Python executable and only contains com.apple.security.cs.allow-jit. jit_helper_entitlements.plist: This is for the node and Chromium Helper executables within the Playwright framework. It contains both com.apple.security.cs.allow-jit and com.apple.security.cs.allow-unsigned-executable-memory. Inside-Out Signing: I perform a deep signing process. I find all binaries, dylibs, and frameworks, sort them by path length (deepest first), and sign each one individually with the appropriate entitlements. The main .app bundle is signed last. Notarization: I zip the .app bundle and submit it using xcrun notarytool submit --wait. The tool reports a successful notarization every time. Stapling: I use xcrun stapler staple on the .app bundle, and it confirms that the ticket was successfully stapled. The point of failure The final step is to verify the result with spctl: spctl --assess --type execute --verbose --ignore-cache "MyApp.app" This is where it fails. The output is: MyApp.app: rejected source=Unnotarized Developer ID This "Unnotarized Developer ID" message is confusing because xcrun notarytool and stapler both report complete success. The crucial detail If I run the entire process without any entitlements—just signing with the Hardened Runtime enabled—the final spctl assessment passes. However, the application then crashes at runtime as soon as it tries to use Playwright, which is expected since the browser helpers are missing their required JIT entitlements. My question Is there a known issue where using com.apple.security.cs.allow-jit or com.apple.security.cs.allow-unsigned-executable-memory on nested helper executables can invalidate an otherwise successful notarization? Is my strategy of applying different, granular entitlements to different executables within the same app bundle correct? Could the issue be related to how or when these entitlements are applied during an "inside-out" signing process? Is there a better way to structure the signing of these complex components? I'm confident the notarization itself is working, but it seems Gatekeeper's local assessment is stricter and is being tripped up by my entitlement configuration. Thank you in advance for any help or suggestions you can provide

I’m facing an issue with my macOS app after code signing and notarization. The app is signed with my Developer ID and notarized using xcrun notarytool. Everything works fine on the machine where the signing was done — Gatekeeper accepts it, no warning appears, and codesign/spctl checks pass. However, when running the same .app on other Macs, users receive a Gatekeeper warning saying the app is "malicious software and cannot be opened". The signature is valid and the notarization log shows status: Accepted. What I've tried: Verified signature with codesign --verify --deep --strict --verbose=2 Checked notarization status via xcrun notarytool log Assessed Gatekeeper trust with spctl --assess --type execute Everything passes successfully on the development machine. Why would the app be treated as malicious on other systems even after notarization? I'm happy to share logs and technical details if needed.

We're interested in adopting App Sandbox in an app distributed outside of the Mac App Store. However, we're hitting a bit of a roadblock and it doesn't seem like either of the techniques described in that post can be used in a reasonable way. For background, this is a third-party launcher for a cross-platform Java game that, among other things, makes it easier for users to mod the game. Users generally download mods as .jar files and place them in a certain directory. In some cases, these mods contain native dynamic libraries (e.g. a .dylib) as part of their code. In general, the .dylib is extracted from the contents of the .jar to some temporary location, loaded, and then deleted once the game closes (the exact details, like the actual temporary location, depends on the mod). App Sandbox greatly interests us in this case because it can limit the damage that a compromised mod could do, and in my testing the functionality of most mods still works with it enabled. However, sandboxed apps quarantine every file they write to by default. Unfortunately, most mods are created by individual developers who don't notarize their libraries (their mods are generally cross-platform, and they're likely just using third-party code that they bundle with the mod but don't sign or notarize). [1] This means that a mod that loads a dynamic library as described above triggers Gatekeeper as described in the documentation if the app is sandboxed, but does not if the sandbox is disabled. Even worse, a user often can't bypass the warning even if they trust the mod because the extracted library is usually a temporary file, and generally is deleted after the failure (which usually causes the game to crash and thus close). By the time they try to approve the code in System Settings, the file is gone (and even if they could approve it, this approval wouldn't stick next time they launch the game). In theory it would work to use an unsandboxed XPC service to remove the quarantine and let the libraries through. However, this is easier said than done. We don't control the mods' code or how they go about loading whatever code they need, which limits what we can do. [1] And in some cases, people like to play old versions of the game with old mods, and the versions they're using might've been released before notarization was even a thing. The closest thing I can think of to a solution is injecting code into the Java process that runs code to call out to the XPC service to remove the quarantine before a library loads (e.g. before any calls to dlopen using dyld interposition). A prototype I have... works... but this seems really flimsy, I've read that interposition isn't meant to be used in non-dev tools, and if there's a better solution I'd certainly prefer that over this. Other things we've tried have significant downsides: com.apple.security.files.user-selected.executable requires user selection in a file picker, and seems to be more blunt than just allowing libraries/plugins which might lead to a sandbox escape [2] Adding the app to the "Developer Tools" section in System Settings > Privacy & Security allows the libraries to load automatically, but requires users to add the app manually and also sounds like it would make a sandbox escape very easy [2] Oh, and I also submitted an enhancement request for an entitlement/similar that would allow these libraries to load (FB13795828) but it was returned as "no plans to address" (which honestly wasn't that surprising). [2] My understanding is that if a sandboxed process loads libraries, the library code would still be confined by the sandbox because it's still running in the sandboxed process. But if a sandboxed process can write and open a non-quarantined app, that app would not be within the confines of the sandbox. So basically we want to somehow allow the libraries to load but not allow standalone executables to run outside the sandbox. In general the game and almost all popular mods I've tested work with App Sandbox enabled, except for this Gatekeeper snag. It would be a shame to completely abandon App Sandbox for this reason if everything else can be made to work. This situation seems not super common, but documentation does say When your sandboxed app launches for the first time, macOS creates a sandbox container on the file system (in ~/Library/Containers) and associates it with your app. Your app has full read and write access to its sandbox container, and can run programs located there as well. which leaves me wondering whether the Gatekeeper prompt is even intended behavior since the libraries are in the sandbox container and written by the app. (By the way, my testing of the claim that apps can run programs in their sandbox container didn't seem to confirm what the documentation said, even without quarantine - FB15963761). Though, given the other documentation page I linked above which more directly references Gatekeeper and quarantined plug-ins, I doubt this is a bug. I suppose the final question is, is this just a situation where App Sandbox won't work (at least in any supported way)? Or is there perhaps some technique we're missing?

This is a continuation of my own old post that became inactive to regain traction. I am trying to resolve issues that arise when distributing a macOS app with a SysExt Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate. To directly distribute the app, I start with exporting the .app via Archive in Xcode. After that, I create a new Developer ID provisioning profile for both the app and sysext and replace the embedded ones in the .app package. After I have replaced the provisioning profiles and the have the entitlements files ready, I start signing the frameworks, sysext and parent app. codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/MacOS/<sysext> codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app After validation is successful with codesign --verify --deep --strict --verbose=4 <app>.app I zip the package, notarize and staple it ditto -c -k --keepParent "<app>.app" "<app>..zip" xcrun notarytool submit <app>.zip --keychain-profile “”<credents> --wait xcrun stapler staple <app>.app After that I finish creating signed and notarized .dmg/.pkg. hdiutil create -volname “<app>” -srcfolder “<app>.app/" -ov -format UDZO ./<app>.dmg codesign --force --sign "Developer ID Application: <name>" <app>.dmg xcrun notarytool submit <app>.dmg --keychain-profile "<credentials>" --wait xcrun stapler staple <app>.dmg Then when I move the .dmg to a clean system, open the .dmg, move the .app to the Applications folder, the attempt to run it fails with “The application “” can’t be opened.”. When I look into the console, the gatekeeper disallows the launch job with the message:
 86127 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: { "com.apple.developer.networking.networkextension" = ( "packet-tunnel-provider-systemextension" ); "com.apple.developer.system-extension.install" = 1; "com.apple.developer.team-identifier" = <teamid>; "keychain-access-groups" = ( “<teamid>.<app>.AppGroup" ); } com.apple.ManagedClient
<app>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, keychain-access-groups, com.apple.developer.system-extension.install, com.apple.developer.team-identifier LAUNCH: Runningboard launch of <app> <private> returned RBSRequestErrorFailed, error Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600001a25830 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}, so returning -10810

 I went through all possible formats (macOS-Style and iOS-Style App Group IDs) and combinations of appgroups according to the post “App Groups: macOS vs iOS: Working Towards Harmony”. But none of those work for me. The weird part is that when I try the same steps on different developer account, I am able to get the app running. What can be wrong?

Is it possible to directly distribute a macOS app with a Developer ID Certificate that belongs to a different team? I am trying to resolve issues that arise when distributing a macOS app with a Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate from a different team than the app’s provisioning profiles and entitlements. I started by attempting Direct Distribution in Xcode with automatic signing. However, it fails with the following message: Provisioning profile "Mac Team Direct Provisioning Profile: ” failed qualification checks: Profile doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. I suspect the issue is that the provisioning profile allows "packet-tunnel-provider-systemextension", whereas the entitlements generated by Xcode contain "packet-tunnel-provider". When I manually modify the .entitlements file to include the -systemextension suffix, the project fails to build because Xcode does not recognize the modified entitlement. If there is a workaround for this issue, please let me know. Due to these issues, I resorted to manually creating a signed and notarized app. My process is as follows: Export the .app from the Xcode archive. Since the exported .app does not contain the necessary entitlements or provisioning profile for direct distribution, I replace Contents/embedded.provisioningprofile in both the .app and the .appex network extension. Sign the app and its components in the following order: codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/PlugIns/<netext>.appex/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/PlugIns/<netext>.appex/ codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app Verify the code signature: codesign --verify --deep --strict --verbose=4 <app>.app - <app>.app: valid on disk - <app>.app: satisfies its Designated Requirement Create a ZIP archive using: ditto -c -k --sequesterRsrc --keepParent <app>.app <app>.zip Notarize the app with notarytool and staple it. The notarization completes successfully with errors: nil. Package the notarized app into a DMG, notarize, and staple the DMG. The app runs successfully on the development machine. However, when moved to another machine and placed in /Applications, it fails to open. Inspecting Console.app reveals Gatekeeper is blocking the launch:
 taskgated-helper <bundleid>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, com.apple.developer.team-identifier taskgated-helper entitlements: { "com.apple.developer.networking.networkextension" = ("packet-tunnel-provider-systemextension"); "com.apple.developer.team-identifier" = <teamid>; } As mentioned earlier, the Developer ID Certificate used for signing belongs to a different team. We are a third-party developer and do not have access to the Developer ID Certificate of the team assigned as the team-identifier. When I changed the bundle identifier (app ID), team, entitlements, and provisioning profiles to match the team associated with the Developer ID Certificate, the app worked. My question is:
 Is this failure caused by using a Developer ID Certificate from a different team, or should it still work if the provisioning profiles and entitlements are correctly set? Could there be an issue elsewhere in the provisioning profiles or entitlements for the original app ID?

Hello, I'm working on an app at work and we finally got to signing and notarizing the app. The app is successfully notarized and stapled, I packaged it in a .dmg using hdiutil and went ahead and notarized and stapled that as well. Now I tried to move this app to another machine through various methods. But every time I download it from another machine, open and extract the contents of the dmg and attempt to open the app, I get the "Apple could not verify my app is free of malware that may harm your Mac or compromise your privacy. When I check the extended attributes there's always the com.apple.quarantine attribute which from what I know, is the reason that this popup appears I've tried uploading it to google drive, sending through slack, onedrive, even tried our AWS servers and last but not least, I tried our Azure servers (which is what we use for distribution of the windows version of our app). I tried uploading to Azure through CloudBerry (MSP360 now), and azure-cli defining the content-type as "application/octet-stream", the content-disposition as "attachment; filename=myApp.dmg", and content-cache-control as "no-transform". None of these worked The only times where a download actually worked with no problems was when I downloaded through the terminal using curl, which obviously not a great solution especially that we're distributing to users who aren't exactly "tech savy" I want the installation experience to be as smooth as other apps outside the App Store (i.e Discord, Slack, Firefox, Chrome etc....) but I've been stuck on this for more than a week with no luck. Any help is greatly appreciated, and if you want me to clarify something further I'd be happy to do so

Hi fellow developers, I built Video Restore AI which uses a number of models with CoreML on macOS to provide simple one-blick video upscaling and colorization. After uploading my archive, I received the following notification through email. ITMS-91109: Invalid package contents - The package contains one or more files with the com.apple.quarantine extended file attribute, such as “{com.kammerath.VideoRestore.pkg/Payload/Video Restore AI.app/Contents/Resources/ECCV16Colorize.mlmodelc/weights/weight.bin}”. This attribute shouldn’t be included in any macOS apps distributed on TestFlight or the App Store. Starting February 18, 2025, you must remove this attribute from all files within your macOS app before you can upload to App Store Connect. How do I deal with this? Is there a way to get Apple to just accept the model contents or do I need to convert it again with coremltools? Many thanks in advance! Jan

In XCode I create and export a notarized app for "direct distribution". I then create a tar file of the exported .app to distribute to my users. Until today this worked fine. Now when the users try to run the app it pops up a dialog saying "app is damaged and can't be opened. You should move it to the Trash." It is possible to ctrl-click on the app and force it to run but, I think, whether this works or not will depend on system settings and not all users have root access to modify settings. Even simply copying the .app folder from the command line will cause this error.