Confused by what is allowed for System Level Apple Watch Bluetooth Connection. Does it require MFi or are there only some BLE chips allowed?

On the Apple MFi Page it only mentions iOS: From Apple MFi Page: :: Who does NOT need to join

Note that the term "not need" there can be somewhat misleading. For all of the technical cases on that list, the reason you "don't need to join" is that the MFi program simply is not involved with that particular accessory type/technology, so there simply isn't any reason to join.

Does this apply to WatchOS as well?

Yes.

No need for MFi application and also no need to worry about which BLE chip is used?

Correct. More specifically, the MFi program does not have a licensing program for "general"* Bluetooth Low Energy Accessories.

*There are specific BLE technologies like iBeacon which are licensed, but none of those apply here.

So, if I am making an BLE device that is Activity Based, and has one of the allowable Health Device UUIDs, is the BLE System Connection allowed using any BLE chip?

Sure? I haven't tested that specific area in any great detail, but the basic answer is that you're allowed to do whatever the system allows you to do. That is, we don't have any specific licensing or certification program for BLE accessories, we simply provide APIs that apps can use to communicate with BLE accessories.

Having said that, I would STRONGLY recommend that you review and follow the guidance in "Accessory Design Guidelines for Apple Devices", particularly around specific technical details like advertising interval* and connection parameter. A large percentage of BLE issues we see are simply that a particular accessory does not work particularly well because it did not follow the guidance in that document. There isn't any mechanism that "forces" your accessory to follow that guidance, but it shouldn't be surprising that accessories which ignore our guidance don't actually work very well.

*I mention advertising interval in particular because a surprising number of accessories choose to invent their own intervals despite us having provided a list of exactly what advertising intervals should be used.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you so much for your response and clarifying matters

One more question if you don't mind

I am able to create a BLE device that advertises itself as a Bluetooth SIG Service UUID such as: 180D - Heart Rate

However, a different type would make much more sense for the product: 1826 - Fitness Machine

Using that Service UUID does not show up under WatchOS > System Settings > Bluetooth

Is there a reason only some Bluetooth SIGs Service UUIDs are allowed and some are not?

A couple of WWDC videos say if this type of System Settings BLE connection is made on the Apple Watch, versus at the App level, the connection is more reliable, is able to connect in the background, and gets data sent more frequently. If our product though makes more sense under an Bluetooth SIG like 0x1826 how can I make that type of connection?

Note: I'll make sure the guidelines are followed. Thanks for the link

Is there a reason only some Bluetooth SIGs Service UUIDs are allowed and some are not?

Yes. This setting isn't intended to simply be a "make bluetooth better" button. It's there for specific health related devices were the "best possible" performance is particularly important. Often that's because it's a sensor where delay could be dangerous or life threatening*.

*Keep in mind here that our ability to screen devices is limited, so that fact that a basic fitness heart monitor appears in a section like this doesn't mean that we actually built this feature for THAT particular device.

Moving to here:

A couple of WWDC videos say if this type of System Settings BLE connection is made on the Apple Watch, versus at the App level, the connection is more reliable, is able to connect in the background, and gets data sent more frequently.

Keep in mind that this can both be true, and not all that relavent to your app/use case. There are lots of APIs involved here and the combination of what you're trying to build is what matters, not the specific details. For example, I believe the workout system would end up escalating your priority HIGHER than the system setting would, so if you app is implementing a workout session (which would be typical for "Fitness Machine") none of that matters.

Secondly, what's actually happening here is that the system is directly collecting the data and adding into HealthKit without the apps involvement. In other words what you're actually asking here:

If our product though makes more sense under an Bluetooth SIG like 0x1826 how can I make that type of connection?

...is for HealthKit to directly integrate that particular service, not simply "escalate" how that service is handled.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware