I'm not sure yet if it's related or not -- but on our side we are normally connecting to RFCOMM over Bluetooth (SPP protocol) for our device. We have failed to open socket connection since the upgrade to macOS Monterey. After investigation, we found out that: The SDP protocol we had in place did not work exactly the same -- we did not receive an event when SDP completed, which caused our app to fail to try a connection (first issue) We used to look at recentDevices() to connect, and the function failed to return recent devices. pairedDevices() has been working properly. Finally, we have found that under a specific set of circumstances, we are able to connect to RFCOMM. However, this only happens when we "beat" the OS to the punch, and manage to open the socket before it gets "locked". I cannot confirm this for certain, but it's likely that something is blocking the connection to RFCOMM socket on the OS side. An example might be if the OS steals the BLE connection to fetch battery level, preventing us to access the classic bluetooth service SPP. In the cases where we managed to connect RFCOMM, the battery % was not displayed next to the device after connection in the Bluetooth menu. It may simply be a coincidence, but in the past we have observed similar issues when trying to connect within our application both BLE Battery service and classic BT SPP at the same time. One ended up blocking the other... If anyone's device uses both SPP/Battery level, this may be the issue you are facing. In order to successfully connect on our side, we normally turn off the device, then try to initiate a connection in the OS (which will try for a while but fail since the device is off). However, while it's trying, and before it fails -- if you turn on the device and enable RFCOMM, there is a chance you can successfully establish the socket connection. Once the connection is established on our side, it's stable.