For years, the iPhone's blue-vs-green bubble divide was more than aesthetic tribalism — it was a security divide. End-to-end encryption for RCS messages between iPhone and Android devices is now officially available, with Apple confirming support is included in iOS 26.5. But to understand why that matters, you need to understand what came before it.
Until iOS 26.5, iPhone-to-Android RCS threads were not end-to-end encrypted. Those conversations did support read receipts, typing indicators, and high-resolution media sharing, but content protection was absent. In other words, the "green bubble upgrade" from SMS to RCS modernised the feature set without fixing the privacy gap. Google Messages had E2EE conversations between Android users using the Signal protocol, but that protection did not extend to RCS threads with iPhone users. iMessage, which Apple has noted remains E2EE by default between Apple devices, sat on the other side of that divide.
The gap persisted because Google's RCS encryption was proprietary. It wasn't until the GSMA — the group that oversees the RCS Universal Profile — announced an E2EE standard that Apple promised to embrace it. That standard, published as Universal Profile 3.0 in March 2025, is what makes the iOS 26.5 rollout possible.
Google and Apple are rolling out end-to-end encryption for RCS, securing chats between Android and iPhone users by default. Starting today, E2EE RCS messaging begins rolling out in beta for iPhone users running iOS 26.5 with supported carriers and Android users on the latest version of Google Messages.
The technical backbone is the IETF's Messaging Layer Security (MLS) protocol. The rollout implements the GSMA's RCS Universal Profile 3.0 specification, which defined how to apply MLS within the RCS standard. Until now, encryption protections had not extended to cross-platform RCS threads. MLS is designed to handle secure messaging at scale, including in group conversations, which makes it well suited for a platform like RCS that serves hundreds of millions of users worldwide.
For users, the experience is simple: in Google Messages, a small lock icon appears next to the conversation — the same lock that previously marked Android-to-Android RCS chats as secure. On iPhone running iOS 26.5, the chat surfaces a similar indicator. Encryption is on by default, and there is a toggle for it in the Messages section of the Settings app.
This is the biggest asterisk on the announcement. One unsupported carrier on either end is enough to leave the thread unencrypted. This is not a toggle issue and not something either user can fix in settings — it is a network support question on both ends of the conversation. The rollout happens over time, and some users may wait days or weeks before the lock icon appears, as carriers must flip switches on their side.
That architectural difference matters in practice. iMessage encryption is consistent because it never touches telecom infrastructure. Encrypted RCS is consistent only when every carrier in a conversation has done its part.
The E2EE functionality in iOS 26.5 is limited to one-on-one conversations. While MLS is designed for group security, its implementation in this initial release has not extended to mixed-platform group messaging. Group chats carry one known exception: if any participant in a thread connects through a carrier that does not yet support encryption, that entire conversation may not be protected under the beta rollout.
End-to-end encryption protects message content in transit — it does not protect everything. Metadata will likely still be collected and stored for these conversations, making alternatives like Signal still a better option for many conversations. That means who you message, when, and how often can still be visible to carriers and infrastructure providers even when the words themselves are locked.
If you back up those conversations to the cloud, they may be stored unencrypted unless you've enabled Apple's Advanced Data Protection or equivalent settings on the Android side. The encryption protects the wire — not necessarily the copy sitting in your backup.
| Method | E2EE by default | Cross-platform | Carrier dependent | Group chat E2EE | Metadata protected |
|---|---|---|---|---|---|
| Signal | ✅ Always | ✅ Yes | ❌ No | ✅ Yes | ✅ Largely yes |
| iMessage (Apple ↔ Apple) | ✅ Always | ❌ Apple-only | ❌ No | ✅ Yes | ⚠️ Partial |
| ✅ Always | ✅ Yes | ❌ No | ✅ Yes | ⚠️ Meta collects metadata | |
| RCS E2EE (iOS 26.5+) | ✅ When supported | ✅ Yes | ✅ Yes | ❌ Not yet | ❌ No |
| RCS without E2EE | ❌ No | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
| SMS | ❌ No | ✅ Yes | ✅ Yes | ❌ No | ❌ No |
The EFF called the announcement a "Victory," acknowledging that Apple and Google have taken meaningful steps toward encrypting everyday messaging at scale. The framing is significant: the EFF has long pressured both companies under its "Encrypt it Already" campaign, and cross-platform RCS E2EE was explicitly on that list.
But the organisation stopped well short of declaring the job done. The metadata caveat, carrier dependency, and beta label all temper the celebration. For sensitive conversations where carrier support hasn't landed yet, Signal remains the more reliable option — it has always been end-to-end encrypted, works across platforms, and doesn't depend on carrier adoption of any standard.
The GSMA, for its part, was more bullish. Their press release stated that E2EE RCS messages can't be read by anyone but the sender and receiver, even by Apple or Google — providing users with "the highest level of privacy and security while messaging." That claim holds for supported, one-on-one conversations — it does not hold universally yet.
The honest summary: cross-platform RCS encryption in 2026 is the best version of built-in texting that has ever existed between iPhones and Androids. It is a genuine improvement, and for most casual conversations it will soon be invisible infrastructure that just works. But "soon" and "most" are still doing heavy lifting.
The green bubble is no longer a scarlet letter for privacy — but it's not a blue bubble either. The gap is narrowing, and that's worth acknowledging. The gap isn't gone, and that's worth knowing.