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.

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
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
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
State 1: SMS/MMS fallback (worst privacy)
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)
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)
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
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
- 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
“Beta” means uneven behavior is not a bug, it’s the deal
- 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
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
Privacy gap #1: Not everyone will have E2EE RCS immediately
That is not a hypothetical edge case. It is the default state of large rollouts.
Privacy gap #2: Threads can downgrade
Privacy gap #3: Encryption doesn’t equal invisibility
Real-world scenarios: what changes for actual iPhone↔Android texting
Scenario 1: Family group chats that include one Android phone
Scenario 2: Sending sensitive information across platforms
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?”
What readers should do now (without obsessing)
Practical takeaways
- 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
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
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
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
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.















