It's unfortunate that RCS is basically a de-facto Google walled garden in most countries. On android you can only use RCS in the Google Messages app and trying to build your own is explicitly blocked. [1] And of course the bonus that rooted devices are banned from RCS. All the propaganda Google spread to get Apple onboard (only with Google's blessing of course, Google could kick apple off if they wanted) was such a big win for them.
As a business I wanted RCS to be a simple upgrade to SMS, but instead they came up with this mess. Businesses using RCS for Business can send messages to anyone, but customers wanting to get in touch with your business can't. They can only reply to a message you sent first. And of course Google is the gatekeeper for anyone to be allowed to use it.
Unfortunately, I think what a lot of people don't know is that RCS actually has "client authenticity verification"[1]... the RCS server has to actively approve any attempts for a client to connect, if it's Android/iOS/etc.
There are no standards for how this should be implemented, Google uses Play Integrity and Apple uses App Attest at the current moment, with explicit proprietary support by the Jibe servers.
It's basically impossible for any solution that Google doesn't approve to function, because it's never going to be able to get App Attest/Play Integrity verification without relying on a jailbreak/vulnerability.
As an aside, the IMS stack used to implement SMS/MMS/RCS on Android is super cursed. A lot of the heavy lifting is handed off to the OEM, for example, Pixel devices hand it off to the Qualcomm modem.
(Meaning Android the OS doesn't even have any control over how the raw SIP messages are sent: they're inside an IPSec tunnel set up by the modem that it can't see inside)
iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?
That's why it's super annoying to handle SMS/MMS using the standard/legacy APIs, because depending on what device the user has, the implementation may behave radically differently with regards to PDU parsing and such.
RCS makes the whole situation worse because it sets up an entire secondary IMS stack inside the Google Messages app, and then uses weird APIs to try to tie it back into the main stack, even though obviously the modem implementation doesn't understand RCS... it's a mess.
> Pixel devices hand it off to the Qualcomm modem.
Older ones maybe, newer ones use Samsung Shannon modems.
> iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?
Just to be cursed the entire IMS stack for Samsung on both qcom and exynos is custom. It’s why no custom roms have support for voLTE on their devices. They also had their own RCS that they sunset in favor of Google Messages.
Apple’s implementation is cursed too and not only did they use an older specification but they didn’t fully implement required responses to registration issues, I wrote about it here: https://wt.gd/working-rcs-messaging
Google doesn't offer an RCS API, but making your own API is not blocked, especially not on phones running MicroG.
For standard ROMs, RCS apps are not feasible because carriers expect interaction with the SIM module, and only privileged apps can do that. Google Messages blocks root access (probably because the RCS spec says they have to if they ever implement the money exchange feature for RCS) but that just locks out Google Messages.
LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless. Rooted devices can also promote third party RCS apps to gain system permissions, so they would be able to use the same RCS apps. Thing is, like all telco protocols, RCS is a long spec with a billion features and acronyms made up of acronyms of even more acronyms, plus you can't easily set up your own server (though in theory a sister project for an open RCS server might be useful for the open 5G project).
I get why people want Google to just stuff their RCS library into open source Android the same way they do SMS/MMS, but to say it's impossible to write a client for, especially when running at the permission level MicroG runs at, is not the whole truth.
As for the whole "Google is the gatekeeper" thing: there are more RCS-for-business providers out there. Google's is probably the easiest to use by far, but Twilio has RCS too, as well as smaller companies such as LINK Mobility and Esendex. Sure, the people whose carriers don't support RCS might receive these business messages through Google's servers, but there's no need to pay Google a dime to make use of the RCS for Business specs.
> They may not be able to register with Google, but they can make an RCS app nonetheless.
They can make a "standards compliant" RCS which will be able to connect to literally zero carriers or servers on the planet.
In fact Google Messages "RCS" doesn't even implement the RCS standard. They use a proprietary protobuf api exclusive to Google. Google messages can't connect to any "RCS" servers except Google's.
> Twilio has RCS too
Twilio, Bandwidth etc. are gatekept by Google and are basically just a middleman reselling Google's product.
> They can make a "standards compliant" RCS which will be able to connect to literally zero carriers or servers on the planet.
I call bullshit. If iPhones can connect to RCS, so can other phones.
Their app does use a weird protobuf spec of their own design, but that's for synchronising messages across devices/their web UI. RCS doesn't really do multi-device the same way iMessage does so they had to add another layer. That's not part of RCS.
> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless.
Building a spec compliant RCS client for the love of the game, I guess.
> but there's no need to pay Google a dime to make use of the RCS for Business specs.
Assuming we're talking of global RCS and not domestic deployments (China and Korea mostly) you pay Google indirectly in all cases as Jibe is monetized via A2P revenue share.
> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client
And it will be useless. They likely won't be able to connect to their mobile network's RCS or to Google's RCS. A user with an official Android phone will be able to reach you only over regular SMS.
The way RCS works, the mobile _operator_ uses your corresponder's phone number to look up their RCS server. So that's also why RCS connectivity is so patchy, not all cell phone operators peer with each other.
> I get why people want Google to just stuff their RCS library into open source Android the same way they do SMS/MMS, but to say it's impossible to write a client for, especially when running at the permission level MicroG runs at, is not the whole truth.
It is. The Google's RCS endpoint requires attestation that is available through Play API only.
My personal advice is to avoid RCS at all costs, and use something that is not infested by mobile phone operators or Apple.
> They likely won't be able to connect to their mobile network's RCS
And why is that? Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.
> It is. The Google's RCS endpoint requires attestation that is available through Play API only.
Annoying, though hardly unexpected at this point. Still, that only poses a problem for Google's RCS servers, not for RCS itself.
> Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.
Except, SMS/MMS can be implemented by any standard IMS stack and it will function on any carrier (in theory, ignoring implementation bugs/incompatibility);
RCS has an explicit provision in the standard for "client authenticity" checks which in practice means App Attest/Play Integrity signatures.
> And it took more than a decade to get MMSC interoperability. It's still not perfect even now.
That's an understatement, my carrier has disabled MMS years ago. Still, that's not an issue with the MMS protocol, just an issue with carriers.
> That's a distinction without difference in the US.
The American carriers including Jibe in their network still speak RCS to clients. Google's Jibe is the most prevalent remaining RCS server but carrier Jibe isn't using the proprietary protocol that Google Messages uses (otherwise it wouldn't work on iPhones).
Ironically this is because of federation; if your carrier just uses Jibe (e.g. if you live in the US) then you don't deal with spam because Google has effective tools and a profit motive.
Also ironic: Google spent a decade forcing the world's carriers onto the worst messaging standard, only to end up where they started with Google Talk and XMPP; they are the only ones with significant market share on the protocol.
> customers wanting to get in touch with your business can't
Not technically true, though it can be more difficult. It's similar to how Apple Messages for Business works where you have to be given a URL (or QR code) to start a conversation with a business using RCS.
Founder of Clerk Chat here, I work with RCS for Business day in and day out and know the protocol inside and out.
A lot of the criticism in this thread is fair from a client / handset perspective, but it’s important to separate consumer RCS from RCS for Business. On the business side, RCS is actually a very powerful, well-designed protocol with massive potential when used the way it was intended: verified senders, conversational flows, and rich interactions at scale.
At Clerk Chat, we’re leading the way on conversational RCS, not just blasting messages, but enabling real two-way conversations that feel native, secure, and useful. Yes, Google is the gatekeeper as well as carriers today, but that’s also what enables trust, verification, and deliverability at global scale. When you work with the ecosystem instead of against it, it’s surprisingly effective.
We’re investing heavily in RCS because we believe it’s the natural evolution of business messaging beyond SMS. For companies that want to engage users where they already are with rich UI, fast responses, and verified identity, RCS is hard to beat.
If you’re interested in exploring what’s actually possible with RCS for Business today, feel free to reach out. Happy to enable folks and share real-world learnings.
Perfect I can't wait for the deluge of spam texts with real clickable buttons to trick me instead of just a 320x320 picture of one.
Let's see, RCS:
* needlessly complicated protocol, such that only a behemoth such as Google could administrate it
* Intensely leans on device attestation to even let you on to the network
* Tenfold the multimedia touchpoints as MMS, correspondingly it will have 10x the zero days
* Certainly wiretapped at law enforcement's whim
* Took 15 years to roll out
* And you still get green bubbles on iPhone
I wish we'd all switch to signal and the telcos would get back to being dumb pipes. But no, we need to support Read indicators and ad carousels in our baseband
When you use Whatsapp, you're trusting a single entity to handle your messages (plus your ISP I guess). When you use RCS, your messages go through your mobile operator, google, and perhaps someone else in an overly complicated way that is also built upon SMS (a non-internet thing) for more confusion.
So is RCS a Google platform, like how iMessage is an Apple platform? It might theoretically be a GSMA standard, but from their marketing page and how it's implemented in reality, it seems like it's the former.
RCS is a standard, but it needs hosted services for providers. Providers can either host themselves, or contract with someone like Google Jibe Cloud. Also, Google provides services for Android for providers that don't have it. iPhone depends on the provider so has less coverage.
Outside of China, it is de facto a Google thing due to Jibe not really in mood to interconnect with others, plus the fact that Google actually shoehorns RCS in countries where they think they can get away with it. Your statement "iPhone depends on the provider so has less coverage" basically bares this one. Two example:
1. Japan has already a different provider-supported thing +Message, (RCS-based but a different flavor because RCS is complicated), but Google is trying to win to them (and if I remember correctly, au actually jumped ship to Jibe recently-ish).
2. African carriers were confused because of RCS shoehorning without the carrier's consent: SMS reliably actually decreased because Google assumes that once you got an Android phone, surely you won't temporarily use that SIM on a "basic" phone for just an hour or two, right? Google just assumes that's offline, but for people still using their Android devices to reach their family on a farm who temporarily switched to a basic phone for its reliability and reach, their messages will still be send solely via RCS (which predictably won't reach the intended recipient because, of course, it does not have RCS).
Apple of course has its incentive to keep its users on iMessage, but it now accepts RCS (whether Jibe or not) and being "patchy" means that there are many, many carriers which did not implement RCS on their volition. I just imagine how would Google handle an oppressive government's request for interception on Jibe after carriers demonstrably shown that RCS was implemented without their consent, with fines and possibly prison sentences for illegally operating a carrier service to boot.
> plus the fact that Google actually shoehorns RCS in countries where they think they can get away with it.
This is the real thing that nails down "RCS" as a totally google thing. Google will forcefully enable RCS for people on carriers that want nothing to do with it. And in that case Google controls the entire process every single step of the way.
Just for the record, I am not necessarily disagreeing with "let's replace SMS", but Google can do it via a value-added service, which is much less regulated in most countries. Heck, Google already had it with Hangouts, and in my personal opinion it was just plain better than with Messenger. It was technically inferior with Whatsapp having E2E, but some people do prefer having a portable archive of their messages stored and access (much to the chagrin of cryptographers). However, killing it, resurrecting its corpse, and doing it again - well, it will not fare as everyone outside of Google predicted. Ron Amadeo had written a great piece about this in Ars Technica in 2021 (A decade and a half of instability: The history of Google messaging apps https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...)
Messing with what is supposed to be a carrier standard, as I already think what is happening, puts Google to (in my opinion) a legally unreasonable position in some countries, and I won't be shocked it it will be treated as a carrier with licenses et al. (or rather, lack of licenses, which is just plain bad for Google). I won't be surprised if it turned out that many Googlers already knew that this is a bad idea legal-wise, but the higher-ups have approved this shoehorning.
It's indeed hard to overstate how much Google fumbled the bag given their position. Early Android adopters came from GMail and almost invariably used GTalk on desktop. We had video chat over 3G in 2011 before iOS. But somehow they had to rewrite the app and try to ship an half-assed SMS integration in Hangouts as reaction to iMessage. Google should really have tried buying WhatsApp more seriously, at least we'd have seen some real competition between WhatsApp and FB Messenger.
> I won't be shocked it it will be treated as a carrier with licenses et al.
So, the way it works:
The GSMA isn't some kind of monolithic entity with a great deal of power. Industry players with aligned interests come together, form groups and agree on specs and roadmaps. Technically, RCS should be mandatory with 5G. In practice, it took a great deal of time before a country actually enforced that (China).
Google has seemingly been at the helm of the RCS work group since 2015~2016 with the Jibe acquisition first, then the spec revamp, a.k.a. Universal Profile. RCS was essentially a zombie initiative after ~2012, Google saw an opportunity and filled the void. Telcos aren't stupid, they saw P2P messaging being wiped out by OTT services, and SMS is good enough for A2P. There was little incentive for them.
Now, after a lot of failed experiments, and pivoting from a semblance of federated network to a protocol almost controlled end-to-end, Google got what it wanted: iOS support in North America. The rest of the world is mostly lost to WhatsApp and friends anyway.
Carriers that are on board with Google need to enable the standard registration mechanism used by the iOS client. It shouldn't be a big deal by the way, IMS is central to 4G/5G deployments for VoLTE, VoWiFi, SMSoIP, ... but this changes one important thing from a legal standpoint: now the service isn't provided by Google through an ad-hoc client (Google Messages), but by your carrier.
That said, Google can sell SaaS solutions to carriers. It's up to them to comply with local laws when they decide to provide RCS, regardless of the backend.
I think the EU has bigger fish to fry with the DMA. But Google's tactics might eventually come to someone's attention, as they essentially cornered carriers into adopting Jibe, or giving up on RCS. Somehow the only country that didn't let that happen is South Korea.
Moreover Android could separate the RCS client frontend and backend, like it does for SMS and MMS. But realistically most OEMs don't seem to care, and third party SMS apps are fairly niche.
Re: lawful interception, when carriers switch to IMS registration (as required by Apple) they should also get access to Jibe's standardized API for law enforcement tools (there's a spec for that, I forgot its name). However, just the fact RCS payloads are E2EE in Android-to-Android communications (and soon Android-to-iOS too, hopefully) might already be illegal in some places.
Google flip-flopping around its mobile IM strategy for a decade and then around carriers with RCS is getting harder and harder to understand. Pulling the rug under carriers in developing countries, who weren't interested in the drug dealer marketing tactics, is only going to solidify Meta's dominance, as doing business with WhatsApp has proven to be a much safer and saner bet all along.
This seems very specific to a few regions, India mostly.
Google is doing a really good job catching and blocking spam as far as I'm concerned. Even scammers aren't trying their luck over RCS in any way significant compared to Telegram, WhatsApp, or even iMessage.
I get vastly less spam on RCS than I do on SMS or iMessage.
The main thing Apple/Google needs to fix is RCS group messaging where spammers change the name of the group message to "Apple" or the business they're trying to impersonate.
Google makes RCS servers for carriers, host RCS themselves for carriers without RCS servers, and builds the most used RCS client app, so it makes sense that they're in the RCS monetization market as well, but you don't need to use them.
Google's pricing being displayed upfront while most others are listed as "contact us" will make Google much more attractive to small apps, of course.
I'm pretty unclear about how the experience they showcase in the video would work on iOS. Maybe Android has APIs for this, but on iOS it looks like RCS just supports green-bubble messages, links and files/multimedia. But in the demo they show multi-choice cards, carousels, cards with buttons, and reply auto-suggestions.
Also, someone correct me if I'm wrong, but it also looks like this needs to be agent-initiated, ie. you can't add a "Text us" button that will take you to this experience. (But you could capture a phone number, and text them _iff_ they have RCS available and enabled.)
Overall, seems questionable whether this is worth integrating if the experience is so fractured across platforms and many people might not even have RCS. The concept of a platform for rich messaging across platforms sounds good though.
However, all of this is in the RCS spec. If Apple implements the RCS spec beyond the bare basics, all of this should Just Work.
RCS is much more than just "SMS but via weird HTTP" and things like chatbots and interactive components were one of the selling points towards ISPs to bother supporting it.
Unfortunately, nobody seems to bother dealing with the standard. Now Google is at it again, selling "RCS for business" when the RCS standard itself is supposed to be used in a federated, carrier-to-carrier fashion just like SMS.
I have, on my iPhone, RCS messages from businesses that don’t show up as a green bubble, have (somewhat) interactive components, and exhibit non-standard (also non-intuitive) behavior I didn’t expect of either an RCS or an iMessage.
So I guess they did implement all that.
(Not that they are particularly nicely implemented - the layout and padding is all wrong, alignment is off, and it looks distinctly non-native… but that’s par for the course on iOS 26.)
I did just manage to dig up a source that says these things are somewhat implemented in iOS 18 with illustrative screenshots rather than actuals, and it seems to be implemented but currently janky:
- On iOS, rich cards have a message length limit of 144 characters. (Implies this is not a limitation on Android.)
- On iOS, multi-CTA might fold some of the options away. So you might give 4 options and it renders 2 options and makes you use a drop-down for the others.
- On iOS, carousels display as cards, which might not be as obvious to interact with.
Potentially improved in iOS 26. It's a little hard to work out the state of this, and of course not trivial to test without joining some kind of partner ecosystem.
This page is specifically talking about A2P (Application to Person) RCS with business messaging rather than Person to Person (P2P). The rich message types shown in the demo are only available for A2P / businesses.
Not a ton of businesses were interested in using RCS until Apple said they would support it. Businesses are now starting to adopt RCS, but for a variety of reasons it'll take a while for it to replace SMS / MMS.
I posted some more info above. Also, it is possible to create a "text us" button, but support (especially on iOS) is flakey. Carriers are not enabling RCS on the numbers businesses use for SMS / MMS in order to help eliminate spam.
What I think this is: as a reward to themselves for not stopping the tidal wave of fraud and phishing distributed via sms, they're going to charge businesses to message you in verifiable manner. So when your bank, ups/fedex for package delivery, walgreens/cvs for prescriptions, etc want to contact you google is going to charge.
As a reward for helping make sms untrustworthy, they're going to tax trustworthy communications.
I had my family iPhones revert to RCS. We had to delete chats and reset settings and reboot phones to get iMessage connected between these contacts again.
And it’s weird how bad sms messaging on Google Voice is, still. RCS would be welcome.
> And it’s weird how bad sms messaging on Google Voice is, still.
Messages get filtered more often by the carriers. Shows up to them as voip local numbers which is highest risk of spam. In any case it was bolted on almost as an afterthought.
I really think they only bump Google Voice client releases to revert the ‘use carrier only setting’ to ‘prefer data and wifi’, so Google saves a few pennies.
RCS is such trash. It's amazing that people fell for Google's BS in pushing Apple to implement it. I imagine that in the near future I will just disable it on my phone if I start getting spam. I push all my Android friends to use other messaging platforms, even with RCS it's a crap-shoot and pictures still come through looking like it's the year 2000.
RCS was a bad idea literally from day 1 and I do not understand why so many people thought it was worth pursuing. I mean other than Google since they effectively own the "standard", finally after untold number of failed messaging projects they have something they strong-armed other idiots into using.
Not really sure why this was posted today. However, I see a lot of confusion / misinformation in the comments, so here is a simplified explanation of how RCS works, while recognizing the topic is more complex technically and commercially. (Source/disclaimer: I am a product manager at Twilio and work on RCS.)
Google bought Jibe Mobile in 2015. [1] The GSMA Universal Profile (UP) defines the industry standard for RCS features. [2] Messaging apps (for example, Google Messages or Messages on iOS) implement those features, and carriers expose them through a MaaP (Messaging as a Platform). The GSMA publishes UP updates periodically; UP v3 was released in February 2025 [3], though the latest publicly iOS version supports UP v2.4.
Most carriers globally now use Google’s Jibe MaaP instead of building their own as Google Messages supports the Jibe MaaP. That choice reduced the fragmentation that previously produced many inconsistent Android messaging experiences. In addition, I believe E2EE encryption was only added to the UP in v3, Google had previously added it to Google Messages outside of the spec, as as a result only worked when both users are using Google Messages.
iOS Messages can technically support any MaaP because the downloaded carrier profile specifies which MaaP URL to use.
A MaaP supports both person-to-person (P2P) and application-to-person (A2P) RCS. P2P RCS uses phone numbers. Carriers generally do not enable RCS on the business phone numbers companies use for SMS today. For A2P RCS, businesses must create a chatbot/agent entity in the MaaP with its own image, display name, and contact details. Google’s MaaP provides an interface for businesses to create those RCS agent profiles; carriers then approve which agents may message subscribers on their networks. Theoretically this also helps make it easier for messaging clients to reduce spam / fraud, since traffic from legitimate business will be more distinguishable from P2P fraudulent traffic—both from a technical perspective (phone number vs chatbot/agent entity) as well as from an end user experience (verified and branded display vs anonymous phone number).
It's unfortunate that RCS is basically a de-facto Google walled garden in most countries. On android you can only use RCS in the Google Messages app and trying to build your own is explicitly blocked. [1] And of course the bonus that rooted devices are banned from RCS. All the propaganda Google spread to get Apple onboard (only with Google's blessing of course, Google could kick apple off if they wanted) was such a big win for them.
As a business I wanted RCS to be a simple upgrade to SMS, but instead they came up with this mess. Businesses using RCS for Business can send messages to anyone, but customers wanting to get in touch with your business can't. They can only reply to a message you sent first. And of course Google is the gatekeeper for anyone to be allowed to use it.
1. https://github.com/microg/GmsCore/issues/2994
Unfortunately, I think what a lot of people don't know is that RCS actually has "client authenticity verification"[1]... the RCS server has to actively approve any attempts for a client to connect, if it's Android/iOS/etc.
There are no standards for how this should be implemented, Google uses Play Integrity and Apple uses App Attest at the current moment, with explicit proprietary support by the Jibe servers.
It's basically impossible for any solution that Google doesn't approve to function, because it's never going to be able to get App Attest/Play Integrity verification without relying on a jailbreak/vulnerability.
1. https://www.gsma.com/solutions-and-impact/technologies/netwo...
As an aside, the IMS stack used to implement SMS/MMS/RCS on Android is super cursed. A lot of the heavy lifting is handed off to the OEM, for example, Pixel devices hand it off to the Qualcomm modem. (Meaning Android the OS doesn't even have any control over how the raw SIP messages are sent: they're inside an IPSec tunnel set up by the modem that it can't see inside)
iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?
That's why it's super annoying to handle SMS/MMS using the standard/legacy APIs, because depending on what device the user has, the implementation may behave radically differently with regards to PDU parsing and such.
RCS makes the whole situation worse because it sets up an entire secondary IMS stack inside the Google Messages app, and then uses weird APIs to try to tie it back into the main stack, even though obviously the modem implementation doesn't understand RCS... it's a mess.
> Pixel devices hand it off to the Qualcomm modem.
Older ones maybe, newer ones use Samsung Shannon modems.
> iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?
Just to be cursed the entire IMS stack for Samsung on both qcom and exynos is custom. It’s why no custom roms have support for voLTE on their devices. They also had their own RCS that they sunset in favor of Google Messages.
Apple’s implementation is cursed too and not only did they use an older specification but they didn’t fully implement required responses to registration issues, I wrote about it here: https://wt.gd/working-rcs-messaging
> never going to be able to get App Attest/Play Integrity verification without relying on a jailbreak/vulnerability.
Even with jailbreak/rooting, hardware attestation is nearly impossible to spoof.
> trying to build your own is explicitly blocked
Google doesn't offer an RCS API, but making your own API is not blocked, especially not on phones running MicroG.
For standard ROMs, RCS apps are not feasible because carriers expect interaction with the SIM module, and only privileged apps can do that. Google Messages blocks root access (probably because the RCS spec says they have to if they ever implement the money exchange feature for RCS) but that just locks out Google Messages.
LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless. Rooted devices can also promote third party RCS apps to gain system permissions, so they would be able to use the same RCS apps. Thing is, like all telco protocols, RCS is a long spec with a billion features and acronyms made up of acronyms of even more acronyms, plus you can't easily set up your own server (though in theory a sister project for an open RCS server might be useful for the open 5G project).
I get why people want Google to just stuff their RCS library into open source Android the same way they do SMS/MMS, but to say it's impossible to write a client for, especially when running at the permission level MicroG runs at, is not the whole truth.
As for the whole "Google is the gatekeeper" thing: there are more RCS-for-business providers out there. Google's is probably the easiest to use by far, but Twilio has RCS too, as well as smaller companies such as LINK Mobility and Esendex. Sure, the people whose carriers don't support RCS might receive these business messages through Google's servers, but there's no need to pay Google a dime to make use of the RCS for Business specs.
> They may not be able to register with Google, but they can make an RCS app nonetheless.
They can make a "standards compliant" RCS which will be able to connect to literally zero carriers or servers on the planet.
In fact Google Messages "RCS" doesn't even implement the RCS standard. They use a proprietary protobuf api exclusive to Google. Google messages can't connect to any "RCS" servers except Google's.
> Twilio has RCS too
Twilio, Bandwidth etc. are gatekept by Google and are basically just a middleman reselling Google's product.
> Bandwidth
Still find it endlessly amusing that they run Google Voice for Google and it still doesn’t support RCS.
> They can make a "standards compliant" RCS which will be able to connect to literally zero carriers or servers on the planet.
I call bullshit. If iPhones can connect to RCS, so can other phones.
Their app does use a weird protobuf spec of their own design, but that's for synchronising messages across devices/their web UI. RCS doesn't really do multi-device the same way iMessage does so they had to add another layer. That's not part of RCS.
The iOS client sends an app attestation token during registration.
Jibe could let any compliant client connect doesn't mean it does in practice. Case in point: Harmony OS.
> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless.
Building a spec compliant RCS client for the love of the game, I guess.
> but there's no need to pay Google a dime to make use of the RCS for Business specs.
Assuming we're talking of global RCS and not domestic deployments (China and Korea mostly) you pay Google indirectly in all cases as Jibe is monetized via A2P revenue share.
> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client
And it will be useless. They likely won't be able to connect to their mobile network's RCS or to Google's RCS. A user with an official Android phone will be able to reach you only over regular SMS.
The way RCS works, the mobile _operator_ uses your corresponder's phone number to look up their RCS server. So that's also why RCS connectivity is so patchy, not all cell phone operators peer with each other.
> I get why people want Google to just stuff their RCS library into open source Android the same way they do SMS/MMS, but to say it's impossible to write a client for, especially when running at the permission level MicroG runs at, is not the whole truth.
It is. The Google's RCS endpoint requires attestation that is available through Play API only.
My personal advice is to avoid RCS at all costs, and use something that is not infested by mobile phone operators or Apple.
> They likely won't be able to connect to their mobile network's RCS
And why is that? Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.
> It is. The Google's RCS endpoint requires attestation that is available through Play API only.
Annoying, though hardly unexpected at this point. Still, that only poses a problem for Google's RCS servers, not for RCS itself.
> Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.
Except, SMS/MMS can be implemented by any standard IMS stack and it will function on any carrier (in theory, ignoring implementation bugs/incompatibility);
RCS has an explicit provision in the standard for "client authenticity" checks which in practice means App Attest/Play Integrity signatures.
(see also: my comment above)
Global RCS == Jibe.
Google killed off all interconnected hubs.
> And why is that? Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do.
Correct. And it took more than a decade to get MMSC interoperability. It's still not perfect even now.
And mobile network operators were incentivized to enable MMSC peering because it was typically a pay-per-message service with hefty fees.
> Annoying, though hardly unexpected at this point. Still, that only poses a problem for Google's RCS servers, not for RCS itself.
That's a distinction without difference in the US.
> And it took more than a decade to get MMSC interoperability. It's still not perfect even now.
That's an understatement, my carrier has disabled MMS years ago. Still, that's not an issue with the MMS protocol, just an issue with carriers.
> That's a distinction without difference in the US.
The American carriers including Jibe in their network still speak RCS to clients. Google's Jibe is the most prevalent remaining RCS server but carrier Jibe isn't using the proprietary protocol that Google Messages uses (otherwise it wouldn't work on iPhones).
Looking at https://support.apple.com/en-us/108048, https://support.apple.com/en-us/118609, and https://support.apple.com/en-us/109526, carrier-based RCS is available in quite a few places. Nowhere near as prevalent as SMS/MMS hubs once were, but that has to do with the fact that in many countries SMS and MMS have been replaced by third-party apps over a decade ago.
> That's an understatement, my carrier has disabled MMS years ago. Still, that's not an issue with the MMS protocol, just an issue with carriers.
If a protocol requires something specific from carriers, then it's an issue with the protocol.
> The American carriers including Jibe in their network still speak RCS to clients.
Sure, and? It's still useless for me because it can't be used without Google Play.
US and about 180 other countries too.
RCS networks outside Jibe:
- China
- South Korea
- Japan with +Message, on its way out for Jibe
- Jio in India (very strange case as Android subscribers can use Google Messages on Jibe)
> Businesses using RCS for Business can send messages to anyone, but customers wanting to get in touch with your business can't.
Basically for blasting spam and ads, which RCS is already notorious for.
Ironically this is because of federation; if your carrier just uses Jibe (e.g. if you live in the US) then you don't deal with spam because Google has effective tools and a profit motive.
Also ironic: Google spent a decade forcing the world's carriers onto the worst messaging standard, only to end up where they started with Google Talk and XMPP; they are the only ones with significant market share on the protocol.
> customers wanting to get in touch with your business can't Not technically true, though it can be more difficult. It's similar to how Apple Messages for Business works where you have to be given a URL (or QR code) to start a conversation with a business using RCS.
to your point i had problems with RCS in an entire organization because you must allow *.goog for rcs to work correctly
Founder of Clerk Chat here, I work with RCS for Business day in and day out and know the protocol inside and out.
A lot of the criticism in this thread is fair from a client / handset perspective, but it’s important to separate consumer RCS from RCS for Business. On the business side, RCS is actually a very powerful, well-designed protocol with massive potential when used the way it was intended: verified senders, conversational flows, and rich interactions at scale.
At Clerk Chat, we’re leading the way on conversational RCS, not just blasting messages, but enabling real two-way conversations that feel native, secure, and useful. Yes, Google is the gatekeeper as well as carriers today, but that’s also what enables trust, verification, and deliverability at global scale. When you work with the ecosystem instead of against it, it’s surprisingly effective.
We’re investing heavily in RCS because we believe it’s the natural evolution of business messaging beyond SMS. For companies that want to engage users where they already are with rich UI, fast responses, and verified identity, RCS is hard to beat.
If you’re interested in exploring what’s actually possible with RCS for Business today, feel free to reach out. Happy to enable folks and share real-world learnings.
Igor, Founder @ Clerk Chat
Perfect I can't wait for the deluge of spam texts with real clickable buttons to trick me instead of just a 320x320 picture of one.
Let's see, RCS:
* needlessly complicated protocol, such that only a behemoth such as Google could administrate it
* Intensely leans on device attestation to even let you on to the network
* Tenfold the multimedia touchpoints as MMS, correspondingly it will have 10x the zero days
* Certainly wiretapped at law enforcement's whim
* Took 15 years to roll out
* And you still get green bubbles on iPhone
I wish we'd all switch to signal and the telcos would get back to being dumb pipes. But no, we need to support Read indicators and ad carousels in our baseband
What is the difference between RCS & Whatsapp messages? Aren't they similar?
When you use Whatsapp, you're trusting a single entity to handle your messages (plus your ISP I guess). When you use RCS, your messages go through your mobile operator, google, and perhaps someone else in an overly complicated way that is also built upon SMS (a non-internet thing) for more confusion.
Message payloads go directly to Google servers, there's no difference in practice.
Carriers handle IMS registration, that's it. And not even in all cases.
So is RCS a Google platform, like how iMessage is an Apple platform? It might theoretically be a GSMA standard, but from their marketing page and how it's implemented in reality, it seems like it's the former.
RCS is a standard, but it needs hosted services for providers. Providers can either host themselves, or contract with someone like Google Jibe Cloud. Also, Google provides services for Android for providers that don't have it. iPhone depends on the provider so has less coverage.
> Providers can either host themselves
Outside of China, it is de facto a Google thing due to Jibe not really in mood to interconnect with others, plus the fact that Google actually shoehorns RCS in countries where they think they can get away with it. Your statement "iPhone depends on the provider so has less coverage" basically bares this one. Two example:
1. Japan has already a different provider-supported thing +Message, (RCS-based but a different flavor because RCS is complicated), but Google is trying to win to them (and if I remember correctly, au actually jumped ship to Jibe recently-ish).
2. African carriers were confused because of RCS shoehorning without the carrier's consent: SMS reliably actually decreased because Google assumes that once you got an Android phone, surely you won't temporarily use that SIM on a "basic" phone for just an hour or two, right? Google just assumes that's offline, but for people still using their Android devices to reach their family on a farm who temporarily switched to a basic phone for its reliability and reach, their messages will still be send solely via RCS (which predictably won't reach the intended recipient because, of course, it does not have RCS).
Apple of course has its incentive to keep its users on iMessage, but it now accepts RCS (whether Jibe or not) and being "patchy" means that there are many, many carriers which did not implement RCS on their volition. I just imagine how would Google handle an oppressive government's request for interception on Jibe after carriers demonstrably shown that RCS was implemented without their consent, with fines and possibly prison sentences for illegally operating a carrier service to boot.
> plus the fact that Google actually shoehorns RCS in countries where they think they can get away with it.
This is the real thing that nails down "RCS" as a totally google thing. Google will forcefully enable RCS for people on carriers that want nothing to do with it. And in that case Google controls the entire process every single step of the way.
Just for the record, I am not necessarily disagreeing with "let's replace SMS", but Google can do it via a value-added service, which is much less regulated in most countries. Heck, Google already had it with Hangouts, and in my personal opinion it was just plain better than with Messenger. It was technically inferior with Whatsapp having E2E, but some people do prefer having a portable archive of their messages stored and access (much to the chagrin of cryptographers). However, killing it, resurrecting its corpse, and doing it again - well, it will not fare as everyone outside of Google predicted. Ron Amadeo had written a great piece about this in Ars Technica in 2021 (A decade and a half of instability: The history of Google messaging apps https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...)
Messing with what is supposed to be a carrier standard, as I already think what is happening, puts Google to (in my opinion) a legally unreasonable position in some countries, and I won't be shocked it it will be treated as a carrier with licenses et al. (or rather, lack of licenses, which is just plain bad for Google). I won't be surprised if it turned out that many Googlers already knew that this is a bad idea legal-wise, but the higher-ups have approved this shoehorning.
It's indeed hard to overstate how much Google fumbled the bag given their position. Early Android adopters came from GMail and almost invariably used GTalk on desktop. We had video chat over 3G in 2011 before iOS. But somehow they had to rewrite the app and try to ship an half-assed SMS integration in Hangouts as reaction to iMessage. Google should really have tried buying WhatsApp more seriously, at least we'd have seen some real competition between WhatsApp and FB Messenger.
> I won't be shocked it it will be treated as a carrier with licenses et al.
So, the way it works:
The GSMA isn't some kind of monolithic entity with a great deal of power. Industry players with aligned interests come together, form groups and agree on specs and roadmaps. Technically, RCS should be mandatory with 5G. In practice, it took a great deal of time before a country actually enforced that (China).
Google has seemingly been at the helm of the RCS work group since 2015~2016 with the Jibe acquisition first, then the spec revamp, a.k.a. Universal Profile. RCS was essentially a zombie initiative after ~2012, Google saw an opportunity and filled the void. Telcos aren't stupid, they saw P2P messaging being wiped out by OTT services, and SMS is good enough for A2P. There was little incentive for them.
Now, after a lot of failed experiments, and pivoting from a semblance of federated network to a protocol almost controlled end-to-end, Google got what it wanted: iOS support in North America. The rest of the world is mostly lost to WhatsApp and friends anyway.
Carriers that are on board with Google need to enable the standard registration mechanism used by the iOS client. It shouldn't be a big deal by the way, IMS is central to 4G/5G deployments for VoLTE, VoWiFi, SMSoIP, ... but this changes one important thing from a legal standpoint: now the service isn't provided by Google through an ad-hoc client (Google Messages), but by your carrier.
That said, Google can sell SaaS solutions to carriers. It's up to them to comply with local laws when they decide to provide RCS, regardless of the backend.
I think the EU has bigger fish to fry with the DMA. But Google's tactics might eventually come to someone's attention, as they essentially cornered carriers into adopting Jibe, or giving up on RCS. Somehow the only country that didn't let that happen is South Korea.
Moreover Android could separate the RCS client frontend and backend, like it does for SMS and MMS. But realistically most OEMs don't seem to care, and third party SMS apps are fairly niche.
Re: lawful interception, when carriers switch to IMS registration (as required by Apple) they should also get access to Jibe's standardized API for law enforcement tools (there's a spec for that, I forgot its name). However, just the fact RCS payloads are E2EE in Android-to-Android communications (and soon Android-to-iOS too, hopefully) might already be illegal in some places.
Google flip-flopping around its mobile IM strategy for a decade and then around carriers with RCS is getting harder and harder to understand. Pulling the rug under carriers in developing countries, who weren't interested in the drug dealer marketing tactics, is only going to solidify Meta's dominance, as doing business with WhatsApp has proven to be a much safer and saner bet all along.
Hate to agree, but with the underhanded tactics that Google is pulling with RCS, Meta is actually the sane and ethical company in the room.
A bit different in that RCS is available on both iOS and Android (and I guess theoretically other platforms?) while iMessage is strictly Apple devices
It's the same as how Android is technically open but the vast majority of users are getting the Google version.
RCS is basically spam-only messaging at this point. You can enhance your messaging experience by just turning it off.
This seems very specific to a few regions, India mostly.
Google is doing a really good job catching and blocking spam as far as I'm concerned. Even scammers aren't trying their luck over RCS in any way significant compared to Telegram, WhatsApp, or even iMessage.
I get vastly less spam on RCS than I do on SMS or iMessage.
The main thing Apple/Google needs to fix is RCS group messaging where spammers change the name of the group message to "Apple" or the business they're trying to impersonate.
If RCS is supposed to be an open standard, then how come Google can gatekeep the "for business" bit for themselves?
They don't (https://www.twilio.com/en-us/messaging/channels/rcs, https://www.cm.com/rcs/, https://www.linkmobility.com/en-gb/channels/rcs, https://gatewayapi.com/rcs/, https://www.productsupport.esendex.com/what-is-rcs-messaging..., the list goes on).
Google makes RCS servers for carriers, host RCS themselves for carriers without RCS servers, and builds the most used RCS client app, so it makes sense that they're in the RCS monetization market as well, but you don't need to use them.
Google's pricing being displayed upfront while most others are listed as "contact us" will make Google much more attractive to small apps, of course.
Twilio, Bandwidth etc. are gatekept by Google and are basically just a middleman reselling Google's product.
Every single customer on the planet reachable via "RCS for Business" is through Google's servers and the Google Messages app.
Pretty much because the other major telcos tried to run their own rcs services and did so terribly
I'm pretty unclear about how the experience they showcase in the video would work on iOS. Maybe Android has APIs for this, but on iOS it looks like RCS just supports green-bubble messages, links and files/multimedia. But in the demo they show multi-choice cards, carousels, cards with buttons, and reply auto-suggestions.
Also, someone correct me if I'm wrong, but it also looks like this needs to be agent-initiated, ie. you can't add a "Text us" button that will take you to this experience. (But you could capture a phone number, and text them _iff_ they have RCS available and enabled.)
Overall, seems questionable whether this is worth integrating if the experience is so fractured across platforms and many people might not even have RCS. The concept of a platform for rich messaging across platforms sounds good though.
I have never seen any of this in real life.
However, all of this is in the RCS spec. If Apple implements the RCS spec beyond the bare basics, all of this should Just Work.
RCS is much more than just "SMS but via weird HTTP" and things like chatbots and interactive components were one of the selling points towards ISPs to bother supporting it.
Unfortunately, nobody seems to bother dealing with the standard. Now Google is at it again, selling "RCS for business" when the RCS standard itself is supposed to be used in a federated, carrier-to-carrier fashion just like SMS.
I have, on my iPhone, RCS messages from businesses that don’t show up as a green bubble, have (somewhat) interactive components, and exhibit non-standard (also non-intuitive) behavior I didn’t expect of either an RCS or an iMessage.
So I guess they did implement all that.
(Not that they are particularly nicely implemented - the layout and padding is all wrong, alignment is off, and it looks distinctly non-native… but that’s par for the course on iOS 26.)
I did just manage to dig up a source that says these things are somewhat implemented in iOS 18 with illustrative screenshots rather than actuals, and it seems to be implemented but currently janky:
- On iOS, rich cards have a message length limit of 144 characters. (Implies this is not a limitation on Android.)
- On iOS, multi-CTA might fold some of the options away. So you might give 4 options and it renders 2 options and makes you use a drop-down for the others.
- On iOS, carousels display as cards, which might not be as obvious to interact with.
https://www.infobip.com/blog/apple-rcs
Potentially improved in iOS 26. It's a little hard to work out the state of this, and of course not trivial to test without joining some kind of partner ecosystem.
This page is specifically talking about A2P (Application to Person) RCS with business messaging rather than Person to Person (P2P). The rich message types shown in the demo are only available for A2P / businesses.
Not a ton of businesses were interested in using RCS until Apple said they would support it. Businesses are now starting to adopt RCS, but for a variety of reasons it'll take a while for it to replace SMS / MMS.
I posted some more info above. Also, it is possible to create a "text us" button, but support (especially on iOS) is flakey. Carriers are not enabling RCS on the numbers businesses use for SMS / MMS in order to help eliminate spam.
> it also looks like this needs to be agent-initiated, ie. you can't add a "Text us" button that will take you to this experience.
This is correct as of when I researched RCS capabilities. Not sure if it's changed at all but it was a deal breaker for me.
What I think this is: as a reward to themselves for not stopping the tidal wave of fraud and phishing distributed via sms, they're going to charge businesses to message you in verifiable manner. So when your bank, ups/fedex for package delivery, walgreens/cvs for prescriptions, etc want to contact you google is going to charge.
As a reward for helping make sms untrustworthy, they're going to tax trustworthy communications.
I had my family iPhones revert to RCS. We had to delete chats and reset settings and reboot phones to get iMessage connected between these contacts again.
And it’s weird how bad sms messaging on Google Voice is, still. RCS would be welcome.
> And it’s weird how bad sms messaging on Google Voice is, still.
Messages get filtered more often by the carriers. Shows up to them as voip local numbers which is highest risk of spam. In any case it was bolted on almost as an afterthought.
I really think they only bump Google Voice client releases to revert the ‘use carrier only setting’ to ‘prefer data and wifi’, so Google saves a few pennies.
RCS is such trash. It's amazing that people fell for Google's BS in pushing Apple to implement it. I imagine that in the near future I will just disable it on my phone if I start getting spam. I push all my Android friends to use other messaging platforms, even with RCS it's a crap-shoot and pictures still come through looking like it's the year 2000.
RCS was a bad idea literally from day 1 and I do not understand why so many people thought it was worth pursuing. I mean other than Google since they effectively own the "standard", finally after untold number of failed messaging projects they have something they strong-armed other idiots into using.
Would be great if we could focus on getting RCS for consumers working first
TIL they have a rich multimedia API for RCS.
I'd believe Google cared more about RCS if it worked with Google Voice.
What does this incarnation of RCS mean? Relentlessly Cancelled Services?
Seriously, define acronyms on your landing page. Is that so hard?
Not really sure why this was posted today. However, I see a lot of confusion / misinformation in the comments, so here is a simplified explanation of how RCS works, while recognizing the topic is more complex technically and commercially. (Source/disclaimer: I am a product manager at Twilio and work on RCS.)
Google bought Jibe Mobile in 2015. [1] The GSMA Universal Profile (UP) defines the industry standard for RCS features. [2] Messaging apps (for example, Google Messages or Messages on iOS) implement those features, and carriers expose them through a MaaP (Messaging as a Platform). The GSMA publishes UP updates periodically; UP v3 was released in February 2025 [3], though the latest publicly iOS version supports UP v2.4.
Most carriers globally now use Google’s Jibe MaaP instead of building their own as Google Messages supports the Jibe MaaP. That choice reduced the fragmentation that previously produced many inconsistent Android messaging experiences. In addition, I believe E2EE encryption was only added to the UP in v3, Google had previously added it to Google Messages outside of the spec, as as a result only worked when both users are using Google Messages.
iOS Messages can technically support any MaaP because the downloaded carrier profile specifies which MaaP URL to use.
A MaaP supports both person-to-person (P2P) and application-to-person (A2P) RCS. P2P RCS uses phone numbers. Carriers generally do not enable RCS on the business phone numbers companies use for SMS today. For A2P RCS, businesses must create a chatbot/agent entity in the MaaP with its own image, display name, and contact details. Google’s MaaP provides an interface for businesses to create those RCS agent profiles; carriers then approve which agents may message subscribers on their networks. Theoretically this also helps make it easier for messaging clients to reduce spam / fraud, since traffic from legitimate business will be more distinguishable from P2P fraudulent traffic—both from a technical perspective (phone number vs chatbot/agent entity) as well as from an end user experience (verified and branded display vs anonymous phone number).
If you're a business / brand, interested in getting started with RCS, check out this page with more info on how to get started with RCS: https://www.twilio.com/en-us/messaging/channels/rcs
1. https://techcrunch.com/2015/09/30/google-acquires-jibe-mobil... 2. https://www.gsma.com/solutions-and-impact/technologies/netwo... 3. https://www.gsma.com/solutions-and-impact/technologies/netwo...
I'm so old and out-of-touch that all I could imagine this was about was an ancient version control system:
https://en.wikipedia.org/wiki/Revision_Control_System
yeah staying away from RCS, too soon
With the quality Google is pushing out these days, I wouldn't touch this with a 100ft pole.