Apple’s ideology behind not expanding iMessage to other platforms has been - at least in part - due to the security of the iMessage platform and how it authorizes senders and recipients (like many encrypted services on Apple devices, tokens are encrypted/decrypted in the Secure Enclave on the SoC). Apparently, Apple has low confidence in the diaspora of Android devices and just decided to forget even trying to create a client for Android it could tie down to hardware authentication due to not having a reliable hardware base. This was many years ago.
I don’t know if this is still true or even necessary today, or if they’ve even bothered to explore it recently, but that’s Apple’s main issue. Sure, it also benefits them in other ways such as driving users to their platforms, but this is their main issue.
Clearly they also saw the benefits of keeping it to Apples platforms, but that doesn’t remove the technical limitations, at least, early on.
Like I said, I don’t know if those limitations still exist. Clearly, the profit motive would if it weren’t for all of the legal and regulatory liabilities that exist abroad. This is why I suggested in another comment that purchasing and integrating this compatibility layer would be a good workaround for them in that regard.
The limitation was added after the fact anyway, like I mentioned in my edit, secure enclave wasn’t added until the A7 chip, which was first used in the iPhone 5S in 2013, two years after iMessage became available.
It’s really not necessary though, it’s just a justification after the fact. There are several secure e2e apps available without utilizing a special chip to house that data, even Google has e2e with their RCS implementation
Apple’s ideology behind not expanding iMessage to other platforms has been - at least in part - due to the security of the iMessage platform and how it authorizes senders and recipients (like many encrypted services on Apple devices, tokens are encrypted/decrypted in the Secure Enclave on the SoC). Apparently, Apple has low confidence in the diaspora of Android devices and just decided to forget even trying to create a client for Android it could tie down to hardware authentication due to not having a reliable hardware base. This was many years ago.
I don’t know if this is still true or even necessary today, or if they’ve even bothered to explore it recently, but that’s Apple’s main issue. Sure, it also benefits them in other ways such as driving users to their platforms, but this is their main issue.
Not according to the leaked emails… https://x.com/TechEmails/status/1589450766506692609?s=20
Also, the secure enclave wasn’t added until the iPhone 5s in 2013, whereas iMessage had already existed as of 2011.
Clearly they also saw the benefits of keeping it to Apples platforms, but that doesn’t remove the technical limitations, at least, early on.
Like I said, I don’t know if those limitations still exist. Clearly, the profit motive would if it weren’t for all of the legal and regulatory liabilities that exist abroad. This is why I suggested in another comment that purchasing and integrating this compatibility layer would be a good workaround for them in that regard.
The limitation was added after the fact anyway, like I mentioned in my edit, secure enclave wasn’t added until the A7 chip, which was first used in the iPhone 5S in 2013, two years after iMessage became available.
Although true, it was added to make iMessage (and every other service) more secure, not just as some sneaky way to keep iMessages off android devices.
It’s really not necessary though, it’s just a justification after the fact. There are several secure e2e apps available without utilizing a special chip to house that data, even Google has e2e with their RCS implementation