@workingdogintokyo's suggestion worked. Except the compiler warns that the capture isn't used, even though it is. Yay!

This is at the declaration level, not in-function level. Eg., extension View { #if os(macOS) @ViewBuilder func onChange<V>( of value: V, initial: Bool = false, perform action: @escaping (V, V) -> Void ) -> some View where V : Equatable { onChange(of: value) { n in action(value, n) } } #endif }

Ooooh, let me try that. Nope, it had been an @State in the ItemView, I changed it to @ObservedObject, and it still doesn't update the view.

Oh, no, it's weirder -- command-B defines it, but command-R's build does not. Weird, but ok I guess.

In retrospect possibly obvious: the Firebase id is optional, so I added a slight layer of abstraction and use a type that has a non-optional id element. (I'd already had this type for other reasons, so it was a minor refactor.) With that done, it worked as expected. Including not crashing, which is always a nice benefit!

As always, thanks @eskimo and please pass my thanks along to JohnM, whom I don't think I know.

An update: this is fixed. While going through and collecting information for the TSI, I went through Keychain Access looking at all my Development certificates. And this time, it said they were all revoked! It did not say this before, and security said I had a bunch of them. So what the heckfire? However! I am able to build for development locally, which was the sob-inducing problem, so I can relax. And build again. Now to figure out how to get the Developer ID one working.

I have now filed a TSI request, because I am at my wit's end.

Well unfortunately that makes sense, so now I'm back to frustrated sobbing. It's still giving me this: I started logging everything, then launched Xcode. I have this log message which may be important? 2023-11-15 10:12:20.099861+0000 0xe0958 Debug 0x1ab38b 409 0 trustd: [com.apple.securityd:reject] non ev score: 111 lower than 1107 <SecCertificatePathVC certs: <cert(0x7f973b00a400) s: Software Signing i: Apple Code Signing Certification Authority> >

Unfortunately, fixing that doesn't fix the problem: Valid identities only 1) 769F003C52AC6942DAF0C5240B3824199F039C1E "Apple Development: Sean Fagan (8S9ZGBEAV3)" 2) 227FA0FB4088D4DD3984EF98D12C8EBB2E28A5D1 "Developer ID Application: Sean Fagan (7C43638LX4)" 3) B07B2C2AB9482E41ACE9868C1E74218AA7027FEA "Apple Development: Sean Fagan (8S9ZGBEAV3)" 4) A4A8B5E37FC91C456E8333DB2ADB32FF1C225536 "Developer ID Application: Sean Fagan (7C43638LX4)" 5) 7B1DE3A19E5EC6B80A8A07AA57887E446BF512C5 "Apple Development: Sean Fagan (8S9ZGBEAV3)" 6) C93D0A9C57506C93B7D5A20925E40E5FD035C09D "Apple Development: Sean Fagan (8S9ZGBEAV3)" 7) B5C7997E7231AB5AF3E86F84D42FA72B60501B13 "Apple Development: Sean Fagan (8S9ZGBEAV3)" (CSSMERR_TP_CERT_REVOKED) 8) 2BDFA67CFF67D25E8CED067446F5D1B6E89CD60B "Apple Development: Sean Fagan (8S9ZGBEAV3)" 8 valid identities found The developer ID seems to be wrong, however? I don't know why it's 8S9ZGBEAV3 for most of them, and 7C43638LX4 for the Developer ID Application ones.

Welp, this certainly looks like a problem: sef% security find-identity -p codesigning Policy: Code Signing Matching identities 0 identities found Valid identities only 0 valid identities found

So I did all that, got the certificate from my backed up login keychain, and... once imported, Keychain Access tells me it's been revoked. The web portal does not say so. And I still have no idea how to get Xcode-managed signing working.

Do you have an independent backup of your Developer ID signing identity? I should. I have an entry in 1Password that has the passcode and the .p12 file. And for the one I created yesterday, as I said, I used openssl specifically so that I would have everything it generated, and I stashed that in a tarball and attached it to the same 1Password note. Your article doesn't tell me how to deal with the fact that I can't build anything -- Xcode revokes my certificate but does not create a new one, or if it does it can't find it.

I am now in this state and I am beyond frustrated.

No, doing it from a UI app, as an agent, which is the containing app in /Applications. So... yes, still having issues. 😄 ETA: I am sure it is my code that's doing something wrong, but I can't figure out what. Before we had two extensions, the flow was: app startup -> activate system extension -> load preferences -> find manager -> load preferences from manager -> set isEnabled to YES -> save preferences. The new flow is largely the same, except that I'm also using notifications to tell when the configuration changes, because trying to do both extensions at the same time fails with permission denied; this means that when one of the extensions is activated and enabled, it sets a property which then checks the other one's state, and if it hasn't been set to YES then it starts that process. So, clearly (to me, anyway) that's where it's happening. But what I don't understand is why.