I worked on integrating a Nordic Bluetooth chip into a smartwatch, it was a nightmare. Some of the problems I encountered:
* the SDK kept changing, not just in minor ways but drastically. My suspicion was that this was so customers would hire Nordic to implement their drivers.
* The hardware kept changing. The chips would go out of production on the order of months or a year. Get your design working, go to order the parts, and the chips are no longer available (and the new chips use the new SDK so you have to rewrite the firmware).
* The Nordic API was nothing like the Bluetooth API, it was a wrapper around it, designed to make creating apps/drivers "simpler". But that means a lot of the Bluetooth documentation is useless to you, you have to translate it to the Nordic API. It also locks your software into one chip design.
* The firmware on the chip changes at will. There is no guarantee it will behave the same when you upgrade it. You only have access to the wrapper source code, not the source code of the stack that runs on the radio MCU.
I spent two years working on what should have been a project of a few months (I previously integrated an ANT+ radio with the smartwatch and it was dead simple.) One thought I had was that Bluetooth was designed to be a barrier to entry. It's become the default on phones and ANT+ doesn't have the market penetration, so if you can't make your gadget or phone support Bluetooth, your product is not marketable. The complexity is there to keep the smaller players out. The spec manuals are like 1500 pages long!
All of this means that many Bluetooth implementations and drivers are faulty because the developers can't spend the time to fully understand what they are doing. Larger companies can afford to hire the Nordic developers to write their drivers.
* the SDK kept changing, not just in minor ways but drastically. My suspicion was that this was so customers would hire Nordic to implement their drivers.
* The hardware kept changing. The chips would go out of production on the order of months or a year. Get your design working, go to order the parts, and the chips are no longer available (and the new chips use the new SDK so you have to rewrite the firmware).
* The Nordic API was nothing like the Bluetooth API, it was a wrapper around it, designed to make creating apps/drivers "simpler". But that means a lot of the Bluetooth documentation is useless to you, you have to translate it to the Nordic API. It also locks your software into one chip design.
* The firmware on the chip changes at will. There is no guarantee it will behave the same when you upgrade it. You only have access to the wrapper source code, not the source code of the stack that runs on the radio MCU.
I spent two years working on what should have been a project of a few months (I previously integrated an ANT+ radio with the smartwatch and it was dead simple.) One thought I had was that Bluetooth was designed to be a barrier to entry. It's become the default on phones and ANT+ doesn't have the market penetration, so if you can't make your gadget or phone support Bluetooth, your product is not marketable. The complexity is there to keep the smaller players out. The spec manuals are like 1500 pages long!
All of this means that many Bluetooth implementations and drivers are faulty because the developers can't spend the time to fully understand what they are doing. Larger companies can afford to hire the Nordic developers to write their drivers.