Search results for

codesign

3,110 results found

Post

Replies

Boosts

Views

Activity

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
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
Topic: Code Signing SubTopic: Entitlements Tags:
Aug ’25
Content Filter: sourceAppAuditToken empty only for Firefox
Starting on macOS Sequoia, flows originated in Firefox have an empty sourceAppAuditToken. Other apps contain a valid token. Background: in order to fetch process info for a certain NEFilterFlow, my content filter extension uses sourceAppAuditToken, audit_token_to_pid() and proc_* (as recommended in #126820). When that fails, we use SecCodeCopyGuestWithAttributes, recommended in some other thread as a better alternative. Both approaches break when the sourceAppAuditToken is empty since they need the pid. Debugging: My logging shows audit token is empty for Firefox Typical logs from com.apple.networkextension also indicate it fails to fetch the same info I'm looking for: com.apple.networkextension debug 11:22:07.024588-0300 Fetching appInfo from cache for pid: 948 uuid: 5C40B765-C6C9-3641-A822-2BC44D264361 bundle id: (null) com.apple.networkextension debug 11:22:07.024657-0300 Calling delegate lookup handler with pid: 948, uuid: 5C40B765-C6C9-3641-A822-2BC44D264361, bundleID: (null) com.apple.networkextension d
3
0
473
Aug ’25
Dynamic Library cannot call exposed C function
This is a lengthy one. I have basically compiled a Rust binary into a dylib and packaged into a .xcframework that contains per arch .frameworks. This loads correctly when run from Xcode into a real iOS device. However, when deployed to TestFlight the app crashes. Here is what is a bit different, the dylib is not fully self-contained. It tries to reach in an use C functions I have exposed in my library code. Calling functions that are just within the dylib and just return works fine, but the moment it tries to call one of the exposed functions it crashes. A full in-depth step by step of how I packaged the binaries can be found in my website: https://ospfranco.com/complete-guide-to-dylibs-in-ios-and-android When I look at the TestFlight crash report there are no symbols but the termination cause via WatchDog is: Termination Reason: CODESIGNING 2 Invalid Page I have declared my functions as such: OBJC_EXTERN void ios_prepare_request(const char *url) #define EXPORT __attribute__((visibility(default), use
Topic: Code Signing SubTopic: General Tags:
16
0
272
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
Topic: Code Signing SubTopic: General
5
0
268
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
Topic: Code Signing SubTopic: General Tags:
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
Topic: Privacy & Security SubTopic: General Tags:
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
Topic: Code Signing SubTopic: General Tags:
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
2
0
78
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
Topic: Code Signing SubTopic: General Tags:
Aug ’25
Reply to PCIDriverKit entitlements during development
In the meantime, I've discovered a few more facts, which I'll detail here. I'll also file some bugs and attach their numbers here. Perfect, thank you. I did manage to get a PCI driver to match and install on a victim machine. I used an Xcode-generated profile that includes our own PCI entitlement, but installed the driver on a machine with entitlement checks turned off. Yep, that will work. It's not something I can really recommend (for obvious reasons), but it is intentional that this does work. Moving to here: I then tried making a USB driver for development (for a vendor ID we don't have an entitlement for). On my usual Mac, the driver won't load because the entitlement in my provisioning profile is for a specific vendor ID - I can't choose the development USB transport capability. First, as a quick clarification, the term capability is basically a term Xcode invented for its own UI because what it's actually showing is a mix of: Entitlements Other stuff (like Info.plist keys) which are NOT in fact entitle
Topic: Code Signing SubTopic: Entitlements Tags:
Aug ’25
Reply to Gatekepper acts against .app package developed by a freelancer for our company
[quote='852386022, VBFSDEV, /thread/795578?answerId=852386022#852386022, /profile/VBFSDEV'] they will have access to all certificates, as you cannot grant selective certificate access. [/quote] I think you’re confused by the terminology here (an industry-wide problem, alas). It’s fine to give anyone access to a certificate. It only contains a public key. To sign code you need a digital identity, aka a code-signing identity, which is a certificate and the private key that matches the public key in that certificate. So, there’s no issue with your freelancer being able to access your Developer ID certificate [1]. What you have to protect is the matching private key. I discuss this terminological confusion in more detail in TN3161 Inside Code Signing: Certificates [quote='852386022, VBFSDEV, /thread/795578?answerId=852386022#852386022, /profile/VBFSDEV'] there is no solution to perform our signing process without granting the freelancer access to our app store connect account, correct? [/quote] It’s not that ther
Topic: Code Signing SubTopic: General Tags:
Aug ’25
Codesign can't find keychain files (on M2 MacBook)
I've been distributing my Math Education app (Java-based) as a downloadable .dmg. My sw manufacturing process was working well on my Intel-iMac a year ago (signing, notarization, stapling). I need to support Apple Silicon, so I replicated the SW manuf. stack on my M2 MacBook, including putting my Developer and Installer Certificates in the Keychain Access. I get through building the M2,M2,M4 .dmg installer file just fine. But the Codesign is failing. It should be prompting me for my MacOS password (it does this in the Intel-Mac process), but fails this command: codesign --sign Pierre Bierre (SL7L4YU8GT) --force --options runtime --verbose --timestamp ~/DFG2D_MacOS_Manufacturing/MacOSInstallers/DFG2D_Mac_J17010_295 The response was: error: The specified item could not be found in the keychain. The signer reference is correct, and works fine on the Intel-Mac codesign process. What could explain why the same script fails in the M2 environment? Does codesign normally prompt for
4
0
219
Aug ’25
Reply to PCIDriverKit entitlements during development
When I look at the available capabilities I can add to an app identifier on the Developer portal, I see com.apple.developer.driverkit.transport.usb, which is development only. There's no development only capability for PCI. Yes, and please file a bug about this and post the bug number back here. I don't know WHY there isn't a development only entitlement (I wasn't involved with DriverKit at the time), but it's a decision I'd like to revisit. And yes... Does this mean it isn't possible to develop even a proof-of-concept PCI driver without being first granted the DriverKit PCI (Primary Match) entitlement? ...that's exactly what it means. You could do this by disabling SIP (and possibly AMFI), but you can't use the more elegant flow the development entitlements allow. In addition: When adding capabilities to a driver, the list of available capabilities shown in Xcode has one DriverKit PCI (Primary Match) entry, but if I double-click it, two such entries appear in the Signing and Capabilities tab for my driver ta
Topic: Code Signing SubTopic: Entitlements Tags:
Aug ’25