The answer is that the carriers worked out a specification and both infra-vendors and device-vendors were left to develop the server/client based on that spec.
So each major device-vendor developed his client-app, and ended up with interoperability issues not only with the RCS-servers used by a given carrier, but also with devices of OTHER vendors. And that doesn't even begin to cover the issues on inter-carrier messaging...
The situation was only resolved after Google acquired Jibe Mobile (the biggest player in developing RCS server/client applications for carriers) and basically created a single RCS-client/server implementation using their Android Messages app and a Google-owned server.
But when you were working on RCS back in 2012, you may remember that at that time, RCS didn't even support store&forward (!!).
So if the receiving device was not available when a message was delivered (because it had no network or client wasn't running on a device, which happened alot especially on iOS because the client was in a constant fight with the OS), the message wasn't queued anywhere.
Apart from the obvious issue of missing messages, it caused the even worse UX-impact that the entire conversation looked different on sender/receiver.
--
Ah yes, and: RCS was originally designed with per-message billing in mind (of course). At the time it was launched it was finally clear to the carriers that those times are over, but the whole architecture had quite a chunk of billing architecture in it as well...
> The situation was only resolved after Google acquired Jibe Mobile (the biggest player in developing RCS server/client applications for carriers) and basically created a single RCS-client/server implementation using their Android Messages app and a Google-owned server.
Thank you for highlighting this. This important piece of information often gets lost in the "green bubble" discussion.
Google has significant incentives for pushing RCS for more than one reason.
Agreed. I hate that we pretend Google is somehow altruistic with their support of RCS. They have many, many incentives and pretending otherwise is naive and obtuse.
> They have many, many incentives and pretending otherwise is naive and obtuse.
Okay. The main incentive is to create a competitive method for messaging which allows rich communication with everyone, regardless of platform or ecosystem just via their phone number.
Running a messaging gateway means Google gets all that sweet metadata at the very least and message content in the many cases where E2EE isn't enabled. That's a lot of data to build advertising derivatives all linked to a specific identity.
In best case for Google they can operate the RCS-server for Android devices. Google already owns the Messaging CLIENT for SMS/MMS/RCS on nearly all Android devices as well as the underlying OS itself.
There is little new information to gain for them, no matter how Android users communicate with Apple users right now.
There is however a lot to gain for them if a unified rich communication standard is established in the market, because apart from finally being able to replace SMS, it would drive platform-agnostic innovation in this area.
Google and Apple agreeing on a standard could disrupt the ecosystems of Facebook Messenger, WhatsApp, Vibr, Zoom, MS Teams etc.
> There is little new information to gain for them, no matter how Android users communicate with Apple users right now.
The client and the OS don't really give them any metadata or message content. Operating the server infrastructure would.
SMS doesn't touch their servers (except possibly for people that use Google's Messages app and/or backup service); RCS does.
> There is however a lot to gain for them if a unified rich communication standard is established in the market, because apart from finally being able to replace SMS, it would drive platform-agnostic innovation in this area.
Absolutely, but that open standard will hopefully not be RCS. It's way too coupled to the 3GPP/ITU model of doing things.
I trust the organizations in charge of the web and Internet (who brought us email and XMPP/Jabber!) a bit more than those who still somewhat yearn for the days in which OTT players did not exist and telecommunication was charged by the mile and minute or message.
> The client and the OS don't really give them any metadata or message content.
The client includes a spam protection service which allows them to send message data to a server for scanning. Every other messaging app uses the Notification service to send the message and its relevant metadata to the OS. So as far as conspiracy goes, Google has all the means to get the data already today.
The situation was resolved by Google taking effort to unify the Android landscape and maintain a single client for that OS, instead of carriers (like Orange Group) developing one client, Samsung, LG, Sony, Huawei, ZTE each developing other clients
Google doesn't own the RCS-specification, the spec is still defined and maintained by GSMA, with Google just having one of the seats at the table (along with carriers and device manufacturers).
Apple is also a member of GSMA, them adopting RCS means that they just take another seat at the table of the RCS working group.
--
> Google has significant incentives for pushing RCS for more than one reason.
I don't know if you mean to imply some hidden Agenda. The incentive is to standardize "rich communication" across mobile platforms. "Green bubble" is one manifestation of the bigger issue that 27 years after the creation of SMS there is still no other universal method for me to send a text to your phone number today.
The main reason for that is, that several players still hope to own this communication channel to the user with their proprietary app, become the "Western WeChat" and sell access to the users.
RCS could be an universal non-proprietary method, open to be adopted by Apple, Facebook, WhatsApp and whoever wants to build a Message ecosystem. It has the potential to end this hassle and allow me to send a text to your number and reach you regardless of your OS and application of preference.
So each major device-vendor developed his client-app, and ended up with interoperability issues not only with the RCS-servers used by a given carrier, but also with devices of OTHER vendors. And that doesn't even begin to cover the issues on inter-carrier messaging...
The situation was only resolved after Google acquired Jibe Mobile (the biggest player in developing RCS server/client applications for carriers) and basically created a single RCS-client/server implementation using their Android Messages app and a Google-owned server.
But when you were working on RCS back in 2012, you may remember that at that time, RCS didn't even support store&forward (!!).
So if the receiving device was not available when a message was delivered (because it had no network or client wasn't running on a device, which happened alot especially on iOS because the client was in a constant fight with the OS), the message wasn't queued anywhere.
Apart from the obvious issue of missing messages, it caused the even worse UX-impact that the entire conversation looked different on sender/receiver.
--
Ah yes, and: RCS was originally designed with per-message billing in mind (of course). At the time it was launched it was finally clear to the carriers that those times are over, but the whole architecture had quite a chunk of billing architecture in it as well...