Yes, I am already considering it, but it has various limitations, which I would like to avoid.

It’s not about the size of the stacks IMO, the Bluetooth stack is notoriously difficult to interact with since the implementation varies wildly across different platforms and maybe architectures, and communicating with those different stacks is difficult, in a way. And within each stack you may find many features that are sparsely or not documented at all.

Just saying, but if it were easy, cross-platform libraries would have been developed long ago, but to this day most libraries have implementations where some functions are either finicky or not implemented. In no way am I trying to criticize the authors of those libraries, IMO it is a commendable achievement that they have understood the standard and the different stacks and have attempted make it cross-platform friendly and easy-to-use, but that’s just the state of Bluetooth these days.

I would like to be involved in the development as much as I can, but I cannot work on rust since I have no experience with it, unlike with Go and Java (a little). Also, cross-platform libraries tend to have more limitations and caveats as to what is implemented and usable. But please, do link the rust library here so I can check it out.

I think platform specific binaries is the way due to more flexibility, although we can debate about that. My objectives are to provide a standard API for any bluetooth client to use, and to retain bluetuith’s existing features. If you are willing to contribute to the MacOS part of it, it would be great, and we can have further discussions via DM.

Windows is indeed a different beast, which is why I am looking for contributors. For Linux it can be done, but since I don’t have a macOS based device, I cannot work on a macOS based implementation.

Haha, I noticed that and edited it out. I had posted this to Reddit as well, and I copy-pasted it here.

You have quite an interesting situation here. You could use a good Bluetooth adapter, pair all your devices to it, and maybe use pulseaudio/pipewire (depending on what your system uses) to manage audio inputs/outputs?