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. 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. 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? 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.