HI Quinn, When using the above created BLEAdvertising app by adding it to the LaunchDaemon (in logged in session not pre-login), once advertising started when I try to unload the app using "sudo launchctl unload /Library/LaunchDaemons/com.abc.myBLEapp.plist" it is stoping advertising as expected. But when I try to load again using "sudo launchctl load /Library/LaunchDaemons/com.abc.myBLEapp.plist" it is not starting advertising, to get the advertising I have to perform "sudo pkill bluetoothd". Am I missing anything to get the advertising start again when I load my app through launchctl? As pkill will kill and restart the bluetooth process, due to this if there are any other ble connected devices they need to get reconnected, so Is using pkill bluethoothd a proper approach?

Hi Quinn, Thankyou for the update and Yes, I am trying this as part of authorisation plug-in only. As you suggested, I tried separating out the bluetooth advertising from my daemon and invoke the bluetooth agent pre-login and perform advertising. Can you please help me understand when exactly this daemon gets invoked like is it only after restart or even at logout and login will I be able to invoke agent through daemon (how to control it)?

HI Team, Any update on the above question please.

Thankyou for proving the insights. Can you help me on the below question from what you mentioned "Therefore is not possible to use Bluetooth from a process without a logged in user. Your best bet would be to separate the Bluetooth functionality into a user level component, perhaps a user agent," so, if I create a user agent will I be able to invoke this user agent before login to user session? Because my need is to perform bluetooth advertising before user login (not unlock scenario)

Here is the FB number I have created FB19835797 ( On macOS Tahoe Icons in the prompts coming from macOS are getting left aligned)

Thank you Quinn, Here is the bug number FB19544589 (Keychain is not getting opened after unlock when system.login.screensaver is updated to use authenticate-session-owner-or-admin)

Hi Argun / @Engineer The peripheral manager is only supporting two advertisement keys: CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey. Is there any way to send 16-byte custom data other than using CBAdvertisementDataLocalNameKey? Any pointers or example references on this will be helpful. Thanks & Regards, Tata Chaitanya

The peripheral manager only supports two advertisement keys: CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey. Is there any way to send 16-byte custom data other than using CBAdvertisementDataLocalNameKey?

It means that we have to pair the user with smartcard and macOS will takecare of unlocking the logon keychain with smartcard. However there are no public APIs to unlock the logon keychain with a smartcard. Is my understanding correct?

Hi Eskimo, I have replied on the original DTS mail communication, can you please provide the required info on the mail thread. Here is the Case ID received, Case-ID: 10703131 Thanks & Regards, Tata Chaitanya

Hi Quinn, Can you please share me the latest QAuthPlugins. The one I have is couple of years old and the Readme documents in it do not have info related to FB13128730. Thanks & Regards, Tata Chaitanya

Thankyou Quinn, Below is the bug details created for this. FB13550696 (Screensaver is not coming when system.login.screensaver is updated to use authenticate-session-owner-or-admin) Thanks & Regards, Tata Chaitanya

Hi Quinn, As per the above conversation, I get Apple is working on a fix for this issue, is there any place where I can track the status as the bug I raised is still in Open state, and can we get informed here if a fix makes it to release? Is there any expected date? Thanks & Regards, Tata Chaitanya

Hi Eskimo, Do we have any steps/script to bring a custom/black background to hide the Desktop, so till the time we get a fix by Apple, we will use this as a work around. Do you suggest any alternate work around which will help us here? Thanks & Regards, Tata Chaitanya

Hi Eskimo, I have updated the bug **FB13000811 **(Lock Screen with SFAutorizationPluginView(old UI) is not hiding the macOS desktop). As this issue is observed even without our product, Do you still want me to create a TSI request for this to check for a fix/solution? Sonoma preview is going to be available from 26th September, so do you think this will be addressed before that or how will we take this up? Thanks & Regards, Tata Chaitanya