Apple turned on RCS in iOS 18, and the demos are genuinely nice: verified brand logos, high-res images, tappable buttons, typing indicators, read receipts. If you saw one of those and thought "we need to switch our whole program to this" — slow down. The demo and the deliverable reality are two very different things right now.
Full disclosure: I work for Ready, an SMS platform. So you'd expect me to talk down the shiny new format. But I'd rather give you the honest version, because the honest version still ends with "keep SMS as your backbone" — and it's better to know why than to take my word for it.
Here's the grounded state of things, and a decision framework for the "should we switch?" conversation you're probably about to have.
What RCS actually is (and what iPhone support really changed)
RCS — Rich Communication Services — is the successor to SMS that carriers have been half-launching for a decade. It runs over data, not the old signaling channel, so it can carry images, carousels, buttons, and read receipts. Google's Android Messages has supported it for years via Google's Jibe backend.
The big 2024–2025 change: Apple added RCS support to iMessage's fallback layer. Before that, an Android RCS message to an iPhone degraded to a green-bubble SMS. Now iPhones can receive RCS from Android and, increasingly, from businesses.
What Apple did not do is hand you a business channel with a green light. Business RCS (the branded, verified sender kind — sometimes called RBM, RCS Business Messaging) is a separate track with its own onboarding, its own carrier-by-carrier availability, and its own approval queues. iPhone reception being live is a prerequisite, not the finish line.
The branded-sender verification is real — and it's a queue
The headline feature for businesses is the verified sender: your logo, your brand name, a color, a "verified" checkmark instead of an anonymous number. It's the thing that makes RCS feel legitimately different from a text.
But getting it means going through Google's verification (and the carriers') the same way you go through A2P 10DLC for SMS today. Brand vetting, use-case review, sample messages, agent registration. If you've been through 10DLC — and if you send SMS at scale you have — you know that process: it works, but it's a queue, not a switch.
If your 10DLC campaign has ever been approved and then throttled anyway, or rejected over a sample message you'll never send, you already understand the shape of RCS business onboarding. It is not faster or looser. It's a second registration on top of the one you already maintain.
The fallback problem nobody demos
Here's the operational killer, and it's the reason RCS can't be your only channel in 2026.
RCS delivery depends on:
- The recipient's device supporting it (getting there, but not universal)
- RCS being enabled on that device (many users, many defaults)
- A live data connection at send time
- The recipient's carrier having RCS interop turned on for your sender
Miss any of those and the message has to fall back to SMS. So you need an SMS path anyway. Every serious RCS deployment is really an RCS-with-SMS-fallback deployment. You're not replacing SMS — you're adding a richer layer on top of it and keeping SMS as the floor.
Which raises the honest question: if you're maintaining a compliant, deliverable SMS program regardless, how much is the rich layer worth today, for your specific use case?
Where RCS genuinely earns its keep — and where it doesn't
Not all messages benefit equally. A rough breakdown:
| Message type | RCS upside today | Verdict |
|---|---|---|
| Order confirmations, receipts | Logo + itemized card looks great | Nice-to-have; SMS already converts fine |
| Appointment reminders | Tappable confirm/reschedule buttons | Real UX win if your audience is RCS-ready |
| Two-factor / OTP codes | Verified sender reduces phishing confusion | Genuinely useful, but SMS OTP still dominant |
| Flash-sale blasts | Image carousels, buttons | High-friction to build; SMS + a good link still wins on reach |
| Customer support threads | Typing indicators, read receipts | Marginal; the reply is what matters |
The pattern: RCS is strongest for transactional, one-to-one, high-trust moments where a verified sender and a button reduce friction. It's weakest for broad reach, because the moment you send to a list of thousands, a meaningful chunk falls back to SMS — and then you've built two message versions to reach the same people SMS would've reached alone.
For appointment reminders specifically, the interactive-button case is real — but the timing and no-show math that makes reminders work doesn't change whether the button is native RCS or a plain SMS link. The channel is a garnish on a system that already works.
The cost and effort math is quiet but real
RCS pricing from carriers isn't standardized the way per-segment SMS is, and it varies by message type (basic vs. single-rich-card vs. conversational). I'm not going to invent numbers. But two costs are certain:
- Build cost. Rich cards, carousels, and button payloads are more work to author, test, and maintain than a 160-character text. You're building and QA-ing a second content format for the same campaign.
- Fallback cost. Every RCS message that degrades still gets billed as an SMS. So your RCS program carries the SMS cost floor plus whatever RCS adds on top for the messages that land natively.
Compare that to what a clean SMS setup costs today. On Ready, outbound SMS is $0.02/segment on Standard (0–50,000/mo), dropping automatically to $0.016/segment past 50,000 in a calendar month, plus a transparent $0.0045/segment carrier pass-through. A 5,000-contact reminder blast at one segment each is 5,000 × ($0.02 + $0.0045) = $122.50, fully predictable, no format branching. That predictability is worth something when you're budgeting.
And the 160-vs-153 character cliff still governs SMS cost — one thing RCS does sidestep, since rich messages aren't segment-billed the same way. If your messages are consistently long, that's a genuine point in RCS's favor worth tracking as pricing firms up.
What to actually do in 2026
A pragmatic sequence, in order:
- Keep SMS as your backbone. It reaches everyone, it's predictable, and the compliance and deliverability discipline you've built — 10DLC registration, quiet hours, opt-out handling — carries over. Don't dismantle a working system for a partial one.
- Fix the SMS fundamentals first. If your texts get content-filtered after approval or your shared-link shorteners get you blocked, RCS won't save you — those are sender-reputation problems that follow you across channels.
- Pilot RCS on one transactional flow. Pick something high-trust and low-volume — order confirmations, appointment confirms — where the verified sender and a button actually change behavior. Measure. Don't roll it out list-wide.
- Assume fallback, always. Author every RCS message with an SMS version that stands on its own. If it only works with the carousel, it's not ready to ship.
- Watch the interop maps. RCS business availability is still filling in carrier by carrier. Revisit quarterly. The answer that's "not yet" in Q1 2026 may be "yes" by Q4.
The practical takeaway
RCS on iPhone is a real milestone, and the branded verified sender is a legitimately good feature — for the right, narrow set of messages. But it's a richer layer on top of SMS, not a replacement for it. Every deployment needs an SMS fallback, which means SMS isn't going anywhere, which means the smart move is to keep your SMS program deliverable and disciplined while you pilot RCS on the flows that actually benefit.
Ready is an SMS platform first — we serve anyone sending text, from ecommerce to healthcare to nonprofits — and the boring truth is that a reliable SMS backbone is what makes an RCS experiment safe to run at all. If you want to get that backbone solid, with 10DLC handled in-app, quiet-hours enforcement, and automatic opt-out handling, you can start free with 2,500 credits — no card — or read the details on Ready SMS.
Adopt RCS where it earns its place. Just don't tear out the floor to do it.