On paper these are the same product. In an integration they have almost nothing in common — different suppliers, different approval processes, different cost models, different populations reached.
The differences that decide it
| iMessage (third-party API) | RCS | |
|---|---|---|
| Official status | None — Apple sanctions nothing | GSMA standard, carrier-supported |
| Who you buy from | Specialist providers | Twilio, Telnyx, Sinch, other CPaaS |
| Approval | Sign up, minutes | Brand and agent verification, days to weeks |
| Reaches | iPhone users, as a blue bubble | Android users with RCS enabled |
| Cost model | Per line per month | Per message |
| Branding | A phone number and a name | Verified brand, logo, colour |
| Rich UI | Text, media, reactions | Carousels, suggested replies, cards |
| Fallback | Provider-side to SMS | Automatic to SMS |
The point people get wrong
Apple adopting RCS did not make iPhones reachable by your RCS agent
Apple supports RCS for messaging between iPhone and Android, which improved cross-platform texting considerably. It does not mean your verified RCS business agent delivers a rich, branded experience into an iPhone the way it does on Android, and it emphatically does not make it a blue bubble. Verify current behaviour with your CPaaS rather than assuming — and never assume RCS covers your iPhone segment.
This matters because in the US roughly half of mobile users are on iPhone. An RCS-only strategy addresses the other half well and the iPhone half through SMS fallback — which is exactly the green-bubble experience you were trying to escape.
Integration effort
iMessage is the faster path by a wide margin. Sign up, get a key, POST a message, and you are live the same afternoon. There is no approval, because there is no authority granting one.
RCS requires brand verification and agent approval through your CPaaS and the carriers. Days to weeks, with documentation about your business. In exchange you get a verified brand identity — logo, colour, a checkmark — which is a genuine trust signal that iMessage does not offer, because on iMessage you are a phone number.
Cost at volume
| Monthly volume | iMessage (one line) | RCS (per message) |
|---|---|---|
| 500 | Flat — a line | Cheap |
| 5,000 | Flat — likely still one line | Adds up |
| 50,000 | Multiple lines needed | Metered, and predictable |
iMessage's flat cost is a large advantage at low and medium volume and stops being one when your daily volume exceeds what a line can safely carry — at which point you are buying lines and the curve straightens. RCS is metered throughout and scales without a ceiling. The per-line arithmetic.
Risk
RCS is a standard with carrier backing and no ambiguity about whether you are allowed to use it. iMessage APIs are unofficial, and that risk does not go away with any vendor.
The counterweight is that iMessage is where the audience with the higher-value handsets actually is, and the channel is not yet saturated with commercial messaging. RCS is following the SMS path toward heavy marketing use, and the trust dividend will erode accordingly.
What most people should build
- Detect the platform. Most iMessage providers offer a lookup that tells you whether a number is reachable on iMessage.
- Route iPhone to iMessage. That is where the blue bubble does its work.
- Route Android to RCS, with SMS fallback underneath.
- Normalise the events. Delivered is delivered, read is read; do not leak two vocabularies into your application.
- Report on both together, or you will optimise one channel into a corner.
Many iMessage providers offer RCS and SMS fallback in one call, which collapses steps 2 and 3 at the cost of owning the routing decision yourself. That trade-off is the real architectural question here, and it is worth deciding deliberately rather than by default. The business-level comparison is here.