Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What is currently not interoperable between the majors mobile OS makers?


Well messaging for one thing...

Some others:

- Find my device features including Bluetooth ping networking (airtags, Tile, Android's upcoming network)

- Airdrop/Nearby Share

- Bluetooth LE proximity pairing (at least I doubt this works when pairing cross ecosystem)

- Carplay/Android Auto

- Airplay/Google Cast


> Find My / Airtags

Another Apple ecosystem that can be used by non-Apple devices. OpenHaystack [0] has been working well for quite a while.

[0] https://github.com/seemoo-lab/openhaystack


See my comment below for why this isn't the interoperability I'm interested in. I don't want to use Apple's service, I want Bluetooth tag pinging to be standard across Apple, Tile, and Android ecosystem devices so that they all work equally well regardless of the percentage of one brand of phone or another in the area the tag is pinging from.


Is there a way to SEE the location of my Apple manufactured Airtags from Android?


Does this still work? that repository appears to be abandoned.


Apple did actually open up the network, there are plenty of third party devices that are 'Find My' compatible. It's intended for integration into things like bikes or scooters.

You can buy tags from AliExpress for $5 that implement it. I've been using a few for a couple of months, and no issues so far.


It would be preferable if Find My capable smart devices could forward tag pings on to non-Apple owners and vice versa. Right now, Find My is strong in the US where iPhones are very common, but it works worse in places where most phones are Android, and vice versa for Androids in the US versus abroad.

You are referring to being able to track devices via the Find My portal on Apple.com or your Apple devices, but I am referring to being able to merge the networks so that Apple devices will forward pings onto Android's Find My network and vice versa.


> that repository appears to be abandoned

The last commit and release is from october.


- Carplay/Android Auto

Are there any headunits that only support one or the other? The cheap Chinese unit I got last year supports wireless for both. It would be nice to have an open protocol though, so third parties could develop alternative UIs.


Or so that there isn't a duopoly lock in for a new phone OS or an android fork that doesn't have Google Play Services on it. Just like Google Cast and Airplay, this should be an open standard, not a pair of incompatible proprietary locked down solutions.


Sadly, yeah- even in OEM units.


okay but this "interoperability" is legitimately hard without degrading the user experience because apple's unique level of control allows it to produce a superior product with more consistency. airdrop is best-in-class; open-source solutions like wi-fi direct are dumpsterfires with trash UX. LE proximity pairing is, i believe, a custom chip apple put in airpods (h1 chip) because bluetooth is stuck in 2005 and still doesn't have easy pairing, full quality two-way audio, etc. carplay/auto have different feature sets and airplay is an objectively easier experience than google cast.

the EU is fundamentally interested in these changes regardless of consumer welfare. this is sour grapes because they fail at tech by every conceivable metric and by degrading everything to a common feature set and commoditizing certain standards, they hope to give domestic companies a prayer. that it prevents innovation and improvements is merely a secondary concern for the hard-headed anti-Americans in brussels.


> apple's unique level of control allows it to produce a superior product with more consistency

Another way to read this: Apple has a superior product because they perform anti-competitive practices and don't allow other companies to out-product them. And when they do, they buy them/shut them down before anyone is the wiser.


editorialization. you know as well as anyone that restricting your feature development to your own platform rather than doing a retarded design by committee helps one innovate faster.


We don't need to speculate; internal emails from the Epic trial discuss the motivations.

https://www.theverge.com/2021/4/27/22406303/imessage-android...

In short, Eddy Cue proposed in 2013 that Apple owning the best-in-class messaging app would be a win, and even mentioned the cost being low. Phil Schiller shut him down, arguing it would remove a barrier preventing iPhone parents from buying their kids Android phones.

That reads like anti-competitive motivation to me. In particular, it looks like tying, where two unrelated products are connected artificially. The wikipedia article on anticompetitive behaviors has a section on tying, and mentions another case involving Apple that bears some resemblance involving iPods being artificially restricted to only playing tracks either from iTunes or direct CD rips.

So I think the anti-competitive angle has some real merit.

The innovation claim, though, I have a harder time with. I don't see how releasing Messages for Android implies design-by-committee. They could just release it, like Beeper Mini just did, but without the reverse engineering part.


They could definitely just release an app for Android instead of opening the protocol, but as an Android user I'd reject it for the same reason I reject my Apple friends suggesting we all use WhatsApp or Signal: I don't want different conversations living in different chat apps for no reason. That to me is the bad old days of Facebook Messenger+Twitter DMs+SMS where I had to remember which platform each of my contacts prefers to use and then deal with missing features and an inconsistent experience all the time.

As much as I think Beeper's work on iMessage is important, apps like that do not and have never solved this problem. Because then you have different contact identifiers to contend with, the inability to make groups amongst those users, differing features, and the list goes on.

If you look closely at what I'm saying here, it's easy to compare it to what iMessage users say about why Android users create problems for them, and that's true. That's why messaging interoperability is important.


Interestingly enough, in my life, WhatsApp has just won. Everyone I know uses it, people I meet when traveling use it. Pretty much every Airbnb host tries to contact me on WhatsApp. My physio right now in Malaysia organizes all my appointments on WhatsApp. But I only travel East of the UK, so Europe/Afria/Asia, I have no idea what South America is like, and can guess that it's not as ubiquitous in North America based on these threads.

I cannot remember the last time I've received a non-spam SMS. The whole iMessage thing feels so alien to me. My girlfriend is an Apple fan-girl and has never used iMessage in her life. I kinda wanted to see what was special about it and when I asked her about it, she had no idea what I was talking about.


Lack of competition has actually been shown to reduce innovation, not increase it. No one is asking them to do feature dev or even support for other platforms. They are asking them not to _shut out_ other platforms if others want to do the work.


Innovation is a good thing, but for many items on this list there's no more innovation happening. Google Cast and Airplay have been mostly unchanged for the last ten years, and the same is true for Airdrop and Nearby Share.

You can definitely make the argument about innovation in the messaging space, but RCS is very extensible. RCS Encryption definitely needs to be standardized, but I recommend you check out how Google layered it on top of RCS [1] including handling fallbacks for corner cases like switching your RCS client away from Google Messages before the system realizes it.

This is to say that RCS is pretty flexible, the key is handling the fallback paths in the extension design and working with other vendors to standardize promptly, so we don't end up with the same kind of broken mess that the carriers made.

[1] https://www.gstatic.com/messages/papers/messages_e2ee.pdf


> apple's unique level of control allows it to produce a superior product with more consistency

Honestly, this reads more like marketing spin to cover anti-competitive behaviour than a forum post.


i am not, nor have i ever been, employed by apple. i use none of their products as my primary devices. stop breaking the forum rules.


Have you used Nearby Share on Android? It's IME just as good Airdrop, the only real issue is that it's not baked into Windows PCs like Airdrop is with Macs (confusingly MS has their own thing called Nearby Share for Windows devices). I've actually had less issues with Nearby Share, my iPhone stopped sharing to my mini after a few months but could talk to everything else. Android solved BT pairing in a superior way years before with NFC pairing. Touch two things and paired. I could get my airpods to pop up on my iPhone 1/10 times. Finnicky, overhyped crap IMO. Only reason NFC pairing didn't catch on is Apple holding the NFC chip hostage for the sole use of Apple Pay.


yes, i primarily use an android phone. nearby share is janky and terrible. additionally, the fact that it's not built in everywhere is a ding from the standpoint of an end user.


It is built in to the Share dialog, so it is accessible anywhere the Share dialog is shown. And when you copy something to clipboard, the popup at the bottom includes Nearby Share. Where else would you like to see it?

Certainly not every iOS app has a custom Airdrop integration either.

Every time I've nearby shared it's worked just fine. What phone do you have?


It's really not. Just make the "superior product" interoperable.


But it often not that simple, anyone who has done cross-platform development can tell you this by heart, it doesn't matter what you do, you must adhere to the lowest common denominator. Interoperability isn't free.


I'm not asking them to implement these things on every platform, but it's not difficult to make documentation they certainly already have about protocols available.


Protocols calcify when you don't control all the endpoints, consider the case in point, iMessage, it is seems like there is some security implications for spoofing iMessage for any random number, yet, apple's recourse is very limited if it can't update all the endpoints (devices).

The same is also true, say about AirDrop, if apple makes it "Open" and they have to make a breaking change for security or whatever reason, they can't feasibly even make an update available for non-apple devices let alone enforce it.

Now "Apple" has broken your non-apple device and along with it their reputation.

Open is good, but the cost is non-zero.


By that logic the Outlook for Windows team should be responsible for patching Gmail for Android.

This argument is silly. You could use this line of reasoning to justify why all computers should use the same OS from the same vendor. Of course then you'd have a monoculture where implementation bugs that cause vulnerabilities are universally exploitable, instead of only exploitable on machines running that vendor's software.


This isn’t uncommon at all when dealing with development that requires interoperability.

Far from it, actually.

If a part of your user base uses another service, you’ll inevitably have to add workarounds specifically to cater to users for that service. It’s just a fact of life when multiple groups have to implement a spec. If you aren’t willing to add workarounds, users will think your software is broken when they should be blaming someone else.

For example, Firefox maintains a few workarounds for websites that ship in the browser. They aren’t the web developers responsible for the sites but someone has to make it work.

Interoperability is not free.


Not free, but worth it for messaging to solve the real pain points that iMessage and Google Messages users deal with while trying to communicate across the aisle.


You're free to make value judgments, but for a business to follow through, the economics of it must be sensible. As a consumer, I prefer a secure messaging platform over an open one any day of the week.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: