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.

1. 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 an alloc method on a type called NSMutableArray. 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.

2. 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".