3 ms·

Doesn't Google offer interoperability for the equivalent features in Android? (well maybe not private symbols in the closed source parts). So I don't see why it

Doesn't Google offer interoperability for the equivalent features in Android? (well maybe not private symbols in the closed source parts). So I don't see why it should be a big problem for Apple to comply. Except of course that it will weaken the lock-in in their platform, but that's kind of the point.

bri3d 2y ago
It's fascinating to me that people have a mis-conception that Google are universally more open about these features, and therefore things will be easy for Apple. I do think they're more open, but the equivalent features are absolutely not "just standardized protocols" on the Google side. Because they're hard engineering problems to make into open protocols! * Bluetooth auto-pairing: Google Fast Pair is a "regulated standard" type interoperability where Google act as a regulatory body and there's extensive certification testing. * AirDrop: Samsung Quick Share (totally proprietary) got combined into Google Quick Share which is semi-proprietary: the protocol documentation isn't open, and there's no first-party MacOS or Linux client support, only reverse engineered stuff - just like AirDrop! But, pieces are hiding in the Chromium source tree and an unofficial Google project called "nearby." Actually, the state of this is really strange to me, honestly; Google try to claim it's both not a Google product and a flagship Android feature at the same time. * AirPlay: Not really, Google Cast supports more devices so people feel it's more open, but it works the same way as AirPlay - for access as a device sink, you enter a "business agreement" with Google and get a blob and a certificate, or reverse engineer it. * Device handoff: I don't know of anyone else who has as extensive an out-of-band device-state signaling system as Apple. Microsoft Phone Link tries but Android doesn't really expose some features at a low enough level for it to be 1:1 with what Apple have done either. There is again, notionally, some aspect of this in "Google Nearby Presence," which is in this not-a-Google-product Google product superposition. * Notifications and background tasks. In this space Android is definitely and provably more interoperable, at the cost that background tasks can spam you and wreak havoc on your device. This will be the hardest thing for Apple IMO; right now, their internal background task and notification sync capability revolves around internal trust and QA, and to expose it externally without degrading user experience will require quite a bit of engineering lift IMO.
- seec 2y ago
  The point is that you can do those things, even if they are not as easy as you wish or require more investment than thought. In the case of Apple, you cannot, regardless of how much you want to invest in supporting those features. Nobody is asking Apple to fund the development of other companies; however, it is required of them that they let access to those functionalities to other companies, fairly. If Apple had a more open system where they would let their customers decide what to run and what to install on their phone, the problem wouldn't even exist. With jailbreaking you could potentially implement all of this (basically just put support for the Android version and voila) but it's illegal and user can't do that easily. The problem is Apple want their cake and eat it too. It's like with power and responsibility, the more of the first you get the more of the second you have, that's pretty much it. So, they can choose to keep their system completely closed and provide a way for competitors to access those features or they can choose to fully open up. Of course they are going to choose the first option, because they are still making a shit ton of money by fully controlling the system allowing them to have software/services that nobody can compete with.

bri3d 2y ago

It's fascinating to me that people have a mis-conception that Google are universally more open about these features, and therefore things will be easy for Apple. I do think they're more open, but the equivalent features are absolutely not "just standardized protocols" on the Google side. Because they're hard engineering problems to make into open protocols! * Bluetooth auto-pairing: Google Fast Pair is a "regulated standard" type interoperability where Google act as a regulatory body and there's extensive certification testing. * AirDrop: Samsung Quick Share (totally proprietary) got combined into Google Quick Share which is semi-proprietary: the protocol documentation isn't open, and there's no first-party MacOS or Linux client support, only reverse engineered stuff - just like AirDrop! But, pieces are hiding in the Chromium source tree and an unofficial Google project called "nearby." Actually, the state of this is really strange to me, honestly; Google try to claim it's both not a Google product and a flagship Android feature at the same time. * AirPlay: Not really, Google Cast supports more devices so people feel it's more open, but it works the same way as AirPlay - for access as a device sink, you enter a "business agreement" with Google and get a blob and a certificate, or reverse engineer it. * Device handoff: I don't know of anyone else who has as extensive an out-of-band device-state signaling system as Apple. Microsoft Phone Link tries but Android doesn't really expose some features at a low enough level for it to be 1:1 with what Apple have done either. There is again, notionally, some aspect of this in "Google Nearby Presence," which is in this not-a-Google-product Google product superposition. * Notifications and background tasks. In this space Android is definitely and provably more interoperable, at the cost that background tasks can spam you and wreak havoc on your device. This will be the hardest thing for Apple IMO; right now, their internal background task and notification sync capability revolves around internal trust and QA, and to expose it externally without degrading user experience will require quite a bit of engineering lift IMO.

seec 2y ago
The point is that you can do those things, even if they are not as easy as you wish or require more investment than thought. In the case of Apple, you cannot, regardless of how much you want to invest in supporting those features. Nobody is asking Apple to fund the development of other companies; however, it is required of them that they let access to those functionalities to other companies, fairly. If Apple had a more open system where they would let their customers decide what to run and what to install on their phone, the problem wouldn't even exist. With jailbreaking you could potentially implement all of this (basically just put support for the Android version and voila) but it's illegal and user can't do that easily. The problem is Apple want their cake and eat it too. It's like with power and responsibility, the more of the first you get the more of the second you have, that's pretty much it. So, they can choose to keep their system completely closed and provide a way for competitors to access those features or they can choose to fully open up. Of course they are going to choose the first option, because they are still making a shit ton of money by fully controlling the system allowing them to have software/services that nobody can compete with.