LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

RCS Messaging

15 min read Networking Deep Dives
messagingrcsmobilenetworkingencryptionstandards
Contents

For thirty years SMS was the messaging protocol of last resort — the thing that worked across every carrier, every phone, every country, at the cost of being a 160-character monospaced relic with no encryption, no read receipts, no high-resolution images, no anything. RCS — Rich Communication Services — was supposed to replace it in the early 2010s and instead spent fifteen years in carrier limbo before Apple’s reversal in 2024 finally pushed it across the line. In 2026 it is the default green-bubble protocol on both Google Messages and Apple Messages, finally with end-to-end encryption in the GSMA Universal Profile 3.0 specification rolling out across carriers, and the messaging interoperability problem is closer to solved than at any point in the smartphone era. It is also still a mess once you look at the seams. This post walks what RCS actually standardizes versus what the marketing implies, how the Universal Profile and Google’s Jibe cloud underneath it actually work, the Apple saga and what changed when it ended, what end-to-end encryption now covers and what still falls outside it, and the SMS fallback behavior that quietly undermines every assumption you might have about the system. The honest framing: RCS is finally the thing it was supposed to be, and that thing is good, not perfect.

What RCS Actually Is

RCS is, at its core, a successor protocol to SMS and MMS published by the GSMA — the global trade body for mobile network operators. Where SMS rides on the cellular control channel as a side effect of the way voice networks were designed, RCS rides on IP, the way every other modern messaging system does. That single architectural change drops away decade-old SMS constraints: 160-character payloads, no images bigger than postage stamps, no group messaging worth using, no typing indicators, no read receipts, no encryption. RCS replaces all of them by carrying messages over the operator’s IMS (IP Multimedia Subsystem) — the same underlying infrastructure that handles voice over LTE and now 5G voice and data.

The headline RCS features look a lot like WhatsApp, iMessage, or Telegram:

  • High-resolution images and videos sent over data instead of MMS.
  • Group chats that work like grown-up group chats — named groups, member adds and removes, persistent membership.
  • Typing indicators and delivery/read receipts.
  • File transfer up to operator-defined limits, often around 100 MB.
  • Reactions, threading, message replies, edits, and (since UP 3.0) message deletion.
  • Audio messages, location sharing, and rich business messaging.
  • End-to-end encryption between supporting clients (more on this below).

The catch — the one that distinguishes RCS from any over-the-top app — is that it is supposed to replace SMS as the carrier default. It uses your phone number as your identity (not an account or username), works with the bundled Messages app on Android and iOS (not a separate download), and falls back to SMS or MMS when RCS is not available on either end. This is what makes RCS interesting and also what makes its history so messy: it is not a single company’s product, it is a standard that has to be implemented by carriers, by phone manufacturers, by chipset vendors, and now by operating-system vendors, and getting all of them to agree on anything took longer than anyone expected.

The Universal Profile, and Why It Had to Exist

Early RCS deployments in the 2010s were a textbook fragmentation disaster. Each carrier could implement RCS however they wanted, with whatever feature set they wanted, talking only to whichever other carriers they had bilateral peering agreements with. The result was that RCS messages from a Verizon phone might not reach a T-Mobile user, RCS features available on AT&T might not work on Vodafone, and a single global user identity was impossible because every carrier had its own walled garden. The protocol existed; the interoperability did not.

The GSMA’s response was the Universal Profile — a single specification that every RCS implementation is supposed to conform to, defining the same feature set, the same message format, the same encoding, and the same interoperability assumptions. Universal Profile 1.0 came out in 2016; subsequent versions tightened the requirements and added features:

  • UP 1.0–2.4 specified the core messaging, group chat, typing, and read-receipt behavior, plus the business-messaging interfaces operators sell to brands.
  • UP 3.0 (March 2025) added the long-promised end-to-end encryption based on the Messaging Layer Security (MLS) protocol, message editing, message deletion, and inline replies. This is the version that finally makes RCS comparable to iMessage or WhatsApp from a privacy posture.

The Universal Profile is the reason RCS now works across carriers in any meaningful sense. It is also the reason RCS feature sets sometimes lag what people expect, because every device pair has to be running a UP version that both support, and operator rollouts are slow.

Carrier RCS, Jibe, and the Two Architectures

Once a carrier decides to support RCS, they have two practical paths to running it: build their own RCS infrastructure (an IMS-based platform that handles message routing, presence, file storage, and interconnect with other carriers’ RCS networks), or hand the whole thing to Google Jibe, the cloud RCS platform that Google operates and offers to operators as a turn-key service.

Building your own RCS is a real undertaking. The carrier needs:

  • IMS application servers handling SIP-based messaging signaling.
  • A media-storage system for the images, videos, and files that RCS allows.
  • Presence and capabilities-discovery services to know when a phone is reachable on RCS versus needing SMS fallback.
  • Interconnect peering with every other carrier whose users your customers want to message — either direct bilateral agreements or via an RCS hub.
  • Operations and billing integration with the rest of the carrier stack.

Google Jibe replaces all of that with a hosted service. The carrier pushes their RCS subscribers to use Jibe (effectively, Google’s cloud handles the IMS-level work), and Jibe automatically interconnects with every other carrier on Jibe — which is now most of them globally. Operators in the U.S. (T-Mobile, AT&T, Verizon), much of Europe, and much of Asia all use Jibe in some capacity. A few large operators still run their own RCS clouds (Vodafone has, China Mobile does) but the majority of the world’s RCS traffic flows through Google Jibe’s infrastructure.

This has real implications. RCS-via-Jibe means Google sees the metadata of every RCS message routed through it — who sent what to whom and when — even when the user is on a competing operator. The message contents are end-to-end encrypted under UP 3.0 between supporting clients, but the routing layer is operated by a single private company in many regions. This is the kind of centralization concern that periodically draws regulatory attention, particularly in the EU, and one of the reasons RCS independence remains a stated goal for some operator groups.

        TWO RCS ARCHITECTURES (carrier-side)

   Operator's own RCS:                    Operator on Google Jibe:

   phone ── 5G/Wi-Fi ── carrier IMS       phone ── 5G/Wi-Fi ── Jibe cloud
                          │                                       │
                          ▼                                       ▼
                  carrier RCS app server                  Google Jibe stack
                          │                                       │
              ┌───────────┼───────────┐               ┌───────────┴────────────┐
              ▼           ▼           ▼               ▼                        ▼
           peering    media store   billing      other Jibe-hosted          peer to a
            hub         (msgs)                    carriers (most of         self-hosted
                                                  the world)               carrier RCS

For a network engineer reasoning about messaging traffic on a corporate or home network, the practical takeaway is that RCS is IP traffic going either to your carrier’s IMS edge or to Jibe’s cloud over standard HTTPS-style transport. It is not, in any meaningful sense, “SMS infrastructure” anymore; it is closer to any OTT messaging app, just one that uses your phone number as the identity.

The Apple Saga and What Actually Changed

For most of the last decade, the central problem with cross-platform messaging was not RCS infrastructure — it was Apple. iPhone users defaulted to iMessage, which delivered end-to-end encrypted messages, high-resolution media, group chats that worked, and the “blue bubble” social-status signifier that became its own cultural phenomenon. When iPhone users messaged Android users, the protocol fell back to plain SMS — green bubbles, no encryption, garbage image quality, broken group chats. Apple had no commercial incentive to support RCS and resisted it for years on the publicly stated grounds that “it was not better than iMessage.”

This held until 2024. A combination of pressure points — the EU’s Digital Markets Act looking closely at messaging interoperability, growing carrier and regulator interest, and Google running multi-year public campaigns about the green-bubble experience — pushed Apple to announce in November 2023 that iOS 18 would support RCS. The actual implementation shipped in late 2024.

What that initial implementation did:

  • Supported the GSMA Universal Profile 2.4.
  • Replaced SMS as the default fallback when iMessage was unavailable, so iPhone-to-Android messages over RCS got high-res media, group chats, typing indicators, and the rest.
  • Kept iMessage exactly as it was for iPhone-to-iPhone — Apple did not migrate iPhone-to-iPhone chats to RCS.
  • Did not include end-to-end encryption, because UP 2.4 did not standardize it.

That last point was the one critics latched onto: iPhone-to-Android RCS was a huge upgrade over SMS but was still less private than either iMessage or WhatsApp. The fix came with UP 3.0, which specified MLS-based end-to-end encryption, and Apple began rolling that out in iOS 26.5 (beta) in early 2026. As of mid-2026, end-to-end encrypted RCS messaging between iOS and Android using the default Messages apps on both sides is a real shipping feature in beta — finally closing the privacy gap that defined the SMS-fallback era.

The iPhone-to-iPhone story still has not changed: those messages stay on iMessage by default, not RCS, because Apple sees no reason to migrate them when iMessage is more featureful and already encrypted. RCS is the interoperability layer; iMessage remains the Apple-to-Apple layer. The blue bubble survives.

What End-to-End Encryption Actually Covers in 2026

The headline that “RCS is now end-to-end encrypted” is correct as far as it goes, but the boundary is worth understanding clearly. As of UP 3.0 and the 2026 rollout:

Scenario Encryption status Notes
iPhone ↔ iPhone (iMessage) E2EE (Apple-controlled) Unchanged, this is iMessage not RCS
Android ↔ Android (Google Messages, both on RCS) E2EE via MLS Already shipped 2022+, broadened under UP 3.0
iPhone ↔ Android (both on Google Messages / Apple Messages, UP 3.0) E2EE via MLS Rolling out in beta from iOS 26.5; the new thing in 2026
Any user ↔ any user, one side on SMS fallback Not encrypted SMS has never been encrypted; fallback drops you out of E2EE
Any user on a non-default RCS client (Samsung Messages, etc.) Depends on client UP 3.0 support Older clients may not negotiate MLS
Business messaging (RBM) Server-mediated, no client E2EE The bank, the airline, the verification codes — not E2EE
RCS group chat E2EE via MLS in UP 3.0 Group key management is exactly what MLS was designed for
Metadata (who messaged whom, when, size) Visible to the routing operator (often Jibe) E2EE protects contents, not the metadata trail

The Messaging Layer Security (MLS) protocol itself is a thoughtful piece of cryptography — an IETF standard designed specifically for asynchronous group messaging at scale, with efficient key updates as members join and leave. It is what Google Messages has used for E2EE since 2022 and what UP 3.0 standardized for cross-carrier RCS. The same kind of careful protocol design that powers DNS-over-TLS and DNS-over-HTTPS — where the wire format is just one piece of a larger trust and key-rotation story — is what makes MLS solid.

The big honest caveat: SMS fallback breaks all of this. The moment one side of the conversation cannot receive RCS — phone offline, traveling on a non-RCS carrier, an old phone, a phone where RCS is disabled — the conversation falls back to plain SMS, which is unencrypted, low-fidelity, and broken in all the same ways it ever was. Most messaging clients will warn you when this happens (the chat bubble color or icon changes), but the warning is easy to miss. Sensitive conversations that need actual privacy guarantees should still happen on Signal, where there is no SMS fallback to silently downgrade you.

SMS Fallback: The Honest Failure Mode

Fallback is the part of the RCS story most users never think about until it bites them. When a Messages app cannot deliver an RCS message — the recipient is offline, on a carrier that has not enabled RCS, on a phone that does not support it, has data turned off, or simply has not enabled RCS in settings — the message silently downgrades to SMS or MMS.

This is the right behavior from a deliverability standpoint: a message that fails because RCS does not work is worse than a degraded message that arrives. But it has cascading consequences:

  • Lost encryption. A fallback drops you from E2EE to plaintext on the air. If you were sharing a password, a bank account, anything, it is now SMS.
  • Lost features. Read receipts vanish. Typing indicators vanish. High-res images get compressed to thumbnails. Group chats devolve into broken “everyone in the same MMS” sessions where reply behavior is non-deterministic.
  • Charges. International SMS rates apply on fallback, where data-based RCS would have been free. Roaming users get surprise bills.
  • Inconsistent UX. A conversation that worked fine yesterday might silently degrade today because one person’s phone is in a tunnel — and then quietly re-upgrade when they come out.

The fallback decision happens at the sending client, based on a capabilities lookup against the RCS network — essentially asking the operator’s presence service “can this recipient receive RCS right now?” If the answer is no, the client formats the same content for SMS/MMS and ships it that way. The protocols are completely different transports; the user experience tries to make this seamless and mostly does, except when it does not.

The detailed behavior varies by client. Google Messages is fairly aggressive about flagging fallback to the user; Apple Messages is more subtle. Some carriers add extra layers (delivery retries, scheduled re-attempts). For a developer building messaging products via RCS Business Messaging, the fallback is a critical reliability mechanism, but you build for it explicitly with separate SMS pathways for the same content.

The Honest 2026 State of Cross-Platform Messaging

So where does this leave the messaging landscape? Better than any year since the smartphone era began, but with seams still visible.

The wins. iPhone-to-Android RCS over UP 3.0 with end-to-end encryption is now real, shipping in beta and rolling broadly across carriers and OS versions through 2026. The green-bubble experience is no longer fundamentally degraded; you get the same high-res media, group chat, typing indicators, and encryption you get on any modern messaging app. Carrier interoperability via the Universal Profile actually works across most of the world. Business messaging via RBM gives brands a real channel for verified rich messages with logos, buttons, and structured cards, which is starting to replace the “click this link” cottage industry of SMS marketing.

The still-uneven parts. Apple’s RCS implementation is conservative — it ships the standard but does not aggressively migrate iPhone users away from iMessage, so the blue/green bubble distinction persists between iOS users (iMessage) and iOS-to-Android pairs (RCS). E2EE rollouts depend on both sides being on a current OS and a participating carrier; old phones and slow-moving operators leave gaps where you think you have encryption and you do not. SMS fallback continues to silently undermine the privacy posture whenever a recipient is briefly unreachable. Metadata — who messages whom — remains visible to the routing operator, which is often Google Jibe.

The over-the-top apps still win on some axes. Signal, WhatsApp, iMessage, Telegram each have features RCS does not match (Signal’s metadata-resistance, WhatsApp’s web client and ubiquity outside North America, iMessage’s polish, Telegram’s bots and channels). RCS is not trying to be them; it is trying to be the carrier-default protocol that everyone you message might be on, even when they have not installed your favorite app. That is a different and important role — the equivalent of the zero-trust posture that assumes you cannot control every endpoint applied to messaging — and it is finally being filled adequately.

For most users, the practical advice in 2026 is simple: enable RCS, accept that iPhone-to-iPhone stays on iMessage, use Signal for anything that genuinely needs privacy, and treat RCS as the new default for the “send to this phone number” use case. It is not iMessage; it is not Signal; it is the messaging-of-last-resort, finally not embarrassing.

Verdict

RCS in 2026 is finally the thing it was supposed to be when the GSMA published the first specs over a decade ago: a carrier-grade replacement for SMS that supports high-resolution media, real group chats, typing indicators, read receipts, and — under Universal Profile 3.0 — end-to-end encryption based on MLS, working across Android and iOS by default. The Apple reversal in 2024 and the UP 3.0 rollout in 2025–2026 closed the two big gaps that had defined the messaging-interoperability problem for a generation, and the green-bubble experience is no longer fundamentally degraded relative to the blue one. The honest caveats remain: most of the world’s RCS routing flows through Google Jibe, concentrating metadata at a single provider; SMS fallback silently downgrades conversations to plaintext whenever one side cannot receive RCS, which means your encryption guarantee is conditional on both endpoints staying reachable; iPhone-to-iPhone messages stay on iMessage rather than RCS, so the blue bubble survives within Apple’s ecosystem; and business RCS messaging is server-mediated rather than end-to-end encrypted, which matters whenever a bank sends you a code. Treat RCS as the new lowest common denominator that is no longer embarrassing, use the default Messages app on both sides for the ordinary case, and keep Signal or another over-the-top app for any conversation where you need an encryption guarantee that does not evaporate the moment your recipient walks into an elevator. The protocol problem is mostly solved; the architecture and policy problems still belong to the next decade.

Sources

Comments