codesign

I’ve learnt a new trick so I wanted to expand on the steps I posted yesterday. I started off by running the steps up to “My next step was to add an app group to the app” point. From there I did this: On the Development website, I confirmed that the target app group ID, group.eskimo1.test, was allocated to my team. In Xcode, I navigated to the build settings for my app target. I clicked the add (+) button and added a custom build setting of REGISTER_APP_GROUPS with a value of YES. This enables the iOS-style app groups UI on Xcode 16.2. I navigated to Signing & Capabilities and added the App Groups capability. Under the group list I clicked the add (+) button. This presents the iOS-style UI. In that UI, I entered my group, group.eskimo1.test, and click OK. Xcode’s automatic code signing machinery kicked in and updated my profile. No muss, no fuss! I chose Product > Build. I dumped the signing state of the development app: % codesign -d --entitlements - Test775022E.app … [Dict] [Key] com.apple.ap

One of my goals for today was to explore how Xcode 16.2 handles the app group changes we recently introduced. So I sat down and ran some tests. As a first step, I created a new app that does need a provisioning profile but doesn’t use an app group. The goal here is to cause Xcode to create and stash the development and distribution profiles for that app. Here’s what I did: Using Xcode 16.2 on macOS 15.3.1, I created a new app from the macOS > App template. I gave it a new, unique bundle ID, com.example.apple-samplecode.Test775022D, to make sure I’m starting from scratch. Note Note the D suffix. It took me 4 tries to get this right (-: In the Signing & Capabilities editor, I set the Team popup and confirmed that automatic signing was enabled. I added the iCloud capability. This forces Xcode to allocate an App ID and generate a profile for that App ID. Without that, Xcode uses my wildcard App ID, which just confuses things. I left the iCloud setup blank. I don’t need this app to use iCloud. I chose Produ

An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost... EtreCheck isn't designed to be used with developer builds of apps. It only considers Developer ID and App Store builds as valid. You should consider spctl the authoritative result. Years ago, I used to use codesign more and I would test a Developer ID build with codesign -vv -R=anchor apple generic /path/to/app. However, you also mentioned TestFlight. I've never used TestFlight, but isn't that an App Store thing? So are you doing developer-signed builds? EtreCheck has no idea about that. Never attempt to disable Gatekeeper on your developer machine. That would be a bad idea. Thankfully, Apple recently added an extra hoop to jump through that saved you. I'm sure your Sequoia install is fine. It's the app that's corrupt. I was confused at first when you were talking about Monterey and App Store. You need at least Ventura/Xcode 15 for App Store submission

[quote='775159021, adminTC, /thread/775159, /profile/adminTC'] The installer contains a flat file [/quote] Is that a Mach-O executable? Or something else? Because, in general, the notary service only requires that you sign the code within your installer package. If it contains data, you have to sign the package but you don’t have to sign the data that the package installs. Still, the most likely cause of your problem is a misunderstanding about how to sign installers. Installers are not code, and thus: You don’t sign them with codesign, but rather with installer-specific tools. You don’t use your Developer ID Application code-signing identity, but rather your Developer ID Installer signing identity. Packaging Mac software for distribution has all the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks again. I ended up just following your advice from the original post and heavily documenting how to create developer (NOT distribution) certificates for my developers to use. Our distribution certificate is now just hooked into CI (and only there). Seems to work for our use cases! There are still a few fun things to determine, like computing a developer or distribution 'code requirement' so we can enable the full disk access TCC config for our app (codesign -dr - foo.app wants to pin the CR to the developer's CN). However I think i'll just post separately about that at some point. Thanks again! D

[quote='826188022, aehlke, /thread/758358?answerId=826188022#826188022, /profile/aehlke'] looks like this behavior has changed in the last day or two for macOS? [/quote] Yes! It makes me very happy to say that there’s been a significant improvement in this space. It’s now possible to create a macOS provisioning profile that authorises the use of an iOS-style app group. I’ve made a quick update to App Groups: macOS vs iOS: Fight! just now, but at some point I’ll go back to that post and update it properly with all the details. I tested this today with Xcode 15.4b1 running on macOS 15.3.1. Here’s a regular macOS app [1], created from the macOS > App template, using automatic signing, signed for development with an iOS style app group: % codesign -d -vvv Test721701.app … Authority=Apple Development: Quinn Quinn (7XFU7D52S4) … % codesign -d --ent - Test721701.app … [Dict] … [Key] com.apple.security.application-groups [Value] [Array] [String] group.eskimo1.test … % security cms -D -i Test72170

I was able to solve the self-update problem with Quinn's advice regarding codesigning with designated requirements. AssociatedBundleIdentifiers still doesn't work as documented, so I have opened a feedback ticket: FB16563823. Thanks for the help Quinn!

We were missing a step where we were not embedding the provisioning profile in our app, so we created one with default entitlements using our developer account and downloaded that. Then we provided this provisioning profile and the entitlements to the electron build process which embedded the provisioning profile in our app. We also checked the provisioning profile with the commands provided in the link. The app you uploaded to the bug is properly signed. The output of: codesign -dvvv --ent :- Lists these entitlements: com.apple.security.cs.allow-dyld-environment-variables com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.disable-library-validation com.apple.security.device.usb While the output of: security cms -D -i /Contents/embedded.provisionprofile Is this: Entitlements com.apple.application-identifier __TEAM ID__.__BUNDLE ID___ keychain-access-groups __TEAM ID__.* com.apple.developer.team-identifier __TEAM ID__ Once again, please ta