However, if you can reproduce this reliably then I encourage you to file your own bug with the details. Part of the issue with getting traction on FB12074874 is that it only reproduces in odd situations, at least IME. Here is the filed bug number: FB22801461 Honestly, I would do minimal authentication here... Good to have confirmation on this, thanks It depends on the exact sequencing. When you’re at the login window, the system has already loaded your plug-in so updating it on disk doesn’t help. I typically update my plug-in when I’m logged in and then log out. The system will then pick up the new plug-in as part of bringing up loginwindow for the new session. I ran some more tests on this but with no luck. Is it possible that when the plugin is also used for general authentication, a machine restart is needed to load the new version, regardless of the method used for the update (manual copy while logged in/.pkg installation/scp from terminal)?

Hi Quinn, thanks for your support. After reviewing your code I still have a couple questions that remains unanswered: Glitch after successful login: It's clear this is a known bug (FB12074874) but in my tests it happens all the time, not just in specific scenarios like when screen mirroring is active, is there any sort of known workaround/solution to this? update() doesn't trigger the plugin to call view(for:): this is still an unresolved issue unless it's an expected behavior as mentioned in previous message setButton not working as expected: same here, see previous message Plugin update: I've noticed that on plugin updates, after logging the user out, the engine is still running the old version of the plugin instead of the updated one. A reboot is basically needed to apply the changes, is this the expected behavior? Certificate issue: Following your suggestion I've moved the networking code into a daemon and had my plug-in use XPC to communicate with it. Now I'm facing some issue trying to set code signing requirements with setCodeSigningRequirement: on the service side, since the plug-in is hosted in a system process, there's not much I can do but verify that the identifier of the process sending the request corresponds to the Security Agent Helper, which, as you can imagine, is not that helpful. On the client side I can instead be more specific since I own the service process but during screen unlock any verification fails, possibly for the same reason that prevented me to do trust evaluations directly from the plugin in the first place. If so, what's your take on this and how would you go about trying to make the connection to the daemon more secure?