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"

Hi! I've been scratching my brain for a few days now to no avail. I have a Perl project that I need to embed within my app. Perl includes a pp command (https://metacpan.org/pod/pp) which takes the runtime binary and then slaps the Perl code at the end of the binary itself which in brings some woes in a sense that the binary then needs to be "fixed" (https://github.com/rschupp/PAR-Packer/tree/master/contrib/pp_osx_codesign_fix) by removing the linker-provided signature and fixing LINKEDIT and LC_SYMTAB header sections of the binary. Nevertheless, I've successfully gotten the binary built, fixed up and codesigned it via codesign -s '$CS' mytool (where $CS is the codesigning identity). I can verify the signature as valid using codesign -v --display mytool: Identifier=mytool Format=Mach-O thin (arm64) CodeDirectory v=20400 size=24396 flags=0x0(none) hashes=757+2 location=embedded Signature size=4820 Signed Time=5. 1. 2026 at 8:54:53 PM Info.plist=not bound TeamIdentifier=XXXXXXX Sealed Resources=none Internal requirements count=1 size=188 It runs without any issues in Terminal, which is great. As I need to incorporate this binary in my app which is sandboxed, given my experience with other binaries that I'm including in the app, I need to codesign the binary with entitlements com.apple.security.app-sandbox and com.apple.security.inherit. So, I run: codesign -s '$CS' --force --entitlements ./MyTool.entitlements --identifier com.charliemonroe.mytool mytool ... where the entitlements file contains only the two entitlements mentioned above. Now I add the binary to the Xcode project, add it to the copy resources phase and I can confirm that it's within the bundle and that it's codesigned: codesign -vvvv --display MyApp.app/Contents/Resources/mytool Identifier=com.xxx.xxx.xxx Format=Mach-O thin (arm64) CodeDirectory v=20500 size=24590 flags=0x10000(runtime) hashes=757+7 location=embedded VersionPlatform=1 VersionMin=1703936 VersionSDK=1704448 Hash type=sha256 size=32 CandidateCDHash sha256=0a9f93af81e8e5cb286c3df6e638b2f78ab83a9e CandidateCDHashFull sha256=0a9f93af81e8e5cb286c3df6e638b2f78ab83a9edf463ce45d1cd3f89a6a4a00 Hash choices=sha256 CMSDigest=0a9f93af81e8e5cb286c3df6e638b2f78ab83a9edf463ce45d1cd3f89a6a4a00 CMSDigestType=2 Executable Segment base=0 Executable Segment limit=32768 Executable Segment flags=0x1 Page size=16384 CDHash=0a9f93af81e8e5cb286c3df6e638b2f78ab83a9e Signature size=4800 Authority=Apple Development: XXXXXX (XXXXXX) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=9. 1. 2026 at 5:12:22 PM Info.plist=not bound TeamIdentifier=XXXXX Runtime Version=26.2.0 Sealed Resources=none Internal requirements count=1 size=196 codesign --display --entitlements :- MyApp.app/Contents/Resources/mytool <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.inherit</key><true/></dict></plist> All seems to be in order! But not to Gatekeeper... Attempting to run this using the following code: let process = Process() process.executableURL = Bundle.main.url(forResource: "mytool", withExtension: nil)! process.arguments = arguments try process.run() process.waitUntilExit() Results in failure: process.terminationStatus == 255 Console shows the following issues: default 17:12:40.686604+0100 secinitd mytool[88240]: root path for bundle "<private>" of main executable "<private>" default 17:12:40.691701+0100 secinitd mytool[88240]: AppSandbox request successful error 17:12:40.698116+0100 kernel exec of /Users/charliemonroe/Library/Containers/com.charliemonroe.MyApp/Data/tmp/par-636861726c69656d6f6e726f65/cache-9c78515c29320789b5a543075f2fa0f8072735ae/mytool denied since it was quarantined by MyApp and created without user consent, qtn-flags was 0x00000086 Quarantine, hum? So I ran: xattr -l MyApp.app/Contents/Resources/mytool None listed. It is a signed binary within a signed app. There are other binaries that are included within the app and run just fine exactly this way (most of them built externally using C/C++ and then codesigned exectly as per above), so I really don't think it's an issue with the app's sandbox setup... Is there anyone who would be able to help with this? Thank you in advance!

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.

Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that. There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test: – Installed through VPP on supervised devices running watchOS 26.1. – Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2. This strongly appears to be a VPP signing issue because we even did the following experiment: Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2. Verify that both apps launch successfully. Use an MDM command to install from VPP over the existing installations Verify that the watch app fails to launch (the iOS app is unaffected) My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.

Hello Apple Developer Forum Community, I’ve got a problem with the signing process of my AppClip Test App. Can someone help me? As I don’t know hot to get the certificate...

I am using a Sonoma VM (14.6) where i have installed xcode 16.2. When i try login into apple id into xcode, i am getting this error. I know i am entering the correct credentials. Not sure why this issue is. In other Sequioa and Tahoe VM , i was able to login.

I'm experiencing an issue when exporting an Enterprise distribution certificate where the certificate and private key won't export together - the private key keeps getting left out. I'm running macOS Tahoe. Has anyone encountered the same issue or know of a solution? Any help would be appreciated.

I have a free developer account, and I have been creating applications. When I tried to open one of them, it said that this app has been flagged as malware. It is not malware, so I don't know why it has been flagged as this. Not just this app, but suddenly a whole bunch of my apps have been flagged as malware as well! The app I have been developing is basically a windows Taskbar for my macbook air, and it has been working well until the latest update i made where it hides in full screen, suddenly it started taking up significant energy, so i reverted to an older version while i was fixing it. Then, when i try to open it another time, it starts to open, and it says "Malware Blocked and Moved to Bin" “Taskbar.app” was not opened because it contains malware. This action did not harm your Mac”. All versions of the taskbar now contain this message. I try opening some of my other apps, a shared storage client and a shared storage server (where i was testing with app groups), and they couldn't open either, the same malware message appeared. ProPermission couldn't open either (changes permissions on files for me so i don't have to use the terminal or finder). I can run these apps through the Xcode environment (attached process), but when I archieve it into an app bundle, the malware flag appears. Please note that I am certain that these apps do not contain malware, apparently XProtect has incorrectly flagged my apps as malware. Because I do not have the paid developer account, I cannot notarize my apps. I am using MacOS Tahoe 26.1 with Xcode 26.0, and I have tested it with a iMac Intel 2017 with MacOS Ventura.

Coming from Windows, I'm finding Mac app packaging farcically complicated, to the level of a Python sketch. I mastered Windows packaging, via Inno, in an hour or so, but it has taken me, on and off, the best part of a week to get to the point I am at with the Mac OS, and I'm nowhere near finished (rather, it hasn't finished with me). Every time I surmount one hurdle, another pops up, seemingly just for the jollies. I'm currently stuck at: 'Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired.' My account lists no agreements in this category. I understand the need for security, but not the labyrinthine nature of the process. An inner-party member in the former Soviet Union overheard a drunken Stalin say, “I trust no one; not even myself". Apple trusts no one, but has true contempt for developers. Is there a simple way to work through the packaging process? Let me rephrase that: please God, let there be a simpler way of working through the process! Regards, in extremis, Richard

The Developer App Certificate is not trusted.

Hey, Just recently I realized something I have been overlooking in my build pipelines. I thought that by adding the the "hardened runtime", I disable 3rd-party library injection (I do not have the disable-library-validation entitlement added). However, I was using some checks on my code and I noticed that the "library validation" code signature check fails on my applications (e.g. adding the .libraryValidation requirement via the LightweightCodeRequirements framework) - with codesign -dvvvv /path/to/app I can check it doesn't have the CS_REQUIRE_LV flag: [...] CodeDirectory v=20500 size=937 flags=0x10000(runtime) hashes=18+7 location=embedded [...] then I used in Xcode the "Other Code Signing Flags" setting and added the -o library option, which added the flag: [...] CodeDirectory v=20500 size=937 flags=0x12000(library-validation,runtime) hashes=18+7 location=embedded [...] Is this flag something I should be explicitly setting? Because I was under the impression enabling hardened runtime would be enough. Popular Developer ID distributed applications (e.g. Google Chrome, Parallels Desktop, Slack) all have this flag set.

I want to export Mac OS application out side App Store and I need to have Developer Id installer certificate to do the same. When I go to certificate section in developer portal - I only see option of Mac App Distribution Mac Installer Distribution Developer ID Application Does anyone know where I can check the Developer ID installer part. Developer ID application doesn't work for signing the app manually.

I tried building a macOS app with Electron, but I ran into problems during notarization. I used notarytool to upload my DMG and got status: Invalid. xcrun notarytool log output { "logFormatVersion": 1, "jobId": "680bf475-a5f4-4675-9083-aa755d492b18", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "BODYPARK-v3.6.0-mac.app.zip", "uploadDate": "2025-09-25T02:50:41.523Z", "sha256": "e61074b9bba6d03696f2d8b0b13870daafc283960e61ab5002d688e4e82ef6f6", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "BODYPARK-v3.6.0-mac.app.zip/BODYPARK-v3.6.0-mac.app/Contents/Resources/plugin/XMagic/mac/libpag.framework/libpag", "message": "The signature of the binary is invalid.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735", "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "BODYPARK-v3.6.0-mac.app.zip/BODYPARK-v3.6.0-mac.app/Contents/Resources/plugin/XMagic/mac/libpag.framework/libpag", "message": "The signature does not include a secure timestamp.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733", "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "BODYPARK-v3.6.0-mac.app.zip/BODYPARK-v3.6.0-mac.app/Contents/Resources/plugin/XMagic/mac/libpag.framework/libpag", "message": "The signature of the binary is invalid.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735", "architecture": "arm64" }, { "severity": "error", "code": null, "path": "BODYPARK-v3.6.0-mac.app.zip/BODYPARK-v3.6.0-mac.app/Contents/Resources/plugin/XMagic/mac/libpag.framework/libpag", "message": "The signature does not include a secure timestamp.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733", "architecture": "arm64" } ] } I checked the signature of my .app file: codesign -v -vvv --deep --strict /Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/MacOS/BODYPARK-v3.6.0-mac --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper (GPU).app --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper (GPU).app --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper (Plugin).app --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper (Plugin).app --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/TXFFmpeg.framework/Versions/Current/. --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/TXFFmpeg.framework/Versions/Current/. --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/. --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/Helpers/chrome_crashpad_handler --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/Helpers/chrome_crashpad_handler --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/. --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/TXSoundTouch.framework/Versions/Current/. --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/TXSoundTouch.framework/Versions/Current/. --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper.app --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper.app --prepared:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper (Renderer).app --validated:/Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/Frameworks/BODYPARK-v3.6.0-mac Helper (Renderer).app /Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/MacOS/BODYPARK-v3.6.0-mac: valid on disk /Users/zhangheng/Desktop/development/coach-app/dist_electron/mac-universal/BODYPARK-v3.6.0-mac.app/Contents/MacOS/BODYPARK-v3.6.0-mac: satisfies its Designated Requirement It looks like local signing succeeded, but notarization is failing. I’m a beginner with macOS signing/notarization. Could you please help me figure out what I’m doing wrong and how to fix this? I’d really appreciate any guidance.

I've recently upgraded to the RC candidates of macOS 26 and Xcode 26. The app I'm building has a helper tool using SMAppService. When I run the app and helper tool in macOS 15 or macOS 26, all works as expected. When it runs on macOS 13 or 14, which previously worked. The helper now crashes on launch with the following reason: Termination Reason: CODESIGNING 4 Launch Constraint Violation I found this developer session which seems to address this, but the plist I've added doesn't seem to satisfy the constraint. https://developer.apple.com/videos/play/wwdc2023/10266/ Here are the contents of my new plist: Are there any gotchas here that I might be missing? Thanks!

Hi, This is my first time developing for iPhone, and I believe I have encountered an unusual edge case related to user management. Background: I work at a very small company currently in the proof-of-concept stage of building an iOS app. We created an Apple account under the company name: Green Vibe, using our corporate email. Initially, I developed the app under the free account on my local iPhone, and everything worked smoothly. When NFC functionality became necessary, we upgraded to a paid Apple Developer account. At that point, I enrolled as a developer under my personal name (Or Itach) while logged in with the Green Vibe Apple account. I want to emphasize that only one Apple account was created — the Green Vibe account. The Issue: When attempting to add NFC, I was able to create the required certificate under the name Or Itach. However, when compiling the project, Xcode prompts me to enter the login password for the user Or Itach. This is problematic because there is no Apple ID associated with that name — only the Apple Developer enrollment under Green Vibe exists. Request: Could you please advise on the proper way to resolve this situation? Specifically: Should the developer enrollment be tied directly to the Green Vibe account rather than to an individual name? How can I correctly configure the account so that Xcode no longer requires a nonexistent Apple ID password? Thank you very much for your support and 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 am experiencing a persistent issue when trying to sign my application, PhotoKiosk.app, using codesign. The process consistently fails with the error errSecInternalComponent, and my troubleshooting indicates the problem is with how the system accesses or validates my certificate's trust chain, rather than the certificate itself. Error Details and Configuration: codesign command executed: codesign --force --verbose --options=runtime --entitlements /Users/sergiomordente/Documents/ProjetosPhotocolor/PhotoKiosk-4M/entitlements.plist --sign "Developer ID Application: Sérgio Mordente (G75SJ6S9NC)" /Users/sergiomordente/Documents/ProjetosPhotocolor/PhotoKiosk-4M/dist/PhotoKiosk.app Error message received: Warning: unable to build chain to self-signed root for signer "(null)" /Users/sergiomordente/Documents/ProjetosPhotocolor/PhotoKiosk-4M/dist/PhotoKiosk.app: errSecInternalComponent Diagnostic Tests and Verifications Performed: Code Signing Identity Validation: I ran the command security find-identity -v -p codesigning, which successfully confirmed the presence and validity of my certificate in the Keychain. The command output correctly lists my identity: D8FB11D4C14FEC9BF17E699E833B23980AF7E64F "Developer ID Application: Sérgio Mordente (G75SJ6S9NC)" This suggests that the certificate and its associated private key are present and functional for the system. Keychain Certificate Verification: The "Apple Root CA - G3 Root" certificate is present in the System Roots keychain. The "Apple Worldwide Developer Relations Certification Authority (G6)" certificate is present and shown as valid. The trust setting for my "Developer ID Application" certificate is set to "Use System Defaults". Attempted Certificate Export via security: To further diagnose the problem, I attempted to export the certificate using the security find-certificate command with the exact name of my identity. Command executed (using double quotes): security find-certificate -c -p "Developer ID Application: Sérgio Mordente (G75SJ6S9NC)" &gt; mycert.pem Error message: security: SecKeychainSearchCopyNext: The specified item could not be found in the keychain. The same error occurred when I tried with single quotes. This result is contradictory to the output of find-identity, which successfully located the certificate. This suggests an internal inconsistency in the Keychain database, where the certificate is recognized as a valid signing identity but cannot be located via a simple certificate search. Additional Troubleshooting Attempts: I have already recreated the "Developer ID Application" certificate 4 times (I am at the limit of 5), and the issue persists with all of them. The application has been rebuilt, and the codesign command was run on a clean binary. Conclusion: The problem appears to be an internal macOS failure to build the trust chain for the certificate, as indicated by the errSecInternalComponent error. Although the certificate is present and recognized as a valid signing identity by find-identity, the codesign tool cannot complete the signature. The failure to find the certificate with find-certificate further supports the suspicion of an inconsistency within the keychain system that goes beyond a simple certificate configuration issue. I would appreciate any guidance on how to resolve this, especially given that I am at my developer certificate limit and cannot simply generate a new one.

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 was working in Xcode with a free personal Team ID. I upgraded to the Dev Program and now have a paid Team ID. I used the same Apple ID for both. The paid Team ID shows up in developer.apple.com as associated with my Apple ID. However, Xcode is not using the paid Team ID in signing, it's stuck on my old personal Team ID. In addition, I'm getting provisioning errors (0xe8008015) when we try to run our app on an iPhone. Anyone have any thoughts? I've scoured the forums and ChatGPT'd, Cursor'd, etc...all of the suggested fixes do not work. This almost seems like Apple needs to make my Apple ID associated with the paid Team ID or something, to start. Thanks all.

Your development team has reached the maximum number of registered iPhone devices. I am use the free provisioning file. So how can I delete old device and use my new iPhone to develop my app. only way is use a paid account? or register a new Apple ID?

Hello Apple Developer Support Community, I am encountering a persistent issue while trying to code sign my macOS application (PromptVault.app) using a valid Developer ID Application certificate. The signing process fails with the following warning and error for every native .so file inside the app bundle: `Warning: unable to build chain to self-signed root for signer "(null)" <file-path>: errSecInternalComponent` What I have tried so far: Verified that my Developer ID Application certificate and the associated private key exist correctly in the login keychain. Confirmed that the intermediate certificate "Apple Worldwide Developer Relations - G6" is installed and valid in the System keychain. Added Terminal to Full Disk Access in Security & Privacy to ensure signing tools have required permissions. Executed security set-key-partition-list to explicitly allow code signing tools to access the private key. Reinstalled both developer and Apple intermediate certificates. Used codesign to individually sign .so files and then sign the entire bundle. Ensured macOS and Xcode Command Line Tools are up to date. Created a clean Python virtual environment and rebuilt all dependencies. Tested code signing in multiple ways and with verbose logging. Current status: Despite all these efforts, the same warning and error persist during the signing process of every .so file. This prevents successful code signing and notarization, blocking distribution. Request for assistance: Could anyone confirm if my certificate and keychain setup sounds correct? Are there known issues or extra steps necessary to properly build the trust chain for Developer ID certificates on macOS 15.6.1 (Sequoia)? Any suggestions for resolving the errSecInternalComponent during signing native libraries? Guidance on ensuring the entire certificates chain is trusted and usable by codesign tools? I can provide debug logs, screenshots of my keychain and security settings, or any other diagnostic information if needed. Thanks in advance for your help!