I want to switch to android
I am currently an IOS user, however, as the title suggests, I wish to switch to android. This is because I would prefer to use free software and not be locked into the apple ecosystem. That being said I am already locked into apple and would like to know how anyone else here has managed the switch.
I for one know I will face problems regarding group chats with friends and family on IOS, I will lose out on iCloud+ features, I will have to buy a replacement for my HomePod, I will need to replace apple home, etc.
How did anyone else here who has made such a switch replace or solve these issues?
You are viewing a single comment
We're talking about basic chat functions that reportedly don't work like joining and leaving a chat. How does that break for everyone when there is one Android user around?
I've wrote enough code that other devs have ported to machines I couldn't even think about. If Apple is not able to that I don't know what they do. There is nothing mythical about supporting phone numbers when you implement that and if you leave out that for Android it still does not justificate to obviously break unrelated functions. No one in the world would develop like this.
Apple is breaking compatibility deliberately. They are well-known to do this for hardware and for software.
It's software...these are computable problems, and we can solve them with Turing machines. No one is saying Apple is incapable of porting them. I'm saying that it's work to port them. It's nowhere near just clicking the compile button in Xcode and having it spit out a binary that speaks RCS or runs natively on Android or whatever. That is work for human programmers to sit down at blank editor windows and start building. Can they do that work? Again, obviously, yes they can.
Someone could sit down and make Vim interpret my .emacs file. It's software. Emacs isn't magic, and the Vim programmers aren't stupid. We could make this happen if we wanted to. But it's foolish to say that because it doesn't work today that "Vim is deliberately breaking Emacs compatibility".
If you can't join or leave a chat, that's a bug and they should address it. But that's different than the whole "blue/green bubbles" conversation where people complain about terrible MMS quality and limitations on group chats and all that stuff. Those things happen because Apple currently speaks two protocols: SMS/MMS as a fallback and the iMessage IP protocol as a primary. To solve those problems cross platforms requires a third protocol (RCS), and that's firmly back in "why doesn't Vim interpret my .emacs file" territory.
Please don't mix everything up. We're still talking about the same software on different platforms from one single vendor. Apple won't fix it to avoid competition and try to convince people that Android is bad instead of their very own program.
It's the same software on completely different back ends though.
What specifically do you want Apple to do? Let's take one specific feature -- sending video to an Android user at high quality. What would you tell Apple engineers to do to "fix" that? Because here's how it works today. If you're an Apple programmer, you have two options that exist today to send that video through iMessage. You can write code that leverages the iMessage IP protocol, or you can write code that leverages the MMS protocol. Those are all that exist. Nothing else is "broken", because nothing else exists. If you pick the iMessage protocol, then Android users can't get the message at all, because there's no iMessage for Android. If you pick the MMS protocol, then the video sends in potato quality because MMS doesn't support anything else. In the app today, those are your only two choices. That's all the code that's ever been written in the iMessage app, and you don't have a magic wand to make more code just appear out of thin air to do anything else. So pick one. And we all generally would agree that "potato quality" is better than "never got the message", so it picks MMS.
That's the world that exists right now. You want them to "fix" it. Ok...how? I can throw out the options that I see.
They could implement an iMessage app for Android, put it in the Google Play Store, and have all messages go over the IP data protocol and bypass SMS/MMS completely (for iPhone/Android users at least). The main reason they don't do this is vendor lock in -- I agree with you there, and they've admitted as much in emails that have been surfaced in lawsuits over the years. But let's say they changed their mind and decided to do it. They can't just flip a switch. You can't compile a Swift/Objective-C/UIKit code base into an Android app. You just can't. The platforms don't work that way. There are probably 10 million lines of code in each of those platforms that don't exist on the other one. Your app might, for example, create an array of pictures to be attached to a message. That code, if it were old Objective-C, might have something like
pics = [[NSMutableArray alloc] init];. That's Objective-C calling methods on objects that are defined in libraries. Android apps can't be written in Objective-C. There's no library available on Android that defines anallocmethod on a type calledNSMutableArray. You may as well be trying to run a Perl script in a Python interpreter. Apple would need to write a new app in Kotlin or Java that kind of did the same things that iMessage did. But even then, you want differences. Android has different UI paradigms. Maybe you need a hamburger menu. The "new message" button should be a floating "plus" icon or whatever. You have to write an Android app, not just recompile an iOS app that's written in a language you can't recompile anyway.They could change the existing iMessage code to support RCS as a protocol. That way, Android users still couldn't run the iMessage app itself, but instead of sending potato quality video over MMS, Apple would send decent video over RCS. So what does that look like? Well again, you can't just recompile an app. It's not "fixing" a bug to make this work. This means adding an entirely new protocol, where by "protocol" we mean "implement these 100 or whatever defined message types". Here's the data you write over the socket to tell the cellular provider to deliver this picture. Here's the data you write over the socket to tell the cellular provider to deliver this video. Here's the data you write over the socket to tell the cellular provider to show the receiving user that I'm actively typing right now. Here's the data you write over the socket to tell the cellular provider to tell the recipient that I "Liked" their message. And so on. Each of those things that the messaging app needs to support will have a different way of communicating to some server what the activity was, and Apple has to write all that code.
That's all I'm realistically aware of. They could do other things like replace the entire code base with a web app and that would be cross platform, or they could write an emulation suite that lets UIKit apps run on Android, but they're not going to do those things. These are the options. Both are completely doable, and Apple is making a choice not to do them. Part of that choice surely involves what they perceive as benefits for themselves from lock-in effects. My whole point is that also, neither of them are easy. Both are pretty large software projects that would take a lot of people, money, and time to do. We're not talking about them just refusing to make easy "fixes".