deong

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

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.

There's not much going on here except for familiarity and some gaps in your knowledge of computers as a whole.

As others have said, Gimp saves files in a project file format that preserves things like layers and edits that aren't possible with png or jpg. It's the equivalent of Microsoft Word using .docx vs exporting as PDF. You can't save your Word doc as a PDF, delete the docx file, and then expect to be able to open it back up in Word and continue editing. If someone needs a PDF and you keep sending them docx files because you don't understand the difference, that's an education problem, not a technical one.

Something like zip vs tarballs...you're really only seeing one small part of the world here. "We don't need the user experience to be bad" is actually a good observation, but you don't have a full understanding of what constitutes the user experience. As an example, a tgz file stores Unix file attributes, and zip doesn't. So if I'm not sending the file to a Windows user, zip makes for an incredibly bad user experience. If I zip up a directory full of files with specific owners and permissions, when I unzip it later, I'll have lost that information. If the "default" compression for Linux (and that's kind of not a sensible concept, but let's go with it) were zip, then the vast majority of Linux users would have to exactly what you don't think people should have to do -- go change the defaults after they install applications. Most Linux users don't want there to be a baked in choice that will be wrong half the time. I want to make a zip file to send to Windows and a tarball to use locally, and I want to make that choice consciously based on what problem I'm trying to solve.

I don't know anything about any of these people one way or the other, but if you believe her account and just think the timing is opportunistic, then do you not also believe the part of her account that's in, you know, the bigger more noticeable font at the top that says, "To stop the speculation and DMs I'm receiving...".

As in, "I quit two years ago and didn't say anything about it, but now this is all over the news and a million people keep asking and/or assuming things, so I guess I should address it".

Otherwise Microsoft would never be able to provide Office for macs.

Two points here. First, Microsoft has 220,000 employees. They absolutely could support two completely separate sets of Office apps if they want to, and in fact they did exactly that until 2018. They could support 200 separate code bases if they wanted to. Second, at best you have provided evidence that Microsoft uses some common code for Office, and that evidence is just that Office for Mac exists. iMessage for Android doesn't exist, so there's no such evidence. If I have a million line Windows app that I wish I could make available natively on Linux, but it's all Win32 from top to bottom, you obviously can't tell me that "all modern software requires a common code base and portability" therefore I could easily do it. My code base isn't common or portable, so what Microsoft did doesn't help me any.

But beyond all that, you've just papered over a vast amount of complexity by just declaring it doesn't exist. Most portable apps today are web apps. You can write Electron and it'll probably run on just about any platform. You could write Java and it'll mostly run on any platform. But none of Apple's stuff is either of those things. iMessage is a UIKit app, probably with a boatload of Objective-C behind the scenes and maybe some Swift for the more modern parts. It runs on Macs because of Catalyst, which is emulates the iPad version of UIKit on the Mac. But that's it. There's no UIKit for Android. iMessage simply isn't portable, as far as any of us know. It's just factually nowhere close to true to say "Apple just needs to compile it". The frameworks it's based off of just aren't there. It's exactly like saying that Adobe just needs to compile Photoshop as a KDE app. Photoshop doesn't use Qt or the KDE libraries to do anything. The code just isn't portable. (Full disclosure I guess, I have no idea if Photoshop uses Qt or not, but it's a reasonable illustrative example).

And supporting a protocol isn't just parsing, encoding, and decoding. HTTP is a protocol. So is IMAP. But you can't just write a web browser that uses IMAP. The concepts don't map 1-1 to each other. It's not like for every HTTP action, there's a matching IMAP action. You can't just say, "I'll just use FETCH instead of GET and everything will be great". HTTP has redirects, for example. How are you going to make redirects work over IMAP? In the case of iMessage vs RCS, for example, iMessage has the ability to message someone without a phone number. RCS doesn't. There's literally nothing in the RCS protocol that makes that possible. So what do you want this mythical compiler to do when you tell it to compile iMessage for Android and use RCS? Should it just core dump if you try to message an email address?

https://pi.math.cornell.edu/~mec/2003-2004/cryptography/diffiehellman/diffiehellman.html

Sure, but one of those things is fixing a bug in the protocol they already use for core functionality, and the other is an entirely new software development project. Adding RCS support to iMessage is adding support for an entirely new protocol. That's what I'm getting at here. It's not "broken". Apple doesn't have to "fix" RCS support. They have to build RCS support, from scratch.

This is like saying that Microsoft Windows should be able to run programs compiled for Apple Silicon on Mac OS. That might be a cool feature, and I have no problem with someone saying they think it should happen, but it's not Microsoft being "evil" or refusing to "fix it".

RCS is not completely compatible. For one thing, it requires a carrier and a phone number. You can go out today, buy a Mac or an iPad with no cell modem, and start using iMessage purely as an IP messaging app. So they can't just replace the existing protocol with RCS, because RCS is a bag of flaming shit. They could spend the money to develop RCS fallback in addition to their protocol, and that would be awesome, but it costs them money, and I get why they don't want to do it.

The reality is that this is Google's fault more than anything. They spent half of my adult life repeatedly inventing and then fucking up the act of sending 200 bytes of text to one person at a time.

I'd love for the modern world to have a great way of messaging people that just worked -- used IP connections with SMS fallback, a login you could manage from anywhere, full support for all the real-time typing stuff, the rich media support, the whole thing. That would be great. Someone get on that. But if I have to listen to fucking Google whine about it one more time, I'm out. They're like a guy with one finger left. If you didn't know any better, you'd feel pretty sympathetic for him. But if you've spent the past two watching him slowly chop the other nine off one at a time with a hatchet and then whine about his bad luck for 12 hours after each chop, the sympathy starts to ebb a bit.

They're not deliberately breaking it -- they just don't support it. "Deliberately breaking" has the connotation that it would have worked just fine, except they took some extra action to stop it. That's not true here. It would only work the way people want it to work if Apple spent a lot of money paying developers to make it work.

They chose to not create an Android client for iMessage to preserve the lock-in effect and keep people on iPhones.

There's a separate conversation around how well the existing Apple clients interoperate with non-Apple clients. And I think that is a mix of preserving lock-in effects, but also just not wanting to spend the money on developing things they don't care that much about. RCS is a shit protocol, and Apple doesn't really gain anything from supporting it, so they don't. It might be part of that decision that they don't want using Android with iPhone friends to be more pleasant, but it can also just be that they don't care enough to spend the money to do it.

It does matter. Take iMessage. It's cross platform enough for most people. You can text an Android-using friend and they can text you back. There are annoying limitations, but if you use a Mac, having the same messages available on your computer while you're sitting at your desk at work is a feature that you may use, and if so, that feature is probably more important to you than whether you can directly share a video clip at full quality versus having to share a link or whatever.

yeah, the smart teenager is going to be charging the adults in his life $50 to get their porn working again.