TheMurrow

Apple’s ‘Encrypted RCS’ Fix Is Real—So Why Are Your “Green Bubble” Texts Still Less Private (and sometimes less reliable) than you think?

Apple says iOS 26.5 brings end‑to‑end encrypted RCS—but it’s beta, carrier‑gated, and threads can still downgrade to SMS/MMS. The color never promised privacy.

By TheMurrow Editorial
May 7, 2026
Apple’s ‘Encrypted RCS’ Fix Is Real—So Why Are Your “Green Bubble” Texts Still Less Private (and sometimes less reliable) than you think?

Key Points

  • 1Apple confirms iOS 26.5 adds end‑to‑end encrypted RCS (beta)—but it’s carrier‑gated and will roll out over time.
  • 2Understand the three states: SMS/MMS fallback, RCS with transport encryption, and RCS with E2EE—threads can switch between them.
  • 3Treat green bubbles as a delivery label, not a safety badge; for high‑stakes messages, use dedicated E2EE apps that don’t depend on carriers.

A green bubble has always meant more than a color choice. For years it has been a quiet warning label: your message to an Android phone is probably traveling as SMS/MMS, stripped of modern features and sent without end‑to‑end encryption.

Apple’s answer arrived in stages. iOS 18 brought RCS to the Messages app, finally upgrading iPhone↔Android chats with typing indicators, read receipts, and better media. But Apple’s own support documentation made the tradeoff explicit: RCS messages weren’t end‑to‑end encrypted. The green bubble looked smarter, yet it still wasn’t private in the way iMessage users expect.

Now Apple says it is closing that gap—partly. Apple has confirmed that iOS 26.5 introduces “end‑to‑end encrypted RCS (beta) messaging,” and that it will be available with supported carriers and roll out over time. That phrasing matters. It means the “fix” is real, but also uneven by design.

“Green bubble is a UI color, not a cryptographic guarantee.”

— TheMurrow

What Apple actually fixed—and why it took this long

Apple didn’t wake up one morning and decide to “encrypt green bubbles.” The problem was structural: iPhone↔Android messaging had defaulted to SMS/MMS, which was designed for the era of flip phones and carrier-controlled texting. SMS offers essentially none of the privacy assurances people now take for granted in secure messaging apps.

iOS 18 marked Apple’s first major shift: it added RCS messaging in Messages, with RCS chats still appearing as green bubbles. RCS modernizes the experience—delivery indicators, typing indicators, richer media—without requiring users to install a third-party app. But Apple’s own support page drew a bright line: at the time of its publication and last update, RCS on iPhone was not end‑to‑end encrypted. That meant carriers or service intermediaries could, in principle, access content depending on implementation.

Apple’s second step is the one users have been demanding: encryption. In early May 2026, Apple confirmed iOS 26.5 adds end‑to‑end encrypted RCS (beta), and that availability depends on supported carriers with a gradual rollout. Multiple outlets highlighted the same constraints from Apple’s release notes: encryption is not instantly universal and is explicitly labeled beta.

The standard Apple was waiting for: GSMA’s Universal Profile 3.0

Apple’s delay was not only stubbornness. Cross-platform encryption requires a shared playbook. For years, Google offered encryption for certain RCS experiences in its own ecosystem, but that didn’t automatically translate into an interoperable, Apple-compatible standard.

A key milestone arrived on March 13, 2025, when the GSMA published RCS Universal Profile 3.0, adding requirements and user-experience guidance for end‑to‑end encryption. The GSMA framed the milestone as new E2EE specs based on the Messaging Layer Security (MLS) protocol. With that, Apple could implement encryption without adopting a Google-only scheme—and without forcing Android to adopt Apple’s iMessage.

“Apple didn’t just ship RCS. It waited for RCS to become a standard worth shipping.”

— TheMurrow

Why “RCS” still doesn’t mean one thing on your phone

Most people talk about “RCS” as if it were a single feature switch: either you have it or you don’t. In practice, “RCS” describes several different states with very different privacy implications. That’s why your green-bubble conversation can feel modern one day and regress the next.

State 1: SMS/MMS fallback (worst privacy)

When RCS isn’t available—because of carrier support gaps, provisioning hiccups, connectivity issues, or a recipient who can’t do RCS—the conversation often falls back to SMS/MMS. Apple’s support documentation distinguishes these message types and explains the differences.

SMS/MMS is the lowest rung:

- No end‑to‑end encryption
- Limited media quality and inconsistent group behavior
- Built for carrier routing, not for modern privacy expectations

State 2: RCS with transport encryption (better, not private)

RCS implementations often use transport encryption (for example, TLS) to protect data in transit. That’s an improvement over SMS, but it is not the same as end‑to‑end encryption, where only the sender and intended recipient can read content.

Google’s documentation for RCS chats describes how messages may be protected with TLS when E2EE isn’t available, and notes operational realities like briefly queued messages if undelivered. Those details matter because they highlight a core point: a system can be “encrypted” without being end‑to‑end encrypted.

State 3: RCS with end‑to‑end encryption (the new goal)

Under the GSMA’s Universal Profile 3.0 direction, E2EE becomes an interoperable expectation rather than a vendor perk. Apple’s iOS 26.5 confirmation is the practical expression of that: E2EE RCS (beta), rolled out through supported carriers.

The crucial implication for readers: even after you update, a single thread might shift among these states depending on the carrier path and device support.

“RCS isn’t a promise. It’s a negotiation between phones, carriers, and standards.”

— TheMurrow

MLS: the quiet standard behind the politics of encryption

End‑to‑end encryption across platforms lives or dies on standards. Apple and Google can each build excellent encryption systems inside their own walls. The hard part is agreeing on the same locks and keys across companies that compete.

That’s where Messaging Layer Security (MLS) enters the story. MLS is an IETF standard designed for efficient, scalable end‑to‑end encrypted messaging, particularly for groups. The core protocol is documented as RFC 9420, published in July 2023.

The GSMA’s announcement around RCS encryption explicitly ties its specs to MLS, and the GSMA also published a formal E2EE specification—RCC.16 v1.0—describing how RCS end‑to‑end encryption works and referencing MLS.

Why MLS matters for iPhone↔Android, not just engineers

MLS is not a marketing term. It matters because it offers a shared technical foundation that neither Apple nor Google “owns.” That lowers the temperature of the usual platform war:

- Apple can support cross-platform encryption without adopting Google’s proprietary approach.
- Android implementations can interoperate without becoming “iMessage-compatible” in a way that cedes control to Apple.
- Carriers and vendors get a common blueprint—though adoption is rarely uniform at the start.

The open question is not whether MLS is credible. It is whether the messy middle—carrier rollout, provisioning, software updates—can deliver encryption consistently enough that ordinary users can trust what they see.

What iOS 26.5 changes—and what the fine print means

Apple’s wording around iOS 26.5 is unusually revealing: “end‑to‑end encrypted RCS (beta) messaging” is “available with supported carriers and will roll out over time.” Two constraints are doing a lot of work in that sentence.

“Beta” means uneven behavior is not a bug, it’s the deal

A beta label signals a feature that’s still being tested in the real world: more edge cases, more interoperability quirks, and more variability. In messaging, those edge cases often show up as:

- Conversations downgrading without warning (for example, RCS to SMS)
- Group chat behavior changing depending on participant support
- Feature mismatches across apps and carrier implementations

None of this implies Apple’s encryption is flimsy. It implies the ecosystem is complex.

“Supported carriers” is the real gatekeeper

The carrier caveat is the bigger story. Apple isn’t flipping a global switch inside iOS and calling it done. It is integrating with a network reality where carriers still influence provisioning and service availability.

From a reader’s perspective, that yields a blunt practical takeaway: two people on the same iOS version can have different privacy outcomes depending on carrier support. That is a hard truth for consumers accustomed to app-based encryption, where the network matters less.

Why your “green bubble” may still be less private than you assume

Even if encrypted RCS works exactly as promised, “private” remains a layered claim. End‑to‑end encryption protects message content from intermediaries. It does not automatically erase every privacy risk that people conflate with encryption.

Privacy gap #1: Not everyone will have E2EE RCS immediately

Apple says encrypted RCS will “roll out over time.” That means early adopters will share the world with everyone else—people on unsupported carriers, older devices, or paths that fall back to SMS/MMS.

That is not a hypothetical edge case. It is the default state of large rollouts.

Privacy gap #2: Threads can downgrade

A conversation can move between RCS and SMS/MMS depending on availability. Apple’s own documentation differentiates these modes because they behave differently and carry different protections. A thread that is “secure” today may not be “secure” tomorrow if it falls back.

Privacy gap #3: Encryption doesn’t equal invisibility

End‑to‑end encryption—whether via iMessage, Signal, or RCS with MLS—does not prevent all metadata collection (who messaged whom, when, and from where). The research here centers on content security, but readers should keep the broader privacy picture in mind: encryption is necessary, not sufficient, for full anonymity or minimal data exhaust.

Real-world scenarios: what changes for actual iPhone↔Android texting

Most debates about RCS get trapped in platform tribalism. The better way to understand iOS 26.5 is to ask what a normal person notices—and what they won’t.

Scenario 1: Family group chats that include one Android phone

Before iOS 18, a mixed group chat often suffered: lower-quality media, clunky group behavior, and SMS/MMS limitations. With iOS 18’s RCS support, the experience improves, but encryption isn’t guaranteed. With iOS 26.5’s encrypted RCS (where available), content privacy should move closer to what iMessage users expect—while still depending on carrier support and rollout timing.

Scenario 2: Sending sensitive information across platforms

People routinely text passwords, addresses, health updates, and personal photos. Under SMS/MMS, those messages are not end‑to‑end encrypted. Under non-E2EE RCS, content may be protected in transit but not necessarily sealed from intermediaries. Under E2EE RCS (when it’s actually active), the content protection is materially stronger.

The practical lesson: if you are sending something truly sensitive and you can’t verify encryption, you should still consider a dedicated encrypted messenger.

Scenario 3: “Why did my chat get worse again?”

A common frustration is regression: you had read receipts and high-res media yesterday, and now you don’t. The simplest explanation is a fallback from RCS to SMS/MMS due to availability. Apple’s documentation and Google’s notes about transport states and queuing underline how many moving parts sit beneath a “simple” text message.

What readers should do now (without obsessing)

Encryption news tends to provoke two unhelpful extremes: complacency (“Apple fixed it, we’re safe”) and paranoia (“Nothing can be trusted”). The realistic posture is more measured: treat iOS 26.5 as genuine progress, and treat early rollout as imperfect.

Practical takeaways

- Update expectations: Even after updating, green-bubble privacy will vary depending on whether your chat is using SMS/MMS, standard RCS, or E2EE RCS.
- Watch for fallback behavior: If a thread loses modern features, it may have dropped to SMS/MMS, which is not end‑to‑end encrypted.
- Use purpose-built apps for high-stakes messages: For legal, medical, or safety-sensitive content, consider a dedicated end‑to‑end encrypted messaging app where encryption does not depend on carrier rollout.
- Be patient with the rollout: Apple has said the feature is beta and carrier-gated. Early inconsistency is not surprising—it is practically guaranteed.

A fair counterpoint: carriers and standards are doing hard work here

It is easy to blame Apple for arriving late, or carriers for moving slowly. Both critiques contain truth. Yet the long-term value of an interoperable standard (GSMA Universal Profile 3.0 based on MLS) is that encryption stops being a brand feature and becomes table stakes across devices.

The tradeoff is speed. Standards are slower than proprietary solutions, and rollouts are rarely synchronized.

“The real victory isn’t a new checkbox in iOS. It’s a shared standard that makes encryption portable.”

— TheMurrow

The bottom line: a real fix, delivered like a rollout—not a switch

Apple’s encrypted RCS move is the rare tech story where the headline is true and still incomplete. iPhone↔Android messaging is finally gaining a path to interoperable end‑to‑end encryption, grounded in a published standard—GSMA Universal Profile 3.0, based on MLS (RFC 9420).

Yet Apple’s own description sets expectations: beta, supported carriers, roll out over time. The green bubble won’t become uniformly “safe” overnight. It will become less of a warning label—gradually, unevenly, and with the kind of real-world friction that standards-based security often demands.

For users, the smartest posture is simple: welcome the progress, keep a clear eye on the caveats, and remember that privacy is a property of systems—not colors.

Key Insight

Apple’s “encrypted RCS” is real—but it’s beta, carrier‑gated, and threads can still fallback to SMS/MMS, changing privacy without the bubble color changing.

At-a-glance: What to watch for in green-bubble threads

  • Loss of typing indicators/read receipts (possible SMS/MMS fallback)
  • Mixed group chats behaving inconsistently (participant/device support mismatch)
  • Assuming “encrypted in transit” equals end‑to‑end encryption (it doesn’t)
  • Carrier differences causing different outcomes on the same iOS version
iOS 18
Apple’s first major shift: brought RCS to Messages for iPhone↔Android chats—modern features, but (at launch) no end‑to‑end encryption.
iOS 26.5
Apple’s stated next step: “end‑to‑end encrypted RCS (beta) messaging”—available with supported carriers and rolling out over time.
March 13, 2025
GSMA published RCS Universal Profile 3.0, adding E2EE requirements and guidance, with specs based on Messaging Layer Security (MLS).
RFC 9420 (July 2023)
The core MLS protocol standard—an IETF foundation designed for scalable end‑to‑end encrypted messaging, especially for groups.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering explainers.

Frequently Asked Questions

What did Apple change with iOS 26.5?

Apple confirmed iOS 26.5 adds “end‑to‑end encrypted RCS (beta) messaging.” Apple also said it is available with supported carriers and will roll out over time, so availability and behavior may vary during rollout.

Didn’t Apple already add RCS in iOS 18?

Yes. iOS 18 added RCS messaging in Messages for iPhone↔Android chats, but Apple’s support documentation noted RCS messages weren’t end‑to‑end encrypted at that stage. iOS 26.5 is the step Apple says adds E2EE to RCS, subject to rollout conditions.

Are green bubbles now as secure as iMessage?

Not automatically. Green bubbles label non‑iMessage chats, which can be SMS/MMS, RCS without E2EE, or RCS with E2EE. Only RCS with E2EE offers end‑to‑end encryption comparable in intent to iMessage.

Why does carrier support matter for encrypted RCS?

Apple says encrypted RCS is available with supported carriers and will roll out over time. Because RCS depends on carrier provisioning and network support more than app-based messengers, two users on the same iOS version can see different encryption outcomes.

What is MLS, and why is it part of this?

Messaging Layer Security (MLS) is an IETF standard for scalable end‑to‑end encrypted messaging; the core protocol is RFC 9420 (July 2023). The GSMA’s RCS encryption specs are based on MLS, enabling interoperable E2EE across iPhone and Android without a proprietary single-vendor scheme.

If my chat uses RCS, is it always encrypted?

Not necessarily end‑to‑end. Some RCS deployments may use transport encryption (like TLS), which protects data in transit but doesn’t guarantee only sender and recipient can read the content. E2EE depends on the specific RCS E2EE implementation and whether it’s active for the conversation.

More in Explainers

You Might Also Like