They’ve changed Bluetooth chipsets a number of times over the years and each one has its own behaviors which makes writing one single BLE communication library that works for all versions very difficult. For instance, in the latest chipset, if you try to increase throughput by using a mixture of ble characteristic writes with and without response, you can very easily end up in a deadlock situation. It appears the hardware buffer just drops ble packets including those with response if full (which appears to hold 5 packets in the latest 2019 MacBook Pro). Dropping without response packets is fine since they’re expected to be unreliable (and you can build a reliable protocol on top) but they drop the write with response packet which the firmware blocks forever on (you can see this pretty clearly when using a ble packet logger). There’s no timeout and all subsequent packets are queued and never sent. Reliable writes should never be dropped!
Every new MacOS/iOS release is a worrying event. Testing the betas which are super unstable increases the tension because you never know if they’ll fix certain breaking changes. Up until the latest beta, our app did not work on iOS or MacOS until they rolled back some ATS hardening because they didn’t like the certificate pinning style we did of manually evaluating trust (which worked countless versions back).