I suppose the question I'm asking here is if macOS Sonoma prevents the macOS device from advertising as a keyboard peripheral. Furthermore, is there any documentation that describes these limitations.
I'm not aware of any such limitation and are existing apps that do exactly what you're describing.
However, I'm also not at all surprised that you're having issues like this:
I've found an example of how to implement the Bluetooth service (from macOS Mojave but updated to Swift 5). The code will build without issue and asks for the necessary permissions in settings. After giving permissions and rebuilding, the peripheral simply does not appear on the iPhone Bluetooth settings menu (or the Bluetooth settings menu of any device).
The Bluetooth APIs are poorly documented and tricky to use, which leaves plenty of space for mistakes. Similarly, our devices show you "the devices which look like the system will work with them", not "every bluetooth device the radio can see". It's entirely possible to have all of the "infrastructure" setup correctly and have the device fail to appear because "something" about the device configuration causes it to be ignored.
It isn't really practical for me to try and diagnose your code, but I do have a few suggestions:
-Forget pairing with iOS for the moment and focus on pairing between two macs (or windows/linux, etc.). It's likely that iOS will "just work" once the mac is working and it's far easier to see what's happening on a mac than iOS.
-Focus on exactly what stage you're at in the process and what that tell you about your code. Case in point, the issue is almost certainly with SDP configuration, advertisment, or "basic" configuration, NOT L2CAP. The other side isn't "seeing" your device and it doesn't really mess with L2CAP until after pairing has occurred.
-You may want to take a look "PacketLogger.app", which you can find inside our "Additional Tools for Xcode <version>" download. That acts like a basic bluetooth packet analyzer, which may give you some hint about what's actually going wrong. Note that the Additional Tools download is generated by our build process. Generally speaking, the tools themselves aren't actually tied to any Xcode version and many of them haven't changed in a VERY long time. You don't really need to worry about getting the "right" download version.
-If you're new to this kind of development slow down, focus on every detail, test everything, and don't assume ANYTHING. From long experience, a big part of what makes this kind of development hard is that every mistake you make looks EXACTLY the same- "it doesn't work". My rule of thumb for driver development is that it always takes about at LEAST 2 days to ACTUALLY get a basic driver loading and matching. Not DOING anything, JUST matching and loading. That sounds ridiculous and silly... but it's also been true of every driver I've written. The process is finicky and with lots of details that are easy to misunderstand or overlook. Even when you "know what you're doing", you'll always miss SOMETHING and find it will ALWAYS take more time than it "should".
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
