Code signing uses various different identifier types, and I’ve seen a lot of folks confused as to which is which. This post is my attempt to clear up that confusion. If you have questions or comments, put them in a new thread, using the same topic area and tags as this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Code Signing Identifiers Explained An identifier is a short string that uniquely identifies a resource. Apple’s code-signing infrastructure uses identifiers for various different resource types. These identifiers typically use one of a small selection of formats, so it’s not always clear what type of identifier you’re looking at. This post lists the common identifiers used by code signing, shows the expected format, and gives references to further reading. Unless otherwise noted, any information about iOS applies to iOS, iPadOS, tvOS, visionOS, and watchOS. Formats The code-signing identifiers discussed here use one of two formats: 10-character This is composed of 10 ASCII characters. For example, Team IDs use this format, as illustrated by the Team ID of one of Apple’s test teams: Z7P62XVNWC. Reverse-DNS This is composed of labels separated by a dot. For example, bundle IDs use this format, as illustrated by the bundle ID of the test app associated with this post: com.example.tn3NNNapp. The Domain Name System has strict rules about domain names, in terms of overall length, label length, text encoding, and case sensitivity. The reverse-DNS identifiers used by code signing may or may not have similar limits. When in doubt, consult the documentation for the specific identifier type. Reverse-DNS names are just a convenient way to format a string. You don’t have to control the corresponding DNS name. You can, for example, use com.<SomeCompany>.my-app as your bundle ID regardless of whether you control the <SomeCompany>.com domain name. To securely associate your app with a domain, use associated domains. For more on that, see Supporting associated domains. IMPORTANT Don’t use com.apple. in your reverse-DNS identifiers. That can yield unexpected results. Identifiers The following table summarises the identifiers covered below: Name | Format | Example | Notes ---- | ------ | ------- | ----- Team ID | 10-character | `Z7P62XVNWC` | Identifies a developer team User ID | 10-character | `UT376R4K29` | Identifies a developer Team Member ID | 10-character | `EW7W773AA7` | Identifies a developer in a team Bundle ID | reverse-DNS | `com.example.tn3NNNapp` | Identifies an app App ID prefix | 10-character | `Z7P62XVNWC` | Part of an App ID | | `VYRRC68ZE6` | App ID | mixed | `Z7P62XVNWC.com.example.tn3NNNNapp` | Connects an app and its provisioning profile | | `VYRRC68ZE6.com.example.tn3NNNNappB` | Code-signing identifier | reverse-DNS | `com.example.tn3NNNapp` | Identifies code to macOS | | `tn3NNNtool` | App group ID | reverse DNS | `group.tn3NNNapp.shared` | Identifies an app group | reverse DNS | `Z7P62XVNWC.tn3NNNapp.shared` | Identifies an macOS-style app group As you can see, there’s no clear way to distinguish a Team ID, User ID, Team Member ID, and an App ID prefix. You have to determine that based on the context. In contrast, you choose your own bundle ID and app group ID values, so choose values that make it easier to keep things straight. Team ID When you set up a team on the Developer website, it generates a unique Team ID for that team. This uses the 10-character format. For example, Z7P62XVNWC is the Team ID for an Apple test team. When the Developer website issues a certificate to a team, or a user within a team, it sets the Subject Name > Organisational Unit field to the Team ID. When the Developer website issues a certificate to a team, as opposed to a user in that team, it embeds the Team ID in the Subject > Common Name field. For example, a Developer ID Application certificate for the Team ID Z7P62XVNWC has the name Developer ID Application: <TeamName> (Z7P62XVNWC). ### User ID When you first sign in to the Developer website, it generates a unique User ID for your Apple Account. This User ID uses the 10-character format. For example, UT376R4K29 is the User ID for an Apple test user. When the Developer website issues a certificate to a user, it sets the Subject Name > User ID field to that user’s User ID. It uses the same value for that user in all teams. Team Member ID When you join a team on the Developer website, it generates a unique Team Member ID to track your association with that team. This uses the 10-character format. For example, EW7W773AA7 is the Team Member ID for User ID UT376R4K29 in Team ID Z7P62XVNWC. When the Developer website issues a certificate to a user on a team, it embeds the Team Member ID in the Subject > Common Name field. For example, an Apple Development certificate for User ID UT376R4K29 on Team ID Z7P62XVNWC has the name Apple Development: <UserName> (EW7W773AA7). IMPORTANT This naming system is a common source of confusion. Developers see this ID and wonder why it doesn’t match their Team ID. The advantage of this naming scheme is that each certificate gets a unique name even if the team has multiple members with the same name. The John Smiths of this world appreciate this very much. Bundle ID A bundle ID is a reverse-DNS identifier that identifies a single app throughout Apple’s ecosystem. For example, the test app associated with this post has a bundle ID of com.example.tn3NNNapp. If two apps have the same bundle ID, they are considered to be the same app. Bundle IDs have strict limits on their format. For the details, see CFBundleIdentifier. If your macOS code consumes bundle IDs — for example, you’re creating a security product that checks the identity of code — be warned that not all bundle IDs conform to the documented format. And non-bundled code, like a command-line tool or dynamic library, typically doesn’t have a bundle ID. Moreover, malicious code might use arbitrary bytes as the bundle ID, bytes that don’t parse as either ASCII or UTF-8. WARNING On macOS, don’t assume that a bundle ID follows the documented format, is UTF-8, or is even text at all. Do not assume that a bundle ID that starts with com.apple. represents Apple code. A better way to identify code on macOS is with its designated requirement, as explained in TN3127 Inside Code Signing: Requirements. On iOS this isn’t a problem because the Developer website checks the bundle ID format when you register your App ID. App ID prefix An App ID prefix forms part of an App ID (see below). It’s a 10-character identifier that’s either: The Team ID of the app’s team A unique App ID prefix Note Historically a unique App ID prefix was called a Bundle Seed ID. A unique App ID prefix is a 10-character identifier generated by Apple and allocated to your team, different from your Team ID. For example, Team ID Z7P62XVNWC has been allocated the unique App ID prefix of VYRRC68ZE6. Unique App ID prefixes are effectively deprecated: You can’t create a new App ID prefix. So, unless your team is very old, you don’t have to worry about unique App ID prefixes at all. If a unique App ID prefix is available to your team, it’s possible to create a new App ID with that prefix. But doing so prevents that app from sharing state with other apps from your team. Unique app ID prefixes are not supported on macOS. If your app uses a unique App ID prefix, you can request that it be migrated to use your Team ID by contacting Apple > Developer > Contact Us. If you app has embedded app extensions that also use your unique App ID prefix, include all those App IDs in your migration request. WARNING Before migrating from a unique App ID prefix, read App ID Prefix Change and Keychain Access. App ID An App ID ties your app to its provisioning profile. Specifically: You allocate an App ID on the Developer website. You sign your app with an entitlement that claims your App ID. When you launch the app, the system looks for a profile that authorises that claim. App IDs are critical on iOS. On macOS, App IDs are only necessary when your app claims a restricted entitlement. See TN3125 Inside Code Signing: Provisioning Profiles for more about this. App IDs have the format <Prefix>.<BundleOrWildcard>, where: <Prefix> is the App ID prefix, discussed above. <BundleOrWildcard> is either a bundle ID, for an explicit App ID, or a wildcard, for a wildcard App ID. The wildcard follows bundle ID conventions except that it must end with a star (*). For example: Z7P62XVNWC.com.example.tn3NNNNapp is an explicit App ID for Team ID Z7P62XVNWC. Z7P62XVNWC.com.example.* is a wildcard App ID for Team ID Z7P62XVNWC. VYRRC68ZE6.com.example.tn3NNNNappB is an explicit App ID with the unique App ID prefix of VYRRC68ZE6. Provisioning profiles created for an explicit App ID authorise the claim of just that App ID. Provisioning profiles created for a wildcard App ID authorise the claim of any App IDs whose bundle ID matches the wildcard, where the star (*) matches zero or more arbitrary characters. Wildcard App IDs are helpful for quick tests. Most production apps claim an explicit App ID, because various features rely on that. For example, in-app purchase requires an explicit App ID. Code-signing identifier A code-signing identifier is a string chosen by the code’s signer to uniquely identify their code. IMPORTANT Don’t confuse this with a code-signing identity, which is a digital identity used for code signing. For more about code-signing identities, see TN3161 Inside Code Signing: Certificates. Code-signing identifiers exist on iOS but they don’t do anything useful. On iOS, all third-party code must be bundled, and the system ensures that the code’s code-signing identifier matches its bundle ID. On macOS, code-signing identifiers play an important role in code-signing requirements. For more on that topic, see TN3127 Inside Code Signing: Requirements. When signing code, see Creating distribution-signed code for macOS for advice on how to select a code-signing identifier. If your macOS code consumes code-signing identifiers — for example, you’re creating a security product that checks the identity of code — be warned that these identifiers look like bundle IDs but they are not the same as bundle IDs. While bundled code typically uses the bundled ID as the code-signing identifier, macOS doesn’t enforce that convention. And non-bundled code, like a command-line tool or dynamic library, often uses the file name as the code-signing identifier. Moreover, malicious code might use arbitrary bytes as the code-signing identifier, bytes that don’t parse as either ASCII or UTF-8. WARNING On macOS, don’t assume that a code-signing identifier is a well-formed bundle ID, UTF-8, or even text at all. Don’t assume that a code-signing identifier that starts with com.apple. represents Apple code. A better way to identify code on macOS is with its designated requirement, as explained in TN3127 Inside Code Signing: Requirements. App Group ID An app group ID identifies an app group, that is, a mechanism to share state between multiple apps from the same team. For more about app groups, see App Groups Entitlement and App Groups: macOS vs iOS: Working Towards Harmony. App group IDs use two different forms of reverse-DNS identifiers: iOS-style This has the format group.<GroupName>, for example, group.tn3NNNapp.shared. macOS-style This has the format <TeamID>.<GroupName>, for example, Z7P62XVNWC.tn3NNNapp.shared. The first form originated on iOS but is now supported on macOS as well. The second form is only supported on macOS. iOS-style app group IDs must be registered with the Developer website. That ensures that the ID is unique and that the <GroupName> follows bundle ID rules. macOS-style app group IDs are less constrained. When choosing such a macOS-style app group ID, follow bundle ID rules for the group name. If your macOS code consumes app group IDs, be warned that not all macOS-style app group IDs follow bundle ID format. Indeed, malicious code might use arbitrary bytes as the app group ID, bytes that don’t parse as either ASCII or UTF-8. WARNING Don’t assume that a macOS-style app group ID follows bundle ID rules, is UTF-8, or is even text at all. Don’t assume that a macOS-style app group ID where the group name starts with com.apple. represents Apple in any way. Some developers use app group IDs of the form <TeamID>.group.<GroupName>. There’s nothing special about this format. It’s just a macOS-style app group ID where the first label in the group name just happens to be group Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS. If you’re writing new code that uses app groups, use an iOS-style app group ID. This allows sharing between different product types, for example, between a native macOS app and an iOS app running on the Mac. Revision History 2026-01-06 First posted.

Hi, We're having problems starting an Ad Hoc ipa on an iPad with iOS 12.7.7 and 12.7.8. The iPad's UUID has been added to the provisioning profile. The iPad that we are trying to start the app on is online, so Apple's certificate validation server should be reachable. We don't have any problems with iOS versions above iOS 12. The .ipa was built using the latest version of Xcode (26.2, build 17C52). Here is the anonymised and reduced console log (only the app launch / bootstrap part): default 07:29:35.683108+0100 SpringBoard Icon touch began: <private> default 07:29:35.752640+0100 SpringBoard Icon tapped: <private> default 07:29:35.768538+0100 trustd cert[0]: SubjectCommonName =(leaf)[]> 0 default 07:29:35.791500+0100 SpringBoard Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName] default 07:29:35.793654+0100 trustd cert[0]: IssuerCommonName =(path)[]> 0 default 07:29:36.043497+0100 assertiond Submitting new job for "<APP_BUNDLE_ID>" on behalf of SpringBoard (pid: 48) default 07:29:36.044393+0100 SpringBoard Bootstrapping <APP_BUNDLE_ID> with intent foreground-interactive error 07:29:36.045124+0100 SpringBoard [<APP_BUNDLE_ID>] Bootstrap failed with error: domain: BKSProcessErrorDomain, code: 1 (bootstrap-failed), reason: "Failed to start job" error 07:29:36.045214+0100 SpringBoard Bootstrapping failed for <APP_BUNDLE_ID> (pid: -1): Error Domain=BKSProcessErrorDomain Code=1 "Unable to bootstrap process with bundleID <APP_BUNDLE_ID>" NSLocalizedFailureReason=Failed to start job NSUnderlyingError=NSPOSIXErrorDomain Code=3 "No such process" BKLaunchdOperation=launch_get_running_pid_4SB BKLaunchdJobLabel=<LAUNCHD_JOB_LABEL> BKSProcessJobLabel=<LAUNCHD_JOB_LABEL> default 07:29:36.046078+0100 assertiond Submitted job with label: <LAUNCHD_JOB_LABEL> default 07:29:36.046442+0100 assertiond Unable to get pid for '<LAUNCHD_JOB_LABEL>': No such process (3) error 07:29:36.046542+0100 assertiond Failed to start job: NSPOSIXErrorDomain Code=3 "No such process" default 07:29:36.046607+0100 assertiond Deleted job with label: <LAUNCHD_JOB_LABEL> default 07:29:36.081068+0100 SpringBoard Application process state changed for <APP_BUNDLE_ID>: pid: -1; taskState: Not Running

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

App translocation, officially known as Gatekeeper path randomisation, comes up from time-to-time. The best resource to explain it, WWDC 2016 Session 706 What’s New in Security, is no longer available from Apple so I thought I’d post some notes here (r. 105455698 ). Questions or comments? Start a new thread here on DevForums, applying the Gatekeeper tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App Translocation Notes Gatekeeper path randomisation, more commonly known as app translocation, is a security feature on macOS 10.12 and later. When you run a newly downloaded app, the system executes the app from a randomised path. This prevents someone from taking an app that loads code from an app-relative path and repackaging it to load malicious code. IMPORTANT The best way to prevent your app from being tricked into loading malicious code is to enable library validation. You get this by default once you enable the hardened runtime. Do not disable library validation unless your app needs to load in-process plug-ins from other third-party developers. If you have an in-process plug-in model, consider migrating to ExtensionKit. The exact circumstances where the system translocates an app is not documented and has changed over time. It’s best to structure your app so that it works regardless of whether it’s translocated or not. App Translocation Compatibility Most apps run just fine when translocated. However, you can run into problems if you load resources relative to your app bundle. For example, consider a structure like this: MyApp.app Templates/ letter.myapp envelope.myapp birthday card.myapp Such an app might try to find the Templates directory by: Getting the path to the main bundle Navigating from that using a relative path This won’t work if the app is translocated. The best way to avoid such problems is to embed these resources inside your app (following the rules in Placing Content in a Bundle, of course). If you need to make them easily accessible to the user, add your own UI for that. For a great example of this, run Pages and choose File > New. App Translocation Limits There is no supported way to detect if your app is being run translocated. If you search the ’net you’ll find lots of snippets that do this, but they all rely on implementation details that could change. There is no supported way to determine the original (untranslocated) path of your app. Again, you’ll find lots of unsupported techniques for this out there on the ’net. Use them at your peril! If you find yourself using these unsupported techniques, it’s time to sit down and rethink your options. Your best option here is to make your app work properly when translocated, as illustrated by the example in the previous section. App Translocation in Action The following steps explain how to trigger app translocation on macOS 13.0. Keep in mind that the specifics of app translocation are not documented and have changed over time, so you might see different behaviour on older or new systems: To see app translocation in action: Use Safari to download an app that’s packaged as a zip archive. My go-to choice for such tests is NetNewsWire, but any app will work. Safari downloads the zip archive to the Downloads folder and then unpacks it (assuming your haven’t tweaked your preferences). In Finder, navigate to the Downloads folder and launch the app. When Gatekeeper presents its alert, approve the launch. In Terminal, look at the path the app was launched from: % ps xw | grep NetNewsWire … /private/var/folders/wk/bqx_nk71457_g9yry9c_2ww80000gp/T/AppTranslocation/C863FADC-A711-49DD-B4D0-6BE679EE225D/d/NetNewsWire.app/Contents/MacOS/NetNewsWire Note how the path isn’t ~/Downloads but something random. That’s why the official name for this feature is Gatekeeper path randomisation. Quit the app. Use Finder to relaunch it. Repeat step 5: % ps xw | grep NetNewsWire … /private/var/folders/wk/bqx_nk71457_g9yry9c_2ww80000gp/T/AppTranslocation/C863FADC-A711-49DD-B4D0-6BE679EE225D/d/NetNewsWire.app/Contents/MacOS/NetNewsWire The path is still randomised. Quit the app again. Use the Finder to move it to the desktop. And relaunch it. And repeat step 5 again: % ps xw | grep NetNewsWire … /Users/quinn/Desktop/NetNewsWire.app/Contents/MacOS/NetNewsWire The act of moving the app has cleared the state that triggered app translocation.

I'm currently befuddled by the entire signing and certificate process. I don't understand what I need, what the team admin needs to do, or how to go about doing it so that I can build the project. We've managed to have this working in the past but I guess the system has changed somewhat. Here's what we have going: A Unity project which hasn't changed from a few years ago. I build the project in unity, open the Xcode project and this: There's an issue with the Signing and Capabilities. If I choose automatic setup it shows an error saying that it requires a development team. I had the account admin add my Apple ID to the team so I'm not sure why that's an issue still. Do I need to pay the 99$ to be able to building Xcode? If I try to do it manually I select the provisioning profile that the account admin sent me and it auto selects the team associated with the provisioning profile I guess but then there's no singing certificate. The error says: There is no signing certificate "iOS Development" found. No "iOS Development" signing certificate matching team ID "V7D5YBZRMV" with a private key was found. So, if someone could explain to me like I'm 5 the entire signing and certificate process is and let me know what we're doing wrong with the team/provisioning profile/certificate setup I would be very much appreciative.

I am using matlab to create an application (.app) using matlab application compiler. Along with that, I use matlab to create an installer for that. Unfortunately, the installer is in (.app) format. So do some custom things to install the dependencies and copying my application to Applications folder. I am able to sign the original application with Developer ID application certificate. But I am not able to sign the installer in .app format with Developer ID installer certificate. Is there any flag in any signing executable that allows me to use Developer ID installer certificate to sign .app file instead of typical (.pkg/.dmg)? Any help would be much appreciated.

Hi, I have a project that integrates the Firebase SDK via SPM as a dependency of an internal Swift Package: My app ⟶ My Library ⟶ Firebase SDK The project builds successfully and can be archived locally ✅. The uploaded .ipa is valid and gets published 🚀. However, we are now trying to automate the release process using Xcode Cloud, but the iOS Archive action is failing ❌ on Xcode Cloud. The logs show the following error ⬇️: error: exportArchive codesign command failed (/Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: replacing existing signature /Volumes/workspace/tmp/XcodeDistPipeline/XcodeDistPipeline.~~~oomCvM/Root/Payload/base-ios.app/Frameworks/FirebaseAnalytics.framework: invalid or corrupted code requirement(s) Requirement syntax error(s): line 1:178: unexpected token: <COMPANY_NAME> ) ** EXPORT FAILED ** I have been researching this issue for a while and have tried several solutions to fix it, but with no luck. Even though the error points to a specific library—the Firebase SDK—I don’t believe Firebase is the root cause. There were related issues in the past, but those were already fixed by the Firebase team, and as I mentioned, the project archives correctly when built locally. On the other hand, the error states: line 1:178: unexpected token: <COMPANY_ACRONYM> This makes me wonder if there’s an issue parsing our Team Name during the re-signing process, as it contains special characters ": "name": "Apple Distribution: Company Full Name "COMPANY_ACRONYM""

I have a .NET 6 application that runs in the background. The installer is a .pkg file built using a third-party tool called "Packages". All .dylib and executable files are codesigned before packaging. The resulting .pkg file is notarized. The app uses these entitlements: com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.allow-dyld-environment-variables com.apple.security.cs.disable-library-validation The app is built on a macbook Air 2015 running macOS 12.6 and it works without issues on that machine. On a macbook Pro M3 running macOS 14.6.1 the app fails to run even though the installation itself is successful. The only logs that I was able to find are related to syspolicyd (4 warnings): Unable to apply protection to app: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null)) Failed to register app bundle for protection: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null)) scan failed, finishing evaluation : PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null)) Terminating process due to Gatekeeper rejection: 95158, Unfortunately, verification commands such as sudo codesign --verify --deep --strict -vvv MyApplication.App spctl -a -vvv -t install MyApplicationInstaller.pkg do not indicate any issues. Are there any additional steps that need to be performed in order for my app to work properly on newer machines?

Hello! I've just recently discovered LaunchCodeRequirement API and I'm exploring how it works compared to existing alternatives available for macOS versions below 14.4. Some questions I have with regards to safety of older and newer APIs examining the given example: func runProcess(executableURL: URL) throws { let process = Process() process.executableURL = executableURL if #available(macOS 14.4, *) { process.launchRequirement = try LaunchCodeRequirement.allOf { ValidationCategory(.developerID) SigningIdentifier("some-signing-identifier") TeamIdentifier("some-team-identifier") } } else { try secStaticCodeCheckValidity(executableURL) // Point #1 } do { try process.run() // Point #2 if #available(macOS 14.4, *) { // process.launchRequirement should take care of the process // and kill it if launchRequirement constraint is not satisfied } else { try secCodeCheckValidity(process.processIdentifier) // Point #3 } process.waitUntilExit() } catch { process.terminate() throw error } // Point #4 guard process.terminationReason == .exit else { throw SomeError() } } let requirement = """ anchor apple generic and identifier = "some-signing-identifier" and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf [subject.OU] = "some-team-identifier" """ func secStaticCodeCheckValidity(_ executableURL: URL) throws { // Init SecStaticCode from `executableURL` // Init SecRequirement from `requirement` let flags = SecCSFlags(rawValue: kSecCSBasicValidateOnly) guard SecStaticCodeCheckValidityWithErrors(code, flags, secRequirement, nil) == errSecSuccess else { throw CodeSignError() } } func secCodeCheckValidity(_ processIdentifier: Int32) { // Init SecCode from `processIdentifier` // Init SecRequirement from `requirement` guard SecCodeCheckValidityWithErrors(code, [], secRequirement, nil) == errSecSuccess else { throw CodeSignError() } } Before macOS 14.4+ flow There's still a small chance that between checking executable binary codesign requirement (Point #1) and launched process' one (Point #3) the binary could be replaced with something malicious and even get some CPU between Points #2 and #3 so technically it can't be 100% safe. Is that a correct statement? Any advices on making it safer? macOS 14.4+ flow Now let's see how launchRequirement is better. I guess initialized launchRequirement gets evaluated on running the process (Point #2). What does it exactly check? Executable at URL before launching the process (as OnDiskConstraint) or launched process (as ProcessConstraint)? Is there any chance the process gets some CPU before it's killed in case of failed codesign check? Any way to distinguish between codesign requirement termination and other reasons at point #4? It returns SIGKILL (9) as terminationStatus but it's not precise enough to be sure it was killed due to failed requirement check. I guess newer SecStaticCodeCheckValidityWithOnDiskRequirement & SecCodeCheckValidityWithProcessRequirement are the same as SecStaticCodeCheckValidityWithErrors & SecCodeCheckValidityWithErrors but a little simpler and can't be used as a 'more secure' way of validating codesign requirement. Thanks, Pavel

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

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

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

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

I am trying to get a PKG installer through the Apple codesign and notarytool process. When I submit the PKG installer I get a status message of "Invalid" and when I review the log file it has 2 errors. For "status summary" it says: "Archive contains critical validation errors", and for "message" it says" "The binary is not signed". The installer contains a flat file that is installed in the "Users/Shared" folder via the PKG installer. Here are the steps I've taken to get the installer through the codesign and notarytool process. codesign the file that's placed in the "Users/Shared" folder: codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/"flat file" which I get a message saying "signed generic". Create the PKG installer with the signed "flat file". Sign the PKG installer containing the signed "flat file": codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/"flat file" which I get a message saying "signed generic". Submit the PKG file with notarytool: xcrun notarytool submit /Users/.../Documents/folder/"flat file" --verbose --apple-id username --password password --team-id ID# --progress It completes and provides the submission ID. I check the status and get the error message that it's invalid. When I check the full details via the log I get the error messages mentioned above. What am I missing or failing to do?

Hello, I have this simulator made in Unity that I want to distribute as Standalone. It consists of launcher which, when users download it, downloads the game. I've built the launcher, got Developer ID Application certificate, added entitlements from: https://docs.unity3d.com/Manual/macoscodesigning.html#signing-identity I've signed the .app of the launcher and 2 dlls chatgpt recommended to sign, zipped it, notarized .zip successfully, stapled to .app and put it on Google Drive to test. I got my other MacBook Pro, downloaded the zip, tried to open it. It did open, but there is a black loading screen saying "0% progress, 0B/0B" indicating that it isn't downloading anything - no network calling. When checked using command xattr -l path/to/file.app I get the following output: com.apple.macl: @?????I???|???? com.apple.quarantine: 0083;67bf1a22;Safari;69764595-CA94-44D2-B679-A69DC4669382 There are some specifics I think are also important to mention. I tried to code-sign it, notarize it and staple it using only Terminal and I'd like to keep it that way because I am very unfamiliar with Mac so I've avoided using Xcode as much as possible I really want to avoid putting the simulator up on the App Store, so I must have Standalone solution and Standalone solution only I believe that there might be problem with needing right entitlements, but I don't know how to check which one's are needed for users to avoid using "xattr" command in terminal to allow the launcher to run because of GateKeeper I've been banging my head against the wall with this problem for over a month and I don't see the light at the end of the tunnel.

I am developing a macOS app that requires the Associated Domains entitlement. The app will be distributed as a custom app. The app needs to be signed using Team A’s Developer ID Application certificate and packaged under Team A’s Team ID. Team A has a secure signing and packaging setup, but they do not provide access to their Developer ID Application Identity (cert) or their provisioning profile. I am part of Team B and have access to Team B’s Developer ID Application identity and provisioning profiles. I am thinking of doing the following: I create a provisioning profile under Team B that authorizes the Associated Domains entitlement. I sign the app using Team B’s Developer ID Application identity, ensuring the required entitlements are included. Then, I re-sign the app using Team A’s Developer ID Application identity, since Team A has also set up the same bundle ID with the Associated Domains entitlement and corresponding provisioning profile. Questions: Is this approach correct & does it have any drawback? Will the double signing process work without issues, given that Team A has the required provisioning profile for the same bundle ID? Are there better ways to handle this situation where signing must be done under Team A but access is limited? Thanks!

Hello, our app is non-sandboxed app, but we do want to support widget extension and safari extension. Those extensions require sandboxing. Is it possible to do this without sandboxing our app? Thank you!

I’ve been having problems with MacOS builds. I’m making a release Appstore build and uploading it to Testflight. However when running it instantly crashes, and report screen shows the following: Current flow: I sign all files in PlugIns/ (we have a number of .bundle), and I’ve tried combinations of signing with/without --entitlements, as well as with/without --deep. After this I sign Frameworks/GameAssembly.dylib and Frameworks/UnityPlayer.dylib. Again, I’ve tried combinations of with/without --entitlements and --deep, also not signing them at all. After signing PlugIns and frameworks, I sign the .app, also tried this with/without --deep (always with --entitlements). Finally I make a .pkg and upload to Testflight. It’s not the game, as I can make an enterprise version that runs fine. We have some restricted entitlements, such as Apple Arcade. Building from an M1 mac, and architecture is Universal (Intel + ARM). Unity documentation says to use --deep, but Apple documentation highly recommend against it. So basically, my question is, how and in what order should I sign the files? Much obliged!

Hello. I have an enterprise application that requires specific privileges to execute correctly on MacOS. One of these privileges is SystemPolicyAllFiles (aka Full Disk Access), as we use the endpoint security framework. When we distribute our application, we generate: A signed, notarized pkg consisting of our application binaries. An MDM-compatible .mobileconfig, which contains the SystemPolicyAllFiles setting. We expect our users to install both to get the application to function correctly. However, we have three environments we deploy to: Internal (local development on a developer's workstation), "development" (where features are integrated prior to release) and "production" (what our customers get). For local, our developers create an Apple account and use a Mac Development certificate for signing. They also generate their own embedded.provisionprofile and drop that into their local installation config. For development/production, we use our Developer ID certificate and Developer Installer certificate, with an endpoint security embedded.provisionprofile bound to those. However, when we generate a .mobileconfig, we need to include a CodeRequirement (CR) for SystemPolicyAllFiles. I've been retrieving this using codesign -dr - ... (i.e., the designated requirement aka DR). However, the designated requirement is very specific to the certificate, which is problematic specifically for local development, where each developer has their own Mac Development certificate. Here's what the relevant section of our generated mobileconfig looks like right now: &lt;dict&gt; &lt;key&gt;SystemPolicyAllFiles&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;Allowed&lt;/key&gt; &lt;true/&gt; &lt;key&gt;CodeRequirement&lt;/key&gt; &lt;string&gt;identifier "com.example.app and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = &lt;TEAMID&gt;&lt;/string&gt; &lt;key&gt;Comment&lt;/key&gt; &lt;string&gt;app&lt;/string&gt; &lt;key&gt;Identifier&lt;/key&gt; &lt;string&gt;com.exmple.app&lt;/string&gt; &lt;key&gt;IdentifierType&lt;/key&gt; &lt;string&gt;bundleID&lt;/string&gt; &lt;key&gt;StaticCode&lt;/key&gt; &lt;false/&gt; &lt;/dict&gt; &lt;/array&gt; &lt;/dict&gt; That's in a format that works for our Developer ID cert, but the DR for the Mac Development certificate looks like: identifier "com.example.app" and anchor apple generic and certificate leaf[subject.CN] = "Mac Developer: John Doe (12ABC34567)" and certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */ Question: Is it possible to relax the code requirement so that it is generic enough to cover all Mac Developer certificates and Developer ID certificates we use? If not, is there a way to have one code requirement for our Mac Developer certificates and a separate CR for our Developer ID certificate? My use case is deploying a static "local" .mobileconfig using our internal company MDM (Apple Business Essentials) to all developer workstations so we don't have to have each developer manually configure their system for the software to run. Thanks! D

There is something wrong with my keychain. Can someone point me in the right direction? codesign --force --sign "Developer ID Application: Denis Putnam (2368694WQF)" --options runtime "/Users/denisputnam/git/expense_tracker/dist/ExpenseTracker.app" /Users/denisputnam/git/expense_tracker/dist/ExpenseTracker.app: replacing existing signature Warning: unable to build chain to self-signed root for signer "Developer ID Application: Denis Putnam (2368694WQF)" /Users/denisputnam/git/expense_tracker/dist/ExpenseTracker.app: errSecInternalComponent Deniss-MacBook-Pro:expense_tracker denisputnam$ security find-certificate -c "Developer ID Certification Authority" -p /Library/Keychains/System.keychain | openssl x509 -noout -dates notBefore=Sep 22 18:55:10 2021 GMT notAfter=Sep 17 00:00:00 2031 GMT Deniss-MacBook-Pro:expense_tracker denisputnam$