I decided to try DistributedNotificationCenter. It doesn't fire at all without deliverImmediately: true, and then I get TWO notifications for each one that I send.

Oh, no, my onAppear() was being called twice, and so I was registering twice.

Not sure what you're asking for. I create the window from a .xib, is there an inspector pane I should look at? The window is narrow (19 px tall) and the width changes dynamically depending on the content, as configured by the user.

Oh, let me try those!

Yes, that helps a lot! I'm able to remove my tap from the run loop if this is false, and that seems to solve the issues. Thank you!

Oh, thanks Quinn! This is the right answer, but I don’t see a way to change the selected answer. The documentation is very thin, but it seems requesting Post implies Listen, and grants both kTCCServicePostEvent and kTCCServiceAccessibility in the TCC database. Requesting only Listen grants only kTCCServiceListenEvent and not kTCCServicePostEvent or kTCCServiceAccessibility.

So, it seems that if the user revokes Accessibility, the TCC DB shows both kTCCServicePostEvent and kTCCServiceAccessibility revoked, but the preflight calls continue to return true, while AXIsProcessTrusted returns false. I think I'll have to stick to that call for determining status.

I'm a little astonished that Apple doesn't consider this support absolutely essential, given that the Associated Domains Entitlement has provision for unreachable servers (https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_associated-domains?language=objc) via "alternate mode." I would argue that it is very, very often the case that the unreachable private server is localhost, and unlikely to be running on 443 or have a valid TLS cert. I filed FB13672492

I see this too, in 17.4/15.3. I filed FB13687719

Is there an easy way to decode these, for debugging purposes?

I like trying stuff out via unit or UI test, and automating functionality tests to help prevent regressions. But in this case, it's quite hard to test on device. I need two devices, and one probably needs to not be signed in to the same AppleID.

@garrett-davidson Some thoughts on improving the Passwords UI: FB13697058.

Thanks for the resources, Quinn! I'm actually familiar with the distinction, just tired and imprecise in my post.

You might think that, but you‘d be wrong. These are packages that build with make, and don’t easily understand Apple platforms or architectures.

Ohhh ffs. thats probably it. Maybe if I’m a paying developer program member they don’t need to be so strict.