Did you ever get a response? I'm still finding the same behaoivr, 5 years later.

Seeing the same thing on watchOS 6.2.6

I tested this again today on the first developer beta of watchOS 7 and it now works without any modifications to the code that was failing before. Perhaps the upgrade process changed my configuration, though on watchOS 6 I tried multiple times to erase and restore my Watch without ever having success with this code. Or, perhaps Apple fixed/changed something in HomeKit on watchOS 7?

And in answer to the Frameworks Engineer, my app is a Watch-only app.

Got it, thank you for the helpful reply! The behavior you describe makes sense, but has unfortunate side effects given that the docs have always instructed developers to check supportsHaptics before attempting a call to Core Haptics: By checking for haptic support early using supportsHaptics, you can set a global Boolean that your view controllers can quickly consult before deciding to play a haptic. If this variable is set to false, then the app can proceed without even attempting a call to Core Haptics. For an example of conditioning haptic playback on this global Boolean, see Playing a Custom Haptic Pattern from a File. Based on whether or not the user’s device supports haptics, your app can decide to use a different codepath, with stronger audio or other multimedia alternatives for feedback. It would seem that many games are following this advice, as I have tried several where haptics work on a controller paired on iPhone but none that work with a controller paired on iPad.

Curiously, this issue does not reproduce on an M1 MacBook Air. It seems that the issue might be specific to the Bluetooth stack for intel Macs.