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?

In my application I validate the authenticity of my own binaries by checking that the Team Identifier in the code signature matches a predefined value. Currently I do not perform a full signature validation that verifies the certificate chain up to Apple’s root CA. When attempting to do this using SecStaticCodeCheckValidityWithErrors (or validateWithRequirement), the operation sometimes takes several minutes. During that time the calling thread appears blocked, and the system logs show: trustd: [com.apple.securityd:SecError] Malformed anchor records, not an array Because of this delay, I decided to rely only on the Team Identifier. My question is: Can it be assumed that if a Mach-O binary contains a Team Identifier in its code signature, then it must have been signed with a valid Apple Developer certificate? Or are there cases where a binary could contain a Team ID but still not be signed by Apple’s trust chain? Thanks for the help !

I am responsible for the mobile app and thus also of the apple developer and app store connect accounts of a company. An external freelancer developed a software package for us which we aim to offer for installation and use on macOS systems of our customers; distributed exclusively outside of the Apple App Store. The software package has nothing to do with the mobile app. MacOS' Gatekeeper currently warns or even prevents our customers regarding the installation of the package on their device; pretty much as described here: https://developer.apple.com/developer-id/. According to a previous talk with Apple's Support, the software package (.app) the Freelancer developed must be signed with one of our own certificates. As we cannot grant selective app store connect access to third persons (only for the concerned certificates), we prefer to not provide access to our entire apple developer account to the freelancer, for the sole reason of the certificate & signing process. According to previous attempts with Apples' support regarding the most feasible solution in this case, they recommended me to manage the signing of the package of the freelancer, and simply request the package from the freelancer. I've thus generated an according Developer ID Certificate, but regarding the signing process, I'm confused. I know how signing works with mobile apps in XCode, but regarding software that is not distributed throughout the App Store on macOS, I'm unsure about the process. Also, as far as I know, the entitlements of the application are involved in the signing process. So my concern is that simply having the software package (.app) from the freelancer is not really enough to complete the signing + notarization process? Won't I need further information about the app's entitlements etc.? I would like to have a clear solution about the procedure that is required in these cases, as online documentations and / or forums as well as previous talks with your non-technical support from Apple did not resolve the issue.

Apple is encouraging VPN apps on macOS to transition to Network Extension APIs, if they haven't done so yet, see: TN3165: Packet Filter is not API WWDC25: Filter and tunnel network traffic with NetworkExtension Using Network Extension is fine for VPN apps that are distributed via the Mac App Store. Users get one pop-up requesting permission to add VPN configurations and that's it. However, VPN apps that are distributed outside of the App Store (using Developer ID) cannot use Network Extension in the same way, such apps need to install a System Extension first (see TN3134: Network Extension provider deployment). Installing a System Extension is a very poor user experience. There is a pop-up informing about a system extension, which the user has to manually enable. The main button is "OK", which only dismisses the pop-up and in such case there is little chance that the user will be able to find the correct place to enable the extension. The other button in that pop-up navigates to the correct screen in System Settings, where the user has to enable a toggle. Then there is a password prompt. Then the user has to close the System Settings and return to the app. This whole dance is not necessary for VPN apps on the Mac App Store, because they work with "app extensions" rather than "system extensions". As a developer of a VPN app that is distributed outside of the App Store, my options are: Implement VPN functionality in an alternative way, without Network Extension. This is discouraged by Apple. Use a System Extension with Network Extension. This is going to discourage my users. I have submitted feedback to Apple: FB19631390. But I wonder, why did Apple create this difference in the first place? Is there a chance that they will either improve the System Extension installation process or even allow "app extensions" outside of the Mac App Store?

My post-build script takes the "developeridexport" archive export, zips it up and uses notarytool to notarize it. I then add the .zip to a .dmg disk image. The next step is to codesign the disk image before notarizing that too. The issue is my Developer ID Application certificate is not accessible to the build host. (When I was doing this in Microsoft AppCenter (now defunct), it had a copy of my Developer ID Application certificate.) What steps do I need to take to get the disk image signed for notarization? Thanks! Lance

The problem is described in full with log output in #16844 We are having an issue with TCC prompting users for access to the app group container despite signing with entitlements following all guidelines. This is a regression from the Feb 2025 Changes discussed in App Groups: macOS vs iOS: Working Towards Harmony The problem can only be reproduced with Xcode 16.0 and later. The entitlements for the app include access for the group container with [Key] com.apple.security.application-groups [Value] [Array] [String] G69SCX94XU.duck The documentation notes the group name can be arbitrary, e.g. <team identifier>.<group name>. Cyberduck uses G69SCX94XU.duck by default. Interestingly enough the alert is not shown when a group name matching the bundle identifier is used, e.g. G69SCX94XU.ch.sudo.cyberduck.