Search results for

“codesign”

3,223 results found

Post

Replies

Boosts

Views

Activity

Best practices for post-build codesigning

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

Developer Tools & Services Xcode Cloud Signing Certificates Code Signing Developer ID

415

Sep ’25

"Application damaged and can't be opened' error prompt on 15.6.1 Sequoia

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

Code Signing General macOS Gatekeeper

2.7k

Sep ’25

Reply to Does NSXPCConnection.setCodeSigningRequirement perform dynamic code signature checks?

Hi Quinn, We are indeed trying to ensure our daemon is only accessed by our client. We do have hardened runtime and kill via -o runtime in our codesign use. We have some old code that checks our signing requirement though (pre-macOS 13) but it seems we can replace that old code with setCodeSigningRequirement(_:) instead. I wasn't clear from the documentation on setCodeSigningRequirement whether that was the case. Thanks, Dave

Code Signing General

Aug ’25

Reply to Does NSXPCConnection.setCodeSigningRequirement perform dynamic code signature checks?

So what threat are you trying to protect against here? Most folks who ask about setCodeSigningRequirement(_:) are trying to ensure that their daemon is only accessed by their client. If that’s your goal then this question isn’t really relevant. If the client process’s code signature becomes invalid before it connects, this check will reject the connection. And if not, you know you’re working with the expected client and thus you can assume it won’t do something to invalidate its signature. On the client side, you want to make sure your client enables the hardened runtime and doesn’t include any entitlements to disable the security features that the hardened runtime enables by default. Oh, and for extra assurance you can sign you code with the kill flag. See the codesign man page for more on that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Code Signing General

Aug ’25

Code signing fails with “unable to build chain to self-signed root for signer "(null)"” and errSecInternalComponent for Developer ID Application on macOS

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) : 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 a

Code Signing General Code Signing

403

Aug ’25

Reply to Xcode 16.4 Can't Attach to iPhone app for debugging

[quote='854898022, Steve-Olson-1951, /thread/797142?answerId=854898022#854898022, /profile/Steve-Olson-1951'] I built a very basic test app from Xcode templates [/quote] That’s always a great diagnostic test. In this case it confirms that there’s something specific about your main project that’s causing this issue. I have some further suggestions: From the Home screen, remove your main app from the device. And then restart the device. These steps should remove any state leftover from any previous builds of the app. Do a clean build of the app. Do a Product > Run. Does it still reproduce the problem? Presuming it does, run the app from the Home screen and then do a Debug > Attach to Process. Does that work? Also, after the rebuild in step 3, choose Product > Show Build Folder in Finder, then navigate to the Debug-iphoneos folder and, in Terminal, run this command: % codesign -d --entitlements - MyApp.app … [Dict] … [Key] get-task-allow [Value] [Bool] true As this code is Development signed, y

Developer Tools & Services Xcode

Aug ’25

Is there a tutorial or good resource about publishing a Python based app on Apple Store?

Hi guys, Is there any good up-to-date tutorial about publishing a Python based app on Apple Store? Now, I have developed a standalone Python app from PyCharm, and it's using Pyside6 for UI and some major Python libraries. It's a productivity app with a little A.I. features. I used PyInstaller to prepare the app. Currently, I am stuck at the stage of codesign and Apple Review process, because I am manually doing codesign and building the package from command-line. Without using Xcode, things can get messy or miss easily. It would be nice to follow a up-to-date tutorial about how to complete the codesign and Apple Review process for a Python based app. For example, what to do, how to do, what to be careful during the Apple Review process, etc. Thanks!

Code Signing General Design App Review Entitlements

181

Aug ’25

Reply to Problem adding Call Directory capability

On our paid Apple Developer Program account (role: Account Holder/Admin), the Call Directory capability toggle does not appear on any iOS App Extension Identifier we create. Because of that, provisioning profiles for those extension IDs never include the Call Directory entitlement and the extension cannot be enabled on device. That is the only reason we tried to add manually which does not work. Environment Membership: Apple Developer Program (paid, active) Xcode: [16.x] iOS devices tested: iOS 18.4.1, 18.5 and 18.6.1 App type: iOS app + Call Directory extension App Groups: enabled and working What I am not seeing In Certificates, Identifiers & Profiles → Identifiers → (iOS App ID, type App Extension), I expect to see a Call Directory capability toggle I can enable but it is not there What actually happens The Call Directory toggle is missing from the extension Identifier details page. Profiles created for the extension ID don’t contain the Call Directory entitlement. The extension never appears under Set

Code Signing Entitlements

Aug ’25

Reply to Dynamic Library cannot call exposed C function

@DTS Engineer as an aside for extra info. I'm adding the xcframework via cocoapods and I have tried to modify the signing of the framework via the following script in the podspec. I know Apple might not encourage the usage of Cocoapods but this is needed so we can distribute our library through several platforms s.script_phase = { :name => 'Sign Framework Binary', :execution_position => :before_compile, :script => <<-SCRIPT echo 🟦🟦🟦🟦🟦🟦🟦 Framework Binary Signing Script === # Use BUILT_PRODUCTS_DIR which points to BuildProductsPath FRAMEWORK_DIR=${BUILT_PRODUCTS_DIR}/../XCFrameworkIntermediates/${PRODUCT_NAME}/sdk.framework # Debug: Print the expected path echo Looking for framework at: $FRAMEWORK_DIR if [ -d $FRAMEWORK_DIR ]; then # Try different ways to get signing identity SIGN_IDENTITY=$EXPANDED_CODE_SIGN_IDENTITY if [ -z $SIGN_IDENTITY ] || [ $SIGN_IDENTITY = - ]; then SIGN_IDENTITY=$CODE_SIGN_IDENTITY fi if [ -z $SIGN_IDENTITY ] || [ $SIGN_IDENTITY = - ]; then # Use the first availab

Code Signing General

Aug ’25

Reply to App IPA upgrade loses access to keychaingroup

There are two important criteria for evaluating keychain access groups: The list of groups you can access. The default keychain access group, that is, the one used when you add an item and don’t specify a group. Sharing access to keychain items among a collection of apps explains how these are set based on three different entitlements in your app’s code signature. When debugging problems like this, I recommend that you unpack the old and new .ipa files (they’re a zip archive under the covers) and dump the entitlements of both apps: % codesign -d --entitlements - /path/to/your.app Compare the two to see what’s changed. Once you understand what’s, you can then start investigating how the new app got signed in that way, and then work out how to fix it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Privacy & Security General

Aug ’25

Reply to app is already signed / code object is not signed at all

I’ve seen problems like this before. In one case it was because the developer was passing multiple subcommands to the codesign command. That is, they were passing in --sign (aka -s) and --verify (aka -v) to the same codesign invocation, and that caused weird issues. And the solution was to stop doing that (-: However, the most common cause is that the app doesn’t follow the rules in Placing content in a bundle or you’re not following the steps to sign nested code in Creating distribution-signed code for macOS. Consider this example: % mkdir -p MyTrue.app/Contents/MacOS % cp /usr/bin/true MyTrue.app/Contents/MacOS/MyTrue % cp /usr/bin/false MyTrue.app/Contents/MacOS/MyFalse % codesign --remove-signature MyTrue.app/Contents/MacOS/MyFalse % codesign --remove-signature MyTrue.app/Contents/MacOS/MyTrue % codesign -s - MyTrue.app MyTrue.app: code object is not signed at all In subcomponent: /Users/quinn/Test/MyTrue.app/Contents/MacOS/MyFalse This bundle structure is corr

Code Signing General

Aug ’25

app is already signed / code object is not signed at all

Our app .dmg file was successfully code signed. We then revised the app and created a new .dmg. Running codesign gave an app is already signed message. Then running codesign -dv said code object is not signed at all Older solutions said to use -f to force signing, but that is no longer an option.

Code Signing General Code Signing

144

Aug ’25

GateKeeper rejects application bundles with a file name with an NFC/NFD problem by copying with Finder

I made a macOS application using Swift Package and distributed it in dmg format through Apple Notary service. However, we received a report from a user that it can be launched from a disk image mounted from dmg, but when copied to /Applications, the app is broken and does not start. I looked into why this happened, I noticed that the codesign command returned different results when copying the application bundle and /Applications on the volume mounted dmg with Finder. Mounted dmg: OK ❯ codesign --verify --deep --verbose /Volumes/azoo-key-skkserv/azoo-key-skkserv.app /Volumes/azoo-key-skkserv/azoo-key-skkserv.app: valid on disk /Volumes/azoo-key-skkserv/azoo-key-skkserv.app: satisfies its Designated Requirement Copied by Finder: Bad codesign reports that there are 148 added/missing files. ❯ codesign --verify --deep --verbose /Applications/azoo-key-skkserv.app /Applications/azoo-key-skkserv.app: a sealed resource is missing or invalid file added: /Applications/azoo-key-skkser

Code Signing General

332

Aug ’25

Reply to unzip identifier is not unique?

Consider this: % ls -i /usr/bin/zipinfo /usr/bin/unzip | cat 1152921500312524002 /usr/bin/unzip 1152921500312524002 /usr/bin/zipinfo unzip and zipinfo have the same inode number, meaning that they are both hard links to the same file. That’s why you’re seeing inconsistent signing identifiers. I suspect that the OS build process is signing one and then signing the other, and you get the identifier for whichever one it did last. That’s curious, and it’s something that I’d like to file a bug about. Before doing that I’d like to nail down the details as to where you see which behaviour. I tested this locally and I always see com.apple.zipinfo: % codesign -d -v /usr/bin/unzip … Identifier=com.apple.zipinfo … This was on macOS 14.x, macOS 15.5, and macOS 26.0 beta. Where are you seeing com.apple.unzip? As to what you should do in your app, you can craft an LWCR that supports either identifier: let lwcr = try LaunchCodeRequirement.allOf { ValidationCategory(.platform) anyOf { SigningIdentifier(com.apple.unz

Code Signing General

Aug ’25

Safari App Extension fails to connect to CloudKit daemon (cloudd) with XPC communication errors -- CKErrorDomain Code=6 / NSCocoaErrorDomain Code=4099 – Unable to connect to CloudKit daemon

I'm working on a macOS app with a Safari web extension. I'm trying to share a SwiftData model between devices using CloudKit synchronization. I am able to get synchronization in the main app on the same device, CloudKit sync works correctly — changes appear in the CloudKit Dashboard under com.apple.coredata.cloudkit.zone. However, in the Safari App Extension, data is saved locally and persists across launches, but never syncs to CloudKit. I have followed the recommended practices for configuring the App Group and entitlements, but the issue persists. Questions: Is there an official limitation preventing Safari App Extensions from connecting to the CloudKit daemon (cloudd)? If not, what entitlements or configuration changes are required for a Safari App Extension to successfully sync with CloudKit? Is the xpc_error=159 from bootstrap_look_up() a known sandbox restriction for this extension type? Any guidance from Apple engineers or others who have successfully used CloudKit from a Safari App Extension would be

App & System Services iCloud & Data Safari Extensions

146

Aug ’25