iOS 26.3 beta 2 prepares encrypted RCS for iPhone and Android with MLS

In this article

1. Overview: why this step is different
2. Technical Details: MLS, E2EE and interoperability
3. Limitations & Challenges: because carriers hold the key
4. What changes for the user: signals, expectations and best practices
5. Next Steps: what to watch for in upcoming betas
6. FAQ

Encrypted RCS iPhone‑Android is getting closer: in iOS 26.3 beta 2 there are signs of carrier control that could enable end‑to‑end encryption (E2EE) on RCS messages between iPhone and Android. This matters because RCS has already brought read receipts, reactions and richer multimedia to cross‑platform chats, but without the privacy shield that many associate with iMessage. If the final piece fits together (carrier infrastructure), “modern” SMS could finally become the default secure option for millions of users.

Overview: why this step is different

RCS (Rich Communication Services) is a messaging standard backed by carriers and backend platforms, designed to replace SMS/MMS with modern features. The distinction here is the ambition to make RCS genuinely private across ecosystems: encrypted RCS iPhone‑Android means iOS and Android can negotiate keys and protect content without relying on a single‑brand proprietary system. The most relevant hint is practical: rather than a purely iPhone‑side option, a signal appears that activation may depend on a carrier bundle parameter. This suggests Apple is already preparing the device side, but needs the carrier networks and/or RCS services to be ready to support E2EE. According to the information shared at the source, the configuration line was seen in packages associated with French carriers (Bouygues, Orange, SFR and Free), though not yet active. For editorial transparency, the original piece is referenced: Apple Preps Secure RCS For iPhone And Android.

Technical Details: MLS, E2EE and interoperability

To understand what is at stake, it helps to separate three concepts. E2EE (end‑to‑end encryption) means only the participants in a conversation can read the messages; intermediate servers should not be able to access the content. MLS (Messaging Layer Security) is a modern protocol designed for one‑to‑one and group chats with frequent member changes, using “ratchet” mechanisms to reinforce properties such as forward secrecy and post‑compromise recovery. The critical point is interoperability: encrypted RCS iPhone‑Android will work consistently only if both sides speak the same cryptographic “language” and the RCS‑delivering backend supports that model. The source notes that MLS was chosen within the Universal Profile 3.0 (GSMA) to make RCS encryption compatible across vendors. In practice, this reduces the risk of each manufacturer creating its own closed solution for “secure messages”. It also explains why Apple cannot “turn this on” alone as it does with iMessage: RCS, by definition, passes through carrier infrastructure and/or cloud messaging platforms. If the RCS server is not ready for encryption routines, key management and compatibility, the iPhone may have software support yet still be unable to establish sessions E2EE.

Limitations & Challenges: because carriers hold the key

That “switch” controlled by the carrier is more than a bureaucratic detail. It signals that the rollout may be phased and uneven: some networks may activate first, others later, and some may be delayed for technical, regulatory or integration reasons with existing systems. There is also a delicate balance with features that sit at the edge of current RCS: spam filtering, anti‑abuse protection, and verified business messages. In many implementations these layers rely on partial visibility of traffic (metadata and, occasionally, content). With E2EE, the content becomes opaque, necessitating a redesign of controls and policies. This does not block encrypted RCS iPhone‑Android, but may dictate how and when it is activated, and in which conversation types. Another challenge is the fallback experience. Even with iPhone support, cases will arise where the chat falls back to unencrypted RCS, or even to SMS/MMS, if the other party, the network, or the backend do not support MLS. For the user, this is only acceptable if the system clearly indicates the security state, avoiding a false sense of privacy.

What changes for the user: signals, expectations and best practices

If and when it becomes available, encrypted RCS iPhone‑Android should protect conversations 1:1 and groups, while retaining most modern features (reactions, typing indicators, read receipts, higher‑quality file sharing). The real gain is simple: less exposure of content to intermediaries, especially in scenarios where today it is mistakenly assumed that “normal messages” are already private. In practice, the day‑to‑day changes will include: 1) An encryption indicator should appear in the chat (the exact wording depends on the final implementation). 2) There may be variation by carrier and country, at least in an initial phase. 3) In mixed‑device conversations, the security state may switch depending on participants and network support. Best practices when the feature arrives: verify the encryption indicator before sharing sensitive data; keep iOS up to date; and in groups, understand that participants joining or leaving may trigger key renegotiation (normal in MLS) and occasional notices in the chat history.

Next Steps: what to watch for in upcoming betas

The strongest signal that encrypted RCS iPhone‑Android is ready for the “real world” will be carriers rolling out the parameter and Apple displaying a clear indicator in the Messages app. Until then, limited testing, country‑ or carrier‑specific activation and compatibility tweaks with different RCS backends are to be expected. For those tracking the topic, three useful clues: (1) release notes and changes in iOS beta 26.3; (2) Android‑side updates in messaging apps and RCS services; (3) support communications that explain what is protected and under what conditions. If you need context on support policies and delivery timelines for online purchases (for example, for anyone swapping smartphones to ensure updates), you can consult iOutlet pages for warranty conditions and shipping deadlines. Essentially, the technology looks to be aligning, but the timetable will depend on who “turns on” the service. When it happens, it will be one of the most significant shifts in standard message privacy between iPhone and Android in years, and for many users, the first time the default chat is truly protected end‑to‑end.

FAQ

What exactly does “encrypted RCS iPhone Android” mean?

It means RCS with end‑to‑end encryption between iPhone and Android, where only the participants can read the messages, ideally using MLS for cross‑platform compatibility.

Doesn't iMessage already solve this?

iMessage is secure, but it works largely within the Apple ecosystem. In conversations with Android, iMessage does not apply; that’s where RCS steps in as the “cross‑platform” standard.

Why does the carrier need to enable encryption?

Because RCS relies on carrier/network or cloud‑based server infrastructure. Enabling E2EE requires backend support, compatible policies and services.

Will I need to change any setting on the iPhone?

There may be an option or the activation could be automatic, but evidence points to carrier‑side control. The final implementation might include indicators and settings in iOS.

Are business messages (e.g., verified senders) also encrypted?

It is not guaranteed. In RCS, business messages may follow a different route for compliance and anti‑abuse reasons, and may not use the same E2EE model.

What happens if the other person does not have support for MLS/E2EE?

The conversation may fall back to unencrypted RCS or, in some cases, to SMS/MMS. Ideally the system clearly indicates when the chat is not protected.

Get more articles like this one.

Refurbished tech analysis + €5 with BEMVINDO5 on your first order.

Subscribe