iOS 26.5 Beta RCS End-to-End Encryption Returns, But Android Gap Remains

Apple has brought iOS 26.5 beta RCS end-to-end encryption back for a second consecutive testing cycle. The iOS 26.5 developer beta, released this week, includes an "End-to-End Encryption (Beta)" toggle for RCS in the Messages app, enabled by default, after the same feature appeared in iOS 26.4 testing and was pulled before that release shipped, as reported by 9to5Mac and MacRumors this week.

The feature isn't shipping in iOS 26.5 either. Apple's developer notes are explicit: "This feature is not shipping in this release and will be available to customers in a future software update for iOS, iPadOS, macOS, and watchOS." The notes carry a harder constraint: current beta testing covers only Apple-to-Apple RCS conversations, and encrypted messaging with Android "is not yet testable with other platforms," Privacy Guides reported today.

That last detail matters. Apple's progress is real and demonstrable. But the core use case, encrypted texts between iPhones and Android phones, remains untested in any public beta.

What the beta shows and what it doesn't

The toggle itself is straightforward. Developers running iOS 26.5 beta 1 can find "End-to-End Encryption (Beta)" under Settings → Apps → Messages → RCS Messaging. It's on by default, and encrypted conversations display a lock icon, the same visual cue iMessage has used for years, now appearing in RCS threads, MacRumors reported six weeks ago.

What matters more is the scope. In this beta, encryption works only when both parties are on Apple devices, a condition that excludes the actual cross-platform scenario the feature is designed for. There's a wrinkle in the reporting worth addressing directly: an earlier MacRumors piece from this week described Apple as having tested iPhone-to-Android encryption during iOS 26.4's beta cycle, while the six-weeks-ago MacRumors report noted that cross-platform testing was planned for a later date. Apple's own 26.5 developer notes settle it: as of this beta, encrypted RCS is available for testing between Apple devices only and is not yet testable with other platforms. Whatever cross-platform testing may have occurred during 26.4, the confirmed scope right now is Apple-to-Apple.

The return of the feature in 26.5, after being pulled from 26.4, signals continued development rather than stalling. But it also confirms Apple's framing: this is a feature in active testing, not one nearing consumer release. As Apple's support documentation from March 2025 states, RCS messages on iPhone remain unencrypted in transit. Nothing in the 26.5 beta changes that for any actual user today.

Why the privacy gap still exists

The stakes here are concrete. iMessage has always been end-to-end encrypted. Android-to-Android RCS messaging has had encryption since 2022, though that protection applied only between Google Messages users, Privacy Guides noted today. iPhone-to-Android RCS is the one gap that remains, MacRumors confirmed this week. Any RCS message you send from an iPhone to an Android device right now travels unencrypted in transit, readable by carriers, network operators, or anyone else positioned to intercept it. That's the problem Apple is working to close, and the reason the beta activity is worth tracking even before it ships.

The standard that makes cross-platform RCS encryption possible, and why it took this long

Apple's RCS encryption isn't a proprietary solution. It depends entirely on RCS Universal Profile 3.0, a specification published by the GSMA that uses the Messaging Layer Security (MLS) protocol from the IETF as its cryptographic foundation. When the GSMA released the spec nine months ago, it described the result as the first large-scale messaging service to support "interoperable end-to-end encryption between client implementations from different providers," Telecoms.com reported.

The path to that release was long. The GSMA announced it would pursue interoperable RCS E2EE in September 2024. Development of Universal Profile 3.0 began in 2022. Apple stated it "helped lead a cross industry effort" to bring E2EE to the RCS Universal Profile, and publicly committed to adding support across iOS, iPadOS, macOS, and watchOS in future software updates, 9to5Mac reported seven weeks ago.

That four-platform commitment matters. Apple is treating this as messaging infrastructure, not a single-device experiment.

The reason encrypted RCS didn't exist from the start is also worth stating plainly. When Apple launched RCS support in iOS 18, it implemented Universal Profile 2.4, the baseline version covering read receipts, typing indicators, and higher-quality media. Encryption requires 3.0. The spec didn't exist in a finalized, interoperable form until 2025. Apple couldn't implement what the standard hadn't yet defined, 9to5Mac noted seven weeks ago.

When will RCS end-to-end encryption on iPhone work with Android?

Even after Apple ships Universal Profile 3.0 support, the experience won't be instant or universal. Three dependencies have to align for any given conversation to be encrypted:

Apple has to ship UP 3.0. That hasn't happened yet. The feature has appeared in two consecutive beta cycles and been pulled from release each time. Apple has committed to a future release across all four platforms but has not named a specific version or date. iOS 26.5 won't be it.

The Android client and carrier on the other end have to support UP 3.0. For an encrypted conversation to work, both devices and both carriers need to have enabled Universal Profile 3.0 support, Privacy Guides reported today. Apple has said most carriers that support RCS will also support RCS E2EE, but that phrasing implies exceptions, and carrier infrastructure upgrades don't happen in lockstep, MacRumors noted six weeks ago.

Both users have to have the toggle on. Unlike iMessage, which enforces encryption with no user override, the RCS implementation allows the feature to be disabled, The Munich Eye reported last month. It defaults to on, which helps. But it means the security floor for cross-platform RCS isn't structurally equivalent to iMessage. A user or a carrier can opt out.

In practice: when Apple ships this, users with supported devices and carriers will likely see the lock icon appear automatically in qualifying chats. Users whose carriers haven't upgraded, or whose Android contacts are on apps or networks that don't yet support UP 3.0, won't. There's no public timeline for which carriers or Android implementations will be ready first, and no independent verification yet of how conversations will behave when encryption isn't available on one end: whether they fall back silently or surface a clear indicator to the user.

What to watch for

Three facts define the current state: Apple is actively testing encrypted RCS, cross-platform testing with Android hasn't started in any confirmed public beta, and no ship date exists. That's meaningful forward motion against a problem, unprotected iPhone-to-Android texts, that has persisted since RCS launched on iOS.

When the feature does ship, the signal will be visible: an encryption toggle enabled by default in RCS settings, and a lock icon in conversations where both ends support UP 3.0. The absence of that lock icon will matter just as much, indicating a carrier gap, an unsupported device, or a disabled toggle on the other end, all of which will remain real possibilities for some time after launch, Privacy Guides noted today.

Apple's beta pattern suggests the feature is progressing. But shipping a toggle is the easy part. The harder target is what the industry actually promised: encrypted RCS working by default across every iPhone-to-Android conversation. The technology is largely in place. The ecosystem isn't there yet.