code:

Google's proprietary fork of RCS

Being from 2008 means RCS lacks much of what you would want from a modern messaging standard. First of all, as a standard, RCS is carrier messaging, so messages are delivered to a single carrier phone number, rather than multiple devices via the Internet, like how you would expect a modern service to operate. As a standard, there's no encryption. Google tried to glom features onto the aging RCS spec, but if you consider those part of the RCS sales pitch, which Google does, now it's more like you selling "Google's proprietary fork of RCS." Google would really like it if Apple built its proprietary RCS fork into iMessage.

Google's version of RCS—the one promoted on the website with Google-exclusive features like optional encryption—is definitely proprietary, by the way. If this is supposed to be a standard, there's no way for a third-party to use Google's RCS APIs right now. Some messaging apps, like Beeper, have asked Google about integrating RCS and were told there's no public RCS API and no plans to build one. Google has an RCS API already, but only Samsung is allowed to use it because Samsung signed some kind of partnership deal.

If you want to implement RCS, you'll need to run the messages through some kind of service, and who provides that server? It will probably be Google. Google bought Jibe, the leading RCS server provider, in 2015. Today it has a whole sales pitch about how Google Jibe can "help carriers quickly scale RCS services, iterate in short cycles, and benefit from improvements immediately." So the pitch for Apple to adopt RCS isn't just this public-good nonsense about making texts with Android users better; it's also about running Apple's messages through Google servers. Google profits in both server fees and data acquisition.