Apple is working on encryption support for RCS messages

The Evolution of RCS and the Push for Universal Encryption

We have been closely monitoring the telecommunications landscape for years, and few developments have been as significant as the shift toward the Rich Communication Services (RCS) protocol. For a long time, the messaging ecosystem was fragmented. Standard SMS offered basic text transmission but lacked modern features like read receipts, high-resolution media sharing, and typing indicators. Apple’s iMessage dominated the premium messaging space for iOS users, offering a seamless, feature-rich experience complete with end-to-end encryption (E2EE). However, this created a notorious divide known as the “green bubble vs. blue bubble” phenomenon, where communication between iPhone and Android users was relegated to the limitations of SMS/MMS.

The introduction of RCS was meant to bridge this gap. Spearheaded by the GSM Association (GSMA), RCS was designed to be the spiritual successor to SMS, providing a universal standard that works across carriers and devices. The initial rollout, heavily championed by Google through its “Messages” app, brought many iMessage-like features to Android devices and cross-platform chats. However, a critical piece was missing: true, standardized end-to-end encryption.

For a significant period, Google implemented E2EE for RCS messages using the MLS (Messaging Layer Security) protocol, but this was a proprietary implementation within Google’s ecosystem. While effective for Android-to-Android communication, it did not offer a standardized framework that Apple could reasonably adopt without compromising its security architecture or relying on a competitor’s specific implementation. Apple, famously protective of user privacy and security standards, naturally hesitated to adopt a non-standardized encryption method.

The landscape shifted dramatically with the release of the RCS Universal Profile 3.0 by the GSMA. This update was a watershed moment because it introduced a standardized definition for end-to-end encryption based on the MLS protocol. Now that the industry has a unified specification, the barrier to entry for Apple has been removed. We are now seeing concrete evidence that Apple is moving beyond mere adoption of the basic RCS protocol and is actively working to integrate this standardized encryption into its ecosystem.

Understanding the Technical Shift: From Proprietary to Universal Profile

To appreciate the magnitude of this development, we must dissect the technical nuances that previously prevented interoperability. The core issue was the lack of a universal standard for message encryption. When Google rolled out E2EE for RCS, it utilized a protocol that was not officially part of the GSMA’s Universal Profile at the time. While Google’s implementation provided security, it created a silo.

Apple’s adoption of RCS in iOS 18 was a major step forward, but it was a cautious one. Apple implemented the Universal Profile 2.4, which brought features like typing indicators and high-quality media sharing to iPhone-to-Android chats. However, because the encryption standard was not yet finalized in the Universal Profile, Apple did not enable E2EE for these cross-platform interactions. This meant that while the user experience was improved, the privacy guarantees were not on par with iMessage-to-iMessage conversations.

The RCS Universal Profile 3.0 solves this dilemma. It defines a standardized way for devices to exchange encryption keys and secure messages using the MLS protocol. This standard is vendor-agnostic, meaning it is not owned by Google, Apple, or any single carrier. It is an industry-agreed method for securing data in transit.

We are now observing that Apple is not merely waiting idly. Code analysis of recent iOS builds suggests that engineers are laying the groundwork for MLS support. This is not a superficial toggle switch; it involves deep integration into the Apple Messages framework. The implementation requires a sophisticated handshake mechanism where an iPhone and an Android device (or any other RCS-compliant device) can negotiate a shared secret key that neither the service provider (Apple or Google) nor the carrier can decipher.

Evidence of Implementation in iOS Development

Our team has been analyzing the telemetry and code strings emerging from beta versions of iOS, and the signs are unmistakable. While the full public rollout may still be pending, the architectural prerequisites for standardized RCS encryption are being constructed within the operating system.

The evidence lies in the evolution of the DaemonMessages framework and the iMessage infrastructure. Historically, Apple’s messaging stack was built entirely around the proprietary Apple Push Notification service (APNs) and the Apple ID ecosystem. Introducing RCS requires a parallel track that handles the GSMA standards. We are seeing references to “rcs_encryption” and “mls_configuration” within internal logs.

This indicates that Apple is developing a dual-mode encryption engine. One mode remains the classic E2EE used for iMessage (based on the Signal Protocol), and the new mode will handle MLS-encrypted RCS messages. The complexity here lies in the key distribution. For iMessage, keys are exchanged via Apple’s servers using public-key cryptography tied to Apple IDs. For RCS, keys must be exchanged via the RCS server infrastructure (often handled by carriers or Google’s Jibe platform) while maintaining the same level of privacy.

Furthermore, the implementation must handle backward compatibility. If an iPhone user sends a message to an Android device that does not support the Universal Profile 3.0 encryption standard, the system must gracefully downgrade to standard RCS (without E2EE) or SMS, without crashing or exposing user data. We are seeing signs of logic gates in the code designed to test the recipient’s capabilities before initiating the encryption handshake.

The Impact on User Privacy and Security

The primary benefit of this implementation is the elevation of privacy standards for cross-platform communication. Currently, when an iPhone user texts an Android user via RCS (or SMS), the metadata and content are generally visible to the mobile carrier and, in some cases, to the RCS server provider (e.g., Google). While carriers are regulated entities, the lack of encryption still presents a theoretical vulnerability.

Once MLS-based E2EE is active, the message content is locked before it leaves the sender’s device and can only be unlocked on the recipient’s device. This renders the data unreadable to intermediaries. For users who prioritize privacy, this is a massive upgrade. It effectively democratizes secure messaging, removing the exclusivity that iMessage has held for over a decade.

We must also consider the regulatory pressure surrounding this change. With regulations like the Digital Markets Act (DMA) in the European Union forcing Apple to open up its ecosystem, the move toward standardized encryption serves two purposes. First, it complies with the demand for interoperability. Second, by adhering to a rigorous, industry-standard encryption protocol (MLS), Apple can argue that it is maintaining high security standards even while opening doors to competitors. It allows Apple to maintain its “privacy-first” branding while playing nice with the broader mobile ecosystem.

RCS Universal Profile 3.0 and the MLS Protocol

To understand why this specific standard matters, we must look at the Messaging Layer Security (MLS) protocol. MLS is an IETF (Internet Engineering Task Force) standard designed to provide efficient, asynchronous group encryption. Unlike older protocols, MLS is designed for the modern web, supporting large groups and reducing the computational overhead required to encrypt messages.

The RCS Universal Profile 3.0 leverages MLS to ensure that messages are secure not just in transit, but at rest on the server, in a way that the server cannot read them. This is a significant technical achievement. It moves RCS away from the older OTR (Off-the-Record) or Signal Protocol implementations (though Signal remains the gold standard for many, MLS is gaining rapid adoption for its scalability).

We are observing that Apple’s implementation will likely rely on the libmls library, an open-source reference implementation of the MLS protocol. By integrating this library into the iOS secure enclave environment, Apple ensures that cryptographic operations remain isolated from the main processor, adding an extra layer of hardware-based security.

The standard also addresses forward secrecy and post-compromise security. This means that even if a user’s device is compromised at a specific point in time, past messages remain secure, and future messages can be secured once the compromise is removed. This level of security is currently only available in iMessage and encrypted RCS between Android devices. Extending it to the Apple-Android bridge is the final piece of the puzzle.

Timeline and Availability: When Can Users Expect It?

A critical question facing the industry is the timeline for deployment. It has been nearly a year since the GSM Association published the RCS Universal Profile 3.0. While Apple is not known for rushing features to market—often preferring to delay until the implementation is polished—signs point to a rollout in the near future.

Based on the development cycles of iOS, we anticipate that support will be formally introduced in a major iOS update, likely iOS 18.5 or iOS 19. Apple typically introduces significant feature updates during their Worldwide Developers Conference (WWDC) in June, with point releases following throughout the year.

The current code findings suggest that the feature is in an active development phase. It is not yet enabled by default in beta builds, indicating that Apple is still refining the handshake mechanism and ensuring it does not drain battery life or consume excessive data. The complexity of coordinating with carrier networks globally adds another layer of delay. Apple requires carrier certification for RCS features, as the protocol relies heavily on carrier network configurations.

We expect a phased rollout. Initially, the feature may be limited to specific regions or carriers that have fully upgraded their infrastructure to support the Universal Profile 3.0. However, given the global nature of the GSMA standards, a worldwide expansion will likely follow quickly once the initial bugs are ironed out.

The End of the “Blue Bubble vs. Green Bubble” Divide?

For years, the visual distinction between blue bubbles (iMessage) and green bubbles (SMS/MMS) has been a cultural phenomenon, often cited as a source of social friction, particularly among younger users. With the adoption of RCS and subsequently E2EE, the visual experience will change.

When iPhone-to-Android messaging transitions to RCS, the bubbles will likely remain green to distinguish iMessage from external messaging, but the features within those bubbles will transform. Users will see high-resolution images, video sharing, group chats that actually work, and typing indicators. Most importantly, they will see encryption indicators.

We anticipate that Apple will introduce a visual cue—perhaps a lock icon or a specific label—indicating that the conversation is encrypted. This is crucial for user education. Users need to know that their cross-platform conversations are now secure. This visual shift will slowly erode the stigma associated with green bubbles, shifting the narrative from “low quality” to “universal and secure.”

While the blue bubble exclusivity will technically remain, the functional gap will be virtually closed. This forces the market to focus less on the color of the bubble and more on the ecosystem features that truly matter, such as FaceTime, AirDrop, and Continuity, which remain unique to Apple.

Carrier Involvement and Network Requirements

The transition to standardized RCS encryption is not solely an Apple or Google endeavor; it requires active participation from mobile network operators (MNOs). Unlike iMessage, which operates over the internet via data connections, RCS is deeply integrated with carrier networks via the IP Multimedia Subsystem (IMS).

For E2EE to function, carriers must support the necessary RCS endpoints that facilitate the MLS key exchange without storing the keys. Many carriers globally are still in the process of upgrading their networks to support the Universal Profile 3.0. Some carriers have relied on Google’s Jibe cloud for RCS hosting, while others have built their own servers.

We are monitoring the alignment of major carriers. In the US, for example, the three major carriers (Verizon, AT&T, and T-Mobile) have committed to the RCS Universal Profile, but the encryption layer adds a new requirement. Apple’s implementation will likely pressure these carriers to finalize their support for MLS. The synergy between Apple’s hardware security and the carrier’s network infrastructure will define the reliability of the encrypted RCS connection.

If a carrier does not support the encryption standard, the fallback mechanism will revert to standard RCS or SMS. This fragmentation highlights the complexity of a global rollout. However, Apple’s influence in the market is such that their adoption of the standard acts as a catalyst, forcing carriers to upgrade their systems to meet user expectations.

Comparison with Existing Messaging Protocols

To fully grasp the significance, we must compare RCS with MLS against other prevalent protocols.

• iMessage (Signal Protocol): Remains the benchmark for Apple-to-Apple communication. It offers perfect forward secrecy and is integrated deeply into the OS. However, it is closed-source and proprietary to Apple.
• WhatsApp (Signal Protocol): Uses the Signal Protocol for E2EE. It is the most popular messaging app globally but operates within a walled garden (the WhatsApp app).
• SMS/MMS: Unencrypted, limited in features, and vulnerable to interception. This is the legacy standard that RCS is replacing.
• RCS (MLS): The new standard. It offers the feature set of iMessage/WhatsApp with the universality of SMS. While the MLS protocol is relatively newer than the Signal Protocol, it is designed for modern group messaging efficiency and has been vetted by the IETF.

Apple’s move to support RCS with MLS does not mean they are abandoning their proprietary iMessage encryption. Rather, they are adding a new protocol layer. The iMessage app will essentially become a dual-protocol client. This is a complex engineering feat. The app must handle two different encryption libraries, two different network transports (APNs for iMessage, Mobile Data/IP for RCS), and two different server infrastructures.

The Role of iOS 18 and Future Updates

The groundwork for this feature began with iOS 18. While iOS 18 introduced basic RCS support, it served primarily as a bridge for better media sharing and reliability. It did not include the encryption component. The code strings we are seeing now point toward a subsequent update, possibly iOS 18.4 or 18.5, where the encryption flags are toggled on.

Apple’s development strategy is iterative. They rarely release a massive, untested feature all at once. The current beta cycles are likely testing the stability of the MLS library integration. We are looking for specific API endpoints, such as RCSipher or MLSSession, to appear in the public SDK. Once these appear, developers can start building apps that interact with the encrypted RCS layer.

The implications for the Magisk Modules community and Android enthusiasts are also notable. As Apple adopts E2EE RCS, the pressure is on Android custom ROM developers and messaging apps to ensure full compliance with the standard. For users who root their devices or use custom messaging clients, the ability to send and receive encrypted RCS messages to iPhones will depend on how well those third-party clients implement the MLS standard.

Security Challenges and Implementation Hurdles

Despite the optimism, we must acknowledge the challenges in implementing standardized encryption. The primary hurdle is key synchronization. In a multi-device ecosystem like Apple’s (where a user may have an iPhone, iPad, and Mac), iMessage keys are synced via iCloud Keychain (with Advanced Data Protection). For RCS, the key management is handled differently.

Apple must ensure that an encrypted RCS message sent to an iPhone is also accessible and readable on the user’s iPad or Mac. This requires a secure synchronization method that does not compromise the end-to-end nature of the encryption. It is a complex problem: how do you share a decryption key across devices without it passing through a server that could be compromised?

Furthermore, there is the issue of message fallback. If a user is offline and sends an RCS message, it might be stored temporarily on a server. With E2EE, the server cannot read the message, but it must still route it to the recipient. Apple’s implementation must handle these “store and forward” scenarios securely. Additionally, if the recipient is offline for an extended period, key expiration could become an issue. The MLS protocol has mechanisms for this, but implementing them correctly in a consumer-facing product requires rigorous testing.

Broader Implications for the Tech Industry

Apple’s work on RCS encryption is a microcosm of a larger trend: the convergence of communication standards. For decades, the tech industry has been defined by walled gardens. Companies built proprietary systems to lock users into their ecosystems. While this drives innovation, it also creates friction.

The adoption of RCS with E2EE signals a shift toward interoperability. It acknowledges that users value communication over the specific platform they use. By adopting an industry standard, Apple is setting a precedent. It suggests that even the most封闭的 ecosystems must eventually open up to universal standards when it comes to core utilities like messaging.

This move also benefits security researchers. By standardizing on MLS, the protocol will be scrutinized by experts from Apple, Google, and independent security firms simultaneously. A vulnerability found in one implementation likely affects the others, leading to faster patching and a more robust protocol overall. The days of security through obscurity are fading; modern security relies on open, tested standards.

What This Means for iPhone and Android Users

For the average user, the transition will be seamless but transformative. An iPhone user will open their Messages app and text an Android user. Behind the scenes, the phone will detect the recipient’s capabilities. If the Android device supports RCS Universal Profile 3.0, the phone will initiate an MLS handshake.

The user will see the chat bubble turn from a standard SMS grey to a feature-rich RCS interface. They will be able to send high-quality photos without compression. They will see when the other person is typing. And, crucially, they will know their conversation is private.

We expect Apple to include a setting in the Settings > Apps > Messages menu allowing users to toggle RCS on or off. There may also be a specific toggle for “RCS Encryption” or a visual indicator in the chat details view showing the encryption status (e.g., “Encrypted with MLS”).

For business users, this enhances security compliance. Cross-platform communication with colleagues using Android devices will no longer be a weak link in the security chain. This is particularly relevant for industries with strict data privacy requirements, where unencrypted SMS has long been a liability.

The Future of Messaging Standards

As we look ahead, the integration of RCS with MLS is just the beginning. The GSMA is already working on RCS 3.0+ features, which may include encrypted file transfers, better location sharing, and perhaps even video calling integration (though FaceTime remains separate).

We also foresee the eventual merger of SMS and RCS at the network level. Eventually, carriers may phase out SMS entirely in favor of IP-based RCS, making the distinction moot. However, that transition is years away due to the billions of legacy devices still in circulation that rely solely on SMS.

For now, Apple’s work on encryption support is the most significant development in the messaging space in recent years. It promises