Developer ID target can't be signed or notarized automatically

macOS application Mulligan's Eagle (403115926)

macOS deployment - macOS 10.14 (Mojave) through Sonoma 14.5

macOS targets - Mac App Store, ad hoc direct drag-to-install image

Xcode version 15.4, various development Macs (Intel, M1, M2)

Eagle delivered since pre-Mac App Store days - derived from System 7 MacApp development. App most recently delivered with min system Mac OS 10.12 through current Sonoma 14.5, dual target for Mac App Store automatically signed with Apple Development credentials and for outside release automatically signed with Developer ID credentials.

Recent revisions to the software to bump min system to 10.14 (Mojave) with typical continuing development for tech, reqm'ts, etc. Updates (a couple since previous release) to Xcode - now using version 15.4, which recommended some config changes that made sense, except min system. Popular application with lots of older (uh... elder) users running Macs servicing golfers.

The application is ready to distribute with automatic signing, but wasn't able to do so with Developer ID credentials, but Xcode note (and reading of tips in this forum and my poor understanding) managed to submit for notarization - failed.

Tried to manually sign...

and reviewed signing info in Xcode...

So I reviewed Certificate(s) etc. that should have been used when previously signing Dev ID for notarization and release. I have (I think) six Developer ID Application certs and six Developer ID Installer certs and I can't find any combination of those certificates - some with duplicate dates or expirations - that allows me to use one to automatically sign code to notarization or delivery. What do I do? I've lived a peaceful solo developer life for 25 years delivering and signing code for the Mac and as long as iOS has existed. I'm terrified about this issue however...

My early Mac OS using customers (since Lion - pre sandbox) still have serial numbers for this software and have bought a Mac every 6 - 10 years so they could get my latest release. We've never required that they re-purchase from the App Store... they have a perpetual license. Sandboxing was a shock they never felt - we kept delivering updates to them and if they decided sandboxing mattered, they purchased from Apple and we included the container-migration entitlement in the App Store version to move their data to the new sandbox. Pretty slick. Until we built an install disk to test it on an unsandboxed version of Eagle in our office. It "lost" its data - vanished by remaining in the old Application Support directory while the new hardened runtime version looked for it in the sandbox - finding nothing. Just imagine encountering that if you're 80 years old running a golf league.

  1. How can I "reset" the futzed-up certificate Developer ID mess? I have multiple machines, all with varying subsets of what seem to be good certificates. And Xcode builds new provisioning profiles just for the heck of it, it seems. I'm afraid to revoke or throw out any certificates because I can't tell which ones are good, bad or duplicates - they're all valid. And I can't create any more Developer ID certs because there's a max to control certificate-miscreants like me (yes, I've read Quinn's protection of your Dev ID note - I screwed it up with only 1 employee). I depend on automatic signing because I'm still, after 58 years of coding, just a novice.

  2. Is it true that I should still specify in my build settings that I'm using Developer ID credentials for my ad hoc development and distribution schemes? And that the proper settings for those should NOT enable hardened runtime or app sandboxing?

  3. Sorry for my intensity here.... It's been 2 weeks since App Review bonked an initial submission with just an "it's broken" reject message, and DTS decided this is not such an emergency that the Developer Forum shouldn't be able to handle it. I'm truly hoping it's so.

Answered by DTS Engineer in 798174022
I have two targets - for Mac App Store distribution (not yet tried) and Developer ID distribution, notarized (currently failing).

Right. And your Mac App Store target enables the App Sandbox while your direct distribution one does not.

From Xcode organizer, the Validate response is:

Hmmm, that’s not a relevant test. The Validate App button validates the app against App Store rules. It’s not a appropriate for your directly distributed app.

To notarise that you, click Distribute App and then follow the Direct Distribution workflow.

Hmmm, come to think of it, I’d appreciate you filing a UI bug against the Xcode organiser about this. The parallel between Distribute App and Validate App is very misleading for Mac apps, where the second choice only makes sense for App Store apps. You are not the first developer to be mislead by this )-:

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Developer ID signing identities are precious. I talk about this in detail in The Care and Feeding of Developer ID.


A word on terminology. We use ad hoc to mean two different things:

  • Capitalised as Ad Hoc, as a distribution mechanism for iOS and its child platforms.

  • In the phase ad hoc signed, to mean a code signature with no signing identity

AFAICT neither is relevant here. Rather, you have two distribution channels:

  • Mac App Store

  • Direct distribution, using Developer ID signing

Is that right?

I often see Developer ID distribution as shorthand for that second one.


My general advice for folks using Xcode to build an app:

  • Configure your project to use automatic code signing. Xcode will then using an Apple Development signing identity for day-to-day development builds.

  • Prepare for distribution by using Product > Archive to create an Xcode archive.

  • Export final products from that Xcode archive using the Xcode organiser (or xcodebuild, if you want to automate this process). This lets you choose the distribution channel, and Xcode will re-sign your app accordingly.

I recommend you set your project back into this state and then try uploading to the App Store. Does that work?

Once you get that working, it’s time to tackle the Developer ID side of this (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, you are correct. Thanks for the terminology help. I have two targets - for Mac App Store distribution (not yet tried) and Developer ID distribution, notarized (currently failing). I have configured for automatic signing and created the archive. From Xcode organizer, the Validate response is:

which wants a /Applications install destination and the enabled .security.app-sandbox entitlement. Then, from the Distribute option:

So no go. I have not used xcodebuild, but these failures seem to be from some Xcode (15.4) requirement for hardened runtime and sandboxing. This failure right at this stage is what's different than the last years of distributions. I will brush up on xcodebuild and try that. I'll get back if it works, but the sandboxing problem seems to be the first hurdle.

Accepted Answer
I have two targets - for Mac App Store distribution (not yet tried) and Developer ID distribution, notarized (currently failing).

Right. And your Mac App Store target enables the App Sandbox while your direct distribution one does not.

From Xcode organizer, the Validate response is:

Hmmm, that’s not a relevant test. The Validate App button validates the app against App Store rules. It’s not a appropriate for your directly distributed app.

To notarise that you, click Distribute App and then follow the Direct Distribution workflow.

Hmmm, come to think of it, I’d appreciate you filing a UI bug against the Xcode organiser about this. The parallel between Distribute App and Validate App is very misleading for Mac apps, where the second choice only makes sense for App Store apps. You are not the first developer to be mislead by this )-:

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

A couple of things have gone right today.

First, I filed a bug report (FB14610234) about the ambiguous Validate button in the Xcode Organizer Archives presentation, and a weirdness in that little popup filter at the top left.

I've been back through all my build settings for both targets, and there's no mention anywhere anymore of Developer ID certs. I built, notarized and delivered a Developer ID release just an hour ago, and the same code, different target is in Review for App Store distribution right now.

I still have a mess having maxed out my Dev ID certificates. I'll reread "The Care and Feeding…".

Developer ID target can't be signed or notarized automatically
 
 
Q