|
No, I'm not an iPhone user, I just use Apple products only when I need to test if HomeKit is working OK, mostly. For your second questions, HAP is clearly intended for single, stand alone expensive devices with strong WiFi access, totally disregarding the fact that certain constraints could directly hinder performance or reliability in certain circumstances. I think most users would rather prefer having HomeKit supports that works fine 99% of the time than having a certain insignificant or nonsensical feature implemented that butchers the overall performance and responsivity of the device. They also clearly try to shift away the implementation burden from their own internal teams to you, the developer of a much less powerful device. They can afford to do this because they have the upper hand in their relation with the manufacturers (they want to interoperate with their stuff, after all) and it clearly saves them money on developers by simplifying a lot what the Home app/the phone has the do, but it leads to overcomplicated, bloated firmwares that then need to run on meagre specs and very limited platforms (thankfully, the ESP32 exists). This is perhaps the number one reason why HAP-compliant gadgets tend to be more expensive - people that buy iPhones clearly have money to spend, though, so this is less of an issue.
Another big thorn that exacerbates this is the closed nature of the protocol; given that you _must_ support Android, you are also forced to implement a second protocol and keep it and HAP always aligned when anything happens, with all the issues that come from that. I think that Apple likes playing hardball a bit too much, especially since they really like to change specs arbitrarily when they see fit. Every time this happens, the whole certification process needs to start again, even for minuscule changes, forcing your company to pay hefty fees (yes, the Apple tax exists). The overall process is also way too strict, and I know for sure that several companies have cheated in some way or another in order to get their products approved. For example, while studying one of our main competitors HAP-compliant devices already on the market, we noticed that it clearly does not respect some of the most cumbersome fine-print in the HAP specification; in their defence, it must be said that those aforementioned requirements they omitted are incredibly stupid, and clearly they've been devised by by some UX designer that knows nothing of how electronics or software works. Had they followed them it would have made zero difference on their users, because everything works perfectly and those devices have been out for years, while driving up the retail cost considerably. Our theory is that (like others), they must have sent the Apple-designated lab either modified devices or firmware with hacks in in order to pretend to actually implement those nonsensical requirements and then sold different devices on the market. The third party labs Apple usually delegates the whole certification process to generally only care about squeezing as much money as they can from you, so they don't really check if the product on the shelves matches with the one you sent them. I can understand how Apple's approach comes from their intransigent, "screw devs", "user first" culture, but it's clear to me that by being so intransigent they completely miss the point of these gadgets, hindering HomeKit adoption in the process.
For instance, the Alexa's certification process is much less strict than Apple's but as far as I've seen, Amazon-certified gadgets are not qualitatively inferior than MFi-certified ones (it's often the opposite, actually). |