The Protocol That Spent a Decade Waiting for Apple
RCS (Rich Communication Services) has existed in various forms since 2008. For most of that time, it was a carrier-driven initiative that went nowhere useful, fragmented implementations, no cross-carrier interoperability, and critically, no iOS support. Android users could send rich messages to other Android users on the same carrier. That was about the ceiling.
The technical picture changed materially in late 2023 when Apple announced iOS 18 would support RCS, and changed again when iOS 18 shipped in September 2024. For the first time, RCS operates as a near-universal messaging layer across Android and iOS in the United States. The addressable audience went from “Android users on supported carriers” to “essentially everyone with a smartphone.”
For developers and engineers building customer communication systems, this shifts RCS from an experimental channel to something worth taking seriously in production architectures. Platforms like Signalmash have started to reflect this shift by treating RCS as a first-class channel alongside SMS and MMS rather than an optional add-on.
How RCS Actually Works at the Protocol Level
RCS is built on top of IP Multimedia Subsystem (IMS) and uses SIP signaling with an MSRP (Message Session Relay Protocol) transport layer for content delivery. In practice, most developers interact with RCS through higher-level APIs rather than raw protocol implementation but understanding the stack matters for debugging and architecture decisions.
The key architectural difference from SMS is that RCS requires a persistent registration with the carrier’s RCS platform. Messages are delivered over data (LTE/5G/Wi-Fi) rather than through the traditional SS7 signaling network. This has meaningful implications:
- Delivery receipts are reliable. Unlike SMS where delivery confirmation is carrier-dependent and often unreliable, RCS provides read receipts at the protocol level.
- Message size limits are effectively gone. SMS is constrained to 160 characters (or 153 in multipart). RCS supports messages up to 8,000 characters, plus file attachments up to 100MB.
- Session state is maintained. RCS supports both single-message and session-based interactions, enabling back-and-forth conversations with persistent context.
For business messaging specifically, RCS operates through a separate “RCS Business Messaging” (RBM) layer managed by Google’s infrastructure in partnership with carriers. Brands interact via an API (based on the Universal Profile standard from the GSMA) that abstracts carrier relationships and handles routing.
The Sender Verification Architecture
One of the most technically interesting aspects of RCS Business Messaging is its trust model. Unlike SMS, where any number can assert any sender identity, RCS business senders go through a verification process that results in cryptographically backed identity attestation.
When a verified business sends an RCS message, the recipient’s messaging client checks the sender’s identity against a carrier-maintained registry. If verified, a checkmark badge is displayed similar to verified accounts on social platforms, but enforced at the protocol level rather than through a platform policy.
This has significant security implications. SMS phishing (smishing) is rampant precisely because there’s no reliable way for a recipient to verify sender identity. RCS’s verification model doesn’t eliminate fraud entirely, but it meaningfully raises the bar for spoofing verified business senders.
For developers building healthcare, financial services, or any compliance-sensitive application, sender verification also has audit trail implications. RCS message logs include verified sender metadata, which can be useful for regulatory compliance.
Fallback Architecture: Handling Mixed Environments
Production RCS deployments require a robust fallback strategy. Not every recipient will have RCS-capable devices or carriers, and network conditions can cause RCS delivery to fail even on capable devices. A production-grade implementation needs to handle this gracefully.
The standard pattern is a capability check before send:
- Query the carrier/RCS platform for the recipient’s RCS capability status
- If RCS-capable: send RCS message with rich content
- If not capable (or capability unknown): fall back to SMS/MMS
- If RCS delivery fails after a defined timeout: fall back to SMS
This capability check adds latency to the first message in a conversation typically 200-500ms depending on carrier infrastructure. For time-sensitive transactional messages, caching capability results per phone number (with appropriate TTL) is worth implementing.
The fallback itself requires content adaptation. An RCS message with action buttons and a carousel card needs to degrade gracefully to an SMS with a URL and plain text. Building content templates that work across both channels from the start is considerably easier than retrofitting SMS fallbacks onto RCS-only templates.
What Direct Carrier Connections Mean for Deliverability
Most businesses access RCS through aggregator platforms that sit between the application and carrier infrastructure. This is fine for low-to-medium volume use cases. At scale, the aggregation layer introduces meaningful tradeoffs.
Direct Tier-1 carrier connections bypassing aggregators and connecting directly to AT&T, Verizon, T-Mobile infrastructure offer lower latency, more reliable delivery confirmation, and better throughput for high-volume campaigns. They also provide more granular delivery analytics: instead of “delivered to aggregator,” you get actual carrier-level delivery status.
The tradeoff is complexity. Direct carrier relationships require negotiated agreements, dedicated infrastructure, and engineering investment that most organizations can’t justify unless messaging is a core product surface.
For teams evaluating CPaaS providers for RCS deployment, the carrier connection model is worth asking about explicitly: is the provider using direct carrier connections or aggregated routes? The answer affects deliverability SLAs, latency characteristics, and the quality of delivery analytics you’ll receive.
The Practical Takeaway for Engineering Teams
RCS is now worth including in your customer communication stack if:
- You’re sending transactional messages where completion rate matters (payments, confirmations, alerts)
- Your customer base is predominantly US-based (RCS adoption is highest in the US, UK, and parts of Europe)
- You need sender verification for compliance or trust reasons
- You have the engineering capacity to implement fallback logic properly
It is not worth the complexity if you’re doing simple notification delivery where SMS works fine, or if your customer base skews toward regions with low RCS adoption.
The protocol is production-ready. The infrastructure is in place. The engineering work is tractable. What’s left is the integration work and that’s firmly in scope for any team already managing a messaging pipeline.
Signalmash provides RCS Business Messaging APIs with direct Tier-1 carrier connections and automatic SMS fallback. Documentation and sandbox access at signalmash.com/developers.
Related Categories