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

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.

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

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

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.

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

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

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

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.

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.

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, let me try those!

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, no, my onAppear() was being called twice, and so I was registering twice.

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.