Look at something like Active Directory that is in theory ldap.
Do you really want to mix AD and open LDAP? You can, and it's a massive pain in the ass. Now you have apple iWatch apps talking to android. Where does apple maintain the translation layer? Does google/samsung take a "fuck off" stance and lock them out? What does the user experience look like when the "bug" in the app is on android and your CALLING apple for support...
I think that last bit is the limit that folks dont really think about. You can call apple, show up at store and they are going to try to fix your issue... when your random android device breaks who do you call?
"the technical limitations" are "we cant control android" and "does not fit our customer support philosophy"
Nah. Garmin smartwatches work fine with Android phones. Apple could have just done the same, regardless of what Samsung or Google wants. Platform boundaries aren't a legitimate concern in this space.
Except that anyone who has tried to build custom apps for Garmin, knows that the ecosystem is a mess. Monkey C, just isn't good. Their API's are unstable, data transfers from apps on the watch to a phone are problematic at best.
Sure apple could have likely brought the baseline functionality of Apple watch to Android, however apps would have likely been much much more complicated, and are a key part of apple watch.
If anyone involved in it could explain to me why they chose to force an OO language on people on a platform where some targets have so little memory that you’ll find yourself cutting lines of code to save memory used by the code itself, not even when it’s executing, thus throwing away a bunch of bytes supporting objects when there’s not enough space to even really take advantage of inheritance—I’d love to know the story. It’s such a weird choice.
Maybe there are the same people that invented Javacards. Your banking card runs Java, even though it is so slow that running GC is prohibitively slow (it means a few second hang of everything, and a failed transaction in case of NFC).
There is nothing that would stop existing Apple Watch apps from continuing to work if the device was paired with an Android phone. In cases where the Watch app depends on a matching iPhone app then obviously the developer would have to build an equivalent Android app to make it work, but no one is proposing that Apple would have to do that themselves.
As for issues with the Garmin ecosystem, that's totally irrelevant. The basic fact is that nothing is stopping third-party smartwatch vendors from building good integration with Android phones. Garmin is just one example. Others such as Suunto and Coros have done the same thing. There are no significant technical obstacles.
As an Apple Watch user, I find this very funny, because data transfer between an iPhone and an Apple Watch is pretty bad too. In no small ways because of Apple insistence on slow wireless solutions with custom opaque APIs.
So, Garmin may be bad but at least they are a lot cheaper and work with more things. At any given price point, they are a lot better as sports watches too.
Anyway, I stopped caring because there is no real compelling use case for a smartwatch, my next one will be a sport watch from Garmin or another competitor. Problem solved.
Look at something like Active Directory that is in theory ldap.
Do you really want to mix AD and open LDAP? You can, and it's a massive pain in the ass. Now you have apple iWatch apps talking to android. Where does apple maintain the translation layer? Does google/samsung take a "fuck off" stance and lock them out? What does the user experience look like when the "bug" in the app is on android and your CALLING apple for support...
I think that last bit is the limit that folks dont really think about. You can call apple, show up at store and they are going to try to fix your issue... when your random android device breaks who do you call?
"the technical limitations" are "we cant control android" and "does not fit our customer support philosophy"