I’m building an Electron app for macOS that I plan to distribute to users in a .dmg outside the Mac App Store. I have a Developer ID Application certificate (from Apple’s Developer Portal) and a private key, and I can see “Developer ID Certification Authority” in my System Roots keychain.
• My Developer ID Application certificate is in the login keychain, and it shows up under “My Certificates” with its private key.
• On Keychain, certificate shows red message "not trusted", but when I evaluate and check it specifically for codesigning it shows a green checkmark and success
• Developer ID Certification Authority is in System Roots.
• security find-identity -p codesigning – shows my certificate, but shows 0 valid identities
• Updated operating system and deleted and recreated a new certificate, still get the same issue
Demystify code signing and its importance in app development. Get help troubleshooting code signing issues and ensure your app is properly signed for distribution.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I've noticed that NSTaks has this property as of macOS 14.4
@property (nullable, copy) NSData *launchRequirementData API_AVAILABLE(macos(14.4)) API_UNAVAILABLE(ios, watchos, tvos, visionos);
It has no documentation whatsoever. Even google search has no clue. Does this have anything to do with code signature requirements validation? Any explanations and examples would be appreciated!
Hi Developers,
I'm encountering persistent validation errors in Xcode 16.3 (16E140) on macOS 15.4.1 (24E263) with M1 when archiving and distributing a macOS app (Developer ID signing + notarization).
App Structure:
A native Swift/Obj-C wrapper app that launches a nested .app inside its Resources.
The nested app is built with PyInstaller and includes:
A Python core
Custom C++ binaries
Many bundled .so libraries (e.g., from OpenCV, PyQt/PySide)
Issues During Validation:
App Sandbox Not Enabled
Error: App Sandbox missing for NestedApp.app/Contents/MacOS/NestedExecutable.
Question: For Developer ID (not App Store), is sandboxing strictly required for nested PyInstaller apps? If the wrapper is sandboxed, must the nested app be as well? Given the PyInstaller app's nature (requiring broad system access), how should entitlements be managed?
Upload Symbols Failed
Errors for missing .dSYM files for:
The nested app’s executable
Custom C++ binaries
.so files (OpenCV, PyQt, etc.)
These are either third-party or built without DWARF data, making .dSYM generation impractical post-build.
Question: Are these symbol errors critical for Developer ID notarization (not App Store)? Can notarization succeed despite them? Is lack of symbol upload a known limitation with PyInstaller apps? Any best practices?
So I just updated Xcode to 16.3 and updated a project to its recommended build settings which includes "Register App Groups".
So I have an outside Mac App Store app that uses app groups. Here we have an action extension. I can't debug it, can't get it to run. Nothing useful in Xcode is displayed when I try... but it looks like a code signing issue when I run and have Console open.
So I try to make a provisioning profile manually and set it...didn't work. I noticed now though in signing & capabilities the group id is in red...like it's invalid, or something?
This was a "macOS styled" group without the "group." prefix. So am I supposed to switch it to have the group. prefix? It makes the red text go away (no warnings or anything about app groups here, just red text).
So if I change it to group. prefix..does that make an entire new container?What happens on app update for installs that don't have group. prefix? Does the system transparently migrate the group? Or Am I supposed to migrate the entire group container to the identifier with group. prefix?
Also how does this affect running on older version of macOS? If I go with the "group." prefix to make the red text go away,.. what happens on macOS 11.0? Got a little more than I bargained for here after midnight.
My Developer ID certificate will expire in few days, so I downloaded and installed new certificate in login keychain. However my key is still linked to my old certificate. I have my .p12 but even if I delete the old certificate from login keychain and reinstall the .12 file, my old certificate reappears in the login keychain.
I tried to select the new certificate in the login keychain and choose Files > Export Items (in Keychain Access) but in the Save dialog under File Format the "Personal Information Exchange (.p12)" option is grayed out. How can I generate a key/.p12 file that will be linked to my new certificate?
Hi,
I've code-signed my app and notarized it, and created a DMG, and when I slacked it or airdropped it to someone for testing the FIRST time they open it, they get a warning that it was Slacked or airdropped to them and do they want to open it. if they say yes everything is fine. So looking through here someone said I need to sign the app and then make a dmg and sign the dmg and then send that for notorization and then staple that. So I did, and I still get a warning the first tie someone try's to run it.
What am I doing wrong? I know I can buy software and not get a warning from apple. so how do I get my app to work correctly like that?
I developed a macOS application and have already signed the pkg package. However, when I submitted it for notarization using the following command:
xcrun notarytool submit --signed.pkg --apple-id "**@gmail.com" --team-id "2*******M" --password "this is password" --wait
I received a "Rejected" status. The log provided the following details:
"logFormatVersion": 1,
"jobId": "f5f3751d-b449-4a2f-b905-32d38ab5963b",
"status": "Rejected",
"statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.",
"statusCode": 7000,
"archiveFilename": "*********.pkg",
"uploadDate": "2025-03-20T03:16:43.651Z",
"sha256": "3ca39700c531a66571721424a6c00668748011174b4ae20bbbec5c2d3a8a41f9",
"ticketContents": null,
"issues": null```
Can you help me, thank you.
Topic:
Code Signing
SubTopic:
Notarization
In XCode I create and export a notarized app for "direct distribution". I then create a tar file of the exported .app to distribute to my users. Until today this worked fine. Now when the users try to run the app it pops up a dialog saying "app is damaged and can't be opened. You should move it to the Trash." It is possible to ctrl-click on the app and force it to run but, I think, whether this works or not will depend on system settings and not all users have root access to modify settings. Even simply copying the .app folder from the command line will cause this error.
I am facing this error on every flutter project build.
Although it runs ok.
The error happens on the codesign command
What do I need to fix ?
I have validated that every *.plist file is ok using plutil -lint
ERROR MESSAGE
/usr/bin/codesign --force --sign MY_SHA_CODE --verbose
/Users/macbookair/workspace/flutter_application_1/build/ios/Release-iphoneos/Runner.app/Frameworks/libswiftCore.dylib)` exited with status 0. The command's
output was:
/Users/macbookair/workspace/flutter_application_1/build/ios/Release-iphoneos/Runner.app/Frameworks/libswiftCore.dylib: a required plist file or resource is
malformed
Info.plist
<?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>$(DEVELOPMENT_LANGUAGE)</string>
<key>CFBundleDisplayName</key> <string>Flutter Application 1</string>
<key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string>
<key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
<key>CFBundleInfoDictionaryVersion</key> <string>6.0</string>
<key>CFBundleName</key> <string>flutter_application_1</string>
<key>CFBundlePackageType</key> <string>APPL</string>
<key>CFBundleShortVersionString</key> <string>$(FLUTTER_BUILD_NAME)</string>
<key>CFBundleSignature</key> <string>????</string>
<key>CFBundleVersion</key> <string>$(FLUTTER_BUILD_NUMBER)</string>
<key>LSRequiresIPhoneOS</key> <true/>
<key>UILaunchStoryboardName</key> <string>LaunchScreen</string>
<key>UIMainStoryboardFile</key> <string>Main</string>
<key>UISupportedInterfaceOrientations</key> <array>
<string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string>
<string>UIInterfaceOrientationLandscapeRight</string> </array>
<key>UISupportedInterfaceOrientations~ipad</key> <array>
<string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationPortraitUpsideDown</string>
<string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string>
</array> <key>CADisableMinimumFrameDurationOnPhone</key>
<true/> <key>UIApplicationSupportsIndirectInputEvents</key>
<true/></dict>
</plist>
Please help.
I'm trying to get an app notarized, which fails with this error:
The signature of the binary is invalid.
However, locally checking the signature does succeed:
$ codesign -vvv --deep --strict TheApp.app
[…]
TheApp.app: valid on disk
TheApp.app: satisfies its Designated Requirement
Performing this check on every single item in the app's MacOS folder also succeeds.
Context: embedded prebuilt binaries
Now, the app has something unusual about it: it embeds prebuilt binaries, arranged in various nested folders. So, the app bundle's MacOS folder actually contains another folder with a whole tree of executables and libraries:
Removing these (before building) does fix the notarization issue, but obviously I'd like to keep them in.
I did my best to properly sign these items:
At build time, they're copied into the product by a Copy Files phase (but not signed), then signed by a script phase
That signing uses the same signing identity as the running Xcode build, and enables the hardened runtime
The app builds and runs correctly, even as a release build
The app has runtime hardening and app sandbox enabled
How should I go about diagnosing the notarization issue?
Topic:
Code Signing
SubTopic:
Notarization
Keys can vary; an account is not necessary, as only Team Keys are suitable for notarization.
It seems that Developer role is sufficient for notarization.
We have tried both keys and roles of Developer and Account Manager - the behavior is the same.
Multiline
There are two types of API keys:
Team
Access to all apps, with varying levels of access based on selected roles.
Individual
Access and roles of the associated user. Individual kevs aren't able to use Provisioning endpoints, access Sales and
Finance, or notaryTool.
BlockQuote
Here are the parameters used for notarization via API key:
`-k, --key key-path
App Store Connect API key. File system path to the private key.
-d, --key-id key-id
App Store Connect API Key ID. For most teams this will be a 10 character alphanumeric string.
-i, --issuer issuer
App Store Connect API Issuer ID. The issuer ID is a UUID format string.`
The notarization result shows as successful, and on the same machine, the package appears as notarized.
However, when the package is transferred to another system, it is displayed as not notarized.
After signing and notarizing our application, the entitlement “com.apple.security.get-task-allow” is removed. However, we want this entitlement to remain and we want to be able to create a corefile when needed.
Is it possible to make the “com.apple.security.get-task-allow” entitlement persistent after signing and notarizing, so that our application can create a corefile?
Topic:
Code Signing
SubTopic:
Entitlements
I have local LLM application, the backend is in python and frontend is in electron.js , all complied in a .pkg file or .dmg file
I have created the valid certifcates for notarization
But it fails everytime, I have attached the logs
steps I followed
Created a certificate all steps related to getting it setup,
ran productsign command on pkg file
ran codesign for dmg
xcruntool submit command
If anyone has any idea on how proceed
codesigningdmg (2).txt
code-singingpkg.txt
Topic:
Code Signing
SubTopic:
Notarization
I have created a XPC server and client using C APIs. I want to ensure that I trust the client, so I want to have a codesigning requirement on the server side, something like -
xpc_connection_set_peer_code_signing_requirement(listener, "anchor apple generic and certificate leaf[subject.OU] = \"1234567\"")
This checks if the client code was signed by a code-signing-identity issued by Apple and that the teamID in the leaf certificate is 1234567.
My questions are-
Is using teamID as a signing requirement enough? What else can I add to this requirement to make it more secure?
How does xpc_connection_set_peer_code_signing_requirement work internally? Does it do any cryptographic operations to verify the clients signature or does it simply do string matching on the teamID?
Is there a way actually verify the clients signature(cryptographically) before establishing a connection with the server? (so we know the client is who he claims to be)
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Tags:
XPC
Signing Certificates
Code Signing
Hi,
I recently created and installed new code signing certificates/keys on my main Mac.
How to easily copy these certificates/keys to my another Mac with the same Apple ID?
Earlier Quinn suggested:
"The easiest way to do this is use Xcode’s import/export feature. Launch Xcode, choose Xcode > Settings, select Accounts, select the account in question, then choose Export Apple ID and Code Signing Assets from the action (…) menu."
And it worked fine in 2020-2021. However import/export options are no longer available in XCode 16 anymore.
Please suggest a simple solution.
Topic:
Code Signing
SubTopic:
Certificates, Identifiers & Profiles
Hey everyone,
I've been trying to notarize my Electron macOS app for the past two days without any success. My longest attempt took nearly 4 hours, and my current attempt has already been running for 2 hours and 26 minutes.
From what I can see in the logs, the signing step has completed successfully, and the app is currently in the notarization stage. But it's been stuck there with no real updates or progress indicators.
Is this kind of delay normal?
Has anyone else experienced such long notarization times?
Any help or insight would be greatly appreciated!
Thanks in advance.
Topic:
Code Signing
SubTopic:
Notarization
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:
<dict>
<key>SystemPolicyAllFiles</key>
<array>
<dict>
<key>Allowed</key>
<true/>
<key>CodeRequirement</key>
<string>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] = <TEAMID></string>
<key>Comment</key>
<string>app</string>
<key>Identifier</key>
<string>com.exmple.app</string>
<key>IdentifierType</key>
<string>bundleID</string>
<key>StaticCode</key>
<false/>
</dict>
</array>
</dict>
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
Hello,
Our company's software successfully passes the notarization process when exported through Xcode Archive and compressed into a zip file. However, it fails notarization when packaged into a pkg using the Packages software (version 1.2.10), consistently returning the error "The signature of the binary is invalid." We need assistance to resolve this issue.
Here are some specific details on the signature statuses and notarization information:
xcrun stapler validation: Successful
xcrun stapler validate Maxi\ PC\ Suite.app
Processing: /Users/autel/Desktop/test11/files/Maxi PC Suite.app
The validate action worked!
pkgutil signature check: Successful
pkgutil --check-signature Maxi\ PC\ Suite.pkg
Package "Maxi PC Suite.pkg":
Status: signed by a developer certificate issued by Apple for distribution
Signed with a trusted timestamp on: 2025-01-09 08:09:17 +0000
Certificate Chain:
1. Developer ID Installer: Autel Intelligent Technology Co., Ltd. (MEXQ8HADL9)
Expires: 2027-02-01 22:12:15 +0000
SHA256 Fingerprint:
B7 F7 AC 05 19 78 CB 5D 66 C1 11 95 EE C9 2E 31 B9 AA BD F5 32
E4 B6 4D 8D 0D 06 04 EE BC 1B 5A
------------------------------------------------------------------------
2. Developer ID Certification Authority
Expires: 2027-02-01 22:12:15 +0000
SHA256 Fingerprint:
7A FC 9D 01 A6 2F 03 A2 DE 96 37 93 6D 4A FE 68 09 0D 2D E1
8D 03 F2 9C 88 CF B0 B1 BA 63 58 7F
------------------------------------------------------------------------
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
SHA256 Fingerprint:
B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED
7E 2C 68 C5 BE 91 B5 A1 10 01 F0 24
pkg notarization: Failed
xcrun notarytool submit Maxi\ PC\ Suite.pkg --apple-id xxx --team-id xxx --password xxx --wait
Conducting pre-submission checks for Maxi PC Suite.pkg and initiating connection to the Apple notary service...
Submission ID received
id: ccbf6330-b64a-4b42-87c0-b5db1fe25b2d
Upload progress: 100.00% (3.42 MB of 3.42 MB)
Successfully uploaded file
id: ccbf6330-b64a-4b42-87c0-b5db1fe25b2d
path: /Users/autel/Desktop/test11/build/Maxi PC Suite.pkg
Waiting for processing to complete.
Current status: Invalid.
Processing complete
id: ccbf6330-b64a-4b42-87c0-b5db1fe25b2d
status: Invalid
Detailed notarization failure information:
xcrun notarytool log ccbf6330-b64a-4b42-87c0-b5db1fe25b2d --keychain-profile "PC_Suit_Mac"
{
"logFormatVersion": 1,
"jobId": "ccbf6330-b64a-4b42-87c0-b5db1fe25b2d",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "Maxi PC Suite.pkg",
"uploadDate": "2025-01-09T08:18:22.374Z",
"sha256": "0d1bd15e5c30bc890d20086de865739d01e131e34386b73ac20f8a5d52229906",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "Maxi PC Suite.pkg/Maxi_PC_Suite.pkg Contents/Payload/Applications/Maxi PC Suite.app/Contents/MacOS/Maxi PC Suite",
"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"
}
]
}
We are looking for advice on how to resolve the error related to the invalid binary signature during the pkg notarization process.
Thank you.
I started the notarization process for my electron app (just a browser window loading a URL) yesterday (26/03/2025) at around 05:23 GMT.
I noticed in a couple of posts here in the forum that it may sometimes take a day to notarize the first app submitted by a team, but it has been over 30 hours since I submitted the app for notarization
Here's the log.
createdDate: 2025-03-26T05:23:11.102Z
id: ddcb3fca-4667-4acb-8fd1-3298a7c244cc
name: xolock-browser.zip
status: In Progress
Is there any reason why it is taking so long?
Thanks in advance!
Topic:
Code Signing
SubTopic:
Notarization
Dear Apple Support,
for better understanding to use the Notary Service, I would like to ask when and what have to be notarized.
I am absolutely aware of using the Notary Service and which packages can be submitted and how to get the status.
Scenario:
We have one library which is developed by a specific team and other teams develop and deliver to customer MacOS apps which packages this library for the shipment.
So, the library will be produced internally and will be shipped in different products.
The library will be code signed before we make available internally.
When should we notarize (and staple) this library?
Directly after the code is signed or when it will be packaged in each product when it will be delivered to customer?
Best regards,
Stefan