iMessage vs RCS vs SMS, feature by feature
Ten things people actually care about, across four ways a text can travel. The third column is the one that matters and the one most comparisons leave out.
Most comparisons have three columns: iMessage, RCS, SMS. That hides the important case. "RCS supports reactions" is true and useless if what you need to know is whether a reaction survives the trip from an iPhone to a Pixel. So we split RCS in two — Android-to-Android, and cross-platform — because those two are genuinely different, and the second is where things break.
Read receipts
- iMessage (iPhone ↔ iPhone) Depends unverified Carried by the protocol, but only if the other person has read receipts switched on.
- RCS (Android ↔ Android) Depends unverified Same idea: supported, but each person controls whether theirs are sent.
- RCS (iPhone ↔ Android) Depends unverified Supported in both directions, and still off for anyone who turned it off.
- SMS / MMS Not available unverified SMS and MMS have no read receipt at all. Nothing to switch on.
Why: A read receipt is a separate signal the receiving app has to send back. SMS has no channel for it at all.
Typing indicator ("…")
- iMessage (iPhone ↔ iPhone) Works unverified Shows while the other person is composing.
- RCS (Android ↔ Android) Works unverified Shows while the other person is composing.
- RCS (iPhone ↔ Android) Works unverified One of the first things people notice working after RCS connects.
- SMS / MMS Not available unverified No live channel exists, so there is nothing to display.
Why: Like read receipts, this is a live signal that needs a data session open between both apps.
"Delivered" status
- iMessage (iPhone ↔ iPhone) Works unverified Confirms the message reached the device, not that it was read.
- RCS (Android ↔ Android) Works unverified Same meaning as on iMessage.
- RCS (iPhone ↔ Android) Works unverified Works across platforms once the chat is actually on RCS.
- SMS / MMS Depends unverified Only if both carriers support and forward delivery reports. Many do not.
Why: iMessage and RCS get an acknowledgement from the receiving device. SMS only ever gets one from the network, and only if the carrier passes it on.
Full-quality photos and video
- iMessage (iPhone ↔ iPhone) Works unverified Sends at close to original quality.
- RCS (Android ↔ Android) Works unverified Much higher ceiling than MMS, though a limit still exists.
- RCS (iPhone ↔ Android) Works unverified This is the single biggest visible difference from falling back to MMS.
- SMS / MMS Degraded unverified Heavy compression to fit the MMS size cap. This is the classic blurry photo.
Why: MMS was designed around a payload of roughly a megabyte, so anything bigger gets crushed to fit. RCS raises the ceiling by a lot but does not remove it.
Reactions / Tapbacks
- iMessage (iPhone ↔ iPhone) Works unverified Attaches to the original message.
- RCS (Android ↔ Android) Works unverified Attaches to the original message.
- RCS (iPhone ↔ Android) Works unverified Believed to attach properly rather than arrive as text — this is the cell we most want to confirm.
- SMS / MMS Degraded unverified Arrives as a separate message reading "Liked a photo" or similar.
Why: A reaction is metadata attached to an earlier message. If the protocol cannot attach it, the sending app describes it in words instead.
Edit and unsend
- iMessage (iPhone ↔ iPhone) Works unverified Within Apple’s own time limits.
- RCS (Android ↔ Android) Depends unverified Depends on the app version on both sides.
- RCS (iPhone ↔ Android) Not available unverified Understood not to carry between an iPhone and an Android phone.
- SMS / MMS Not available unverified Once an SMS is sent it is gone. There is no recall.
Why: Editing means reaching back into a message already on someone else's device. That only works where both ends run the same messaging system.
Naming a group and leaving it
- iMessage (iPhone ↔ iPhone) Works unverified Name it, add people, leave it.
- RCS (Android ↔ Android) Works unverified Works when everyone in the group is on RCS.
- RCS (iPhone ↔ Android) Depends unverified Only if every participant is RCS-capable. One person who is not drops the whole group to MMS.
- SMS / MMS Not available unverified No name, no leaving — you can only mute it.
Why: A group with a name and a membership list is a real object on a server. An MMS group is just a list of numbers on every message.
Voice messages
- iMessage (iPhone ↔ iPhone) Works unverified Plays inline in the thread.
- RCS (Android ↔ Android) Works unverified Plays inline in the thread.
- RCS (iPhone ↔ Android) Works unverified Believed to play inline on both sides.
- SMS / MMS Degraded unverified Arrives as an attachment to open rather than a clip to tap.
Why: A voice clip is just a file. The question is whether the protocol can carry a file of that size and play it inline.
Location sharing
- iMessage (iPhone ↔ iPhone) Works unverified Both a one-off pin and continuous sharing.
- RCS (Android ↔ Android) Works unverified Both a one-off pin and continuous sharing inside the same app.
- RCS (iPhone ↔ Android) Depends unverified A static pin generally travels. Continuous, live sharing usually does not.
- SMS / MMS Degraded unverified Becomes a map link in the message body.
Why: Sending a pin once and sharing your position continuously are different features, and only the first travels well between platforms.
Long messages arriving in one piece
- iMessage (iPhone ↔ iPhone) Works unverified Length is not a meaningful constraint.
- RCS (Android ↔ Android) Works unverified Length is not a meaningful constraint.
- RCS (iPhone ↔ Android) Works unverified Length is not a meaningful constraint.
- SMS / MMS Degraded unverified Split into segments; emoji and accents cut the per-segment limit sharply.
Why: SMS carries a fixed, small number of characters per message, so anything longer is cut into segments and reassembled — badly, sometimes.
Version facts on this page: not verified yet — the site-wide verification pass has not been completed. See the update log
How to read the four states
- Works — the feature does what you expect, with no asterisk.
- Degraded — something arrives, but not the thing you sent. A photo arrives at a fraction of its resolution; a reaction arrives as a sentence. This is the state that causes the most confusion, because nothing looks broken.
- Not available — the protocol has no way to carry it, so it simply does not happen.
- Depends — the protocol can carry it, but something outside the protocol decides whether it does: a setting the other person controls, or which carrier they are on.
Where these answers come from
Every claim on this page is tied to an entry in our verification table, and every entry carries its own confidence level. That is the whole point of the site: articles about this get written once and then quietly rot, and we would rather show you which parts we have actually checked than sound uniformly confident about all of them.
| ID | What we need to know | Status | Source |
|---|---|---|---|
| F4 | Reactions are believed to survive between an iPhone and an Android phone on RCS, but early iPhone RCS releases sent them as plain text and we have not checked which release changed that. 🔴 2026-09-02 verification attempt — still unverified, and we now know why. Apple documents what RCS carries in two places (support.apple.com/en-us/104972 and /122195) and both list the same set: “texts, high resolution photos and videos, links, and more”, plus “delivery and read receipts and typing indicators”. Reactions and Tapbacks appear in neither list. So Apple does not document reaction interoperability at all, and the introduction version is reported only in the trade press. Do not promote this to verified on press coverage — either Apple documents it or the fact stays here. | Pending verification | Not attached yet |
| F5 | Apple’s iPhone User Guide states plainly that “SMS, MMS, or RCS text messages can’t be edited or unsent”. The one exception Apple gives is a group conversation that still contains at least one iMessage user — that is an iMessage thread, not the cross-platform RCS case this fact covers. | Confirmed | Primary source |
| F8 | Voice clips are believed to carry over RCS. Live location is a different feature from sending a static pin and the two behave differently across platforms. 🔴 2026-09-02 verification attempt — still unverified, same reason as F4. Apple’s two RCS capability pages list “texts, high resolution photos and videos, links, and more” plus receipts and typing indicators; neither audio messages nor location appear. Google’s RCS overview page (support.google.com/messages/answer/13508703) says only “Share high-resolution photos and videos” and does not mention either feature. Neither vendor documents the cross-platform behaviour, and “and more” is not a source. The honest reading is that the value below is an assumption. | Pending verification | Not attached yet |
| F9 | The ceiling is set by the profile and by each carrier, so a single number is already a simplification. 🔴 2026-09-02 verification attempt — still unverified. Neither Apple nor Google publishes an RCS attachment ceiling; both describe the capability qualitatively (“high resolution photos and videos”) and stop there. The 100 MB figure circulates widely but traces back to carrier and vendor marketing, not to a published Universal Profile limit. Since AT&T’s MMS page shows carriers do publish numbers when they have them (see F21), the absence here is meaningful: treat the ceiling as carrier-set and unpublished rather than as 100 MB. | Pending verification | Not attached yet |
| F10 | Apple’s iPhone User Guide gives the path as “Go to the Settings app… Tap Apps, then tap Messages… Turn on Send Read Receipts”, and Google’s Messages help gives “tap your Profile picture or Initial → Messages settings → RCS chats → Send read receipts”. Both match what we had. Reciprocity is settled by Apple in one sentence: “You can’t turn on read receipts for anyone but yourself. To receive read receipts when your messages are opened, ask the recipient to turn them on.” Sending and receiving are independent, so reciprocal is false. 🔴 The default states are deliberately null: neither Apple nor Google states a default anywhere in their documentation, so we do not claim one. The screen tells the reader what their own setting is; a guessed default would be the only unsourced number on the page. | Confirmed | Primary source |
| F21 | AT&T publishes the figure directly: “The AT&T mobile broadband network delivers picture, video, or audio messages of up to 1MB”, and “Larger media file attachments are compressed before sending to keep the message size below 1MB.” AT&T also states the rule that makes a single number misleading: “The maximum size for sending and receiving picture, video, or audio messages is also dependent upon the recipient’s device and the limitations of other carriers’ networks (e.g., other carriers may have a lower message size limit than AT&T).” 🔴 Scope note — the claim was narrowed on 2026-09-02. It used to say “US major carriers” (plural). Verizon serves its figure from JavaScript and T-Mobile returns 403 to non-browser clients, so we could not read either as a primary source. Rather than publish a number for carriers we could not check, the fact now carries the one published figure we can cite plus the lower-of-the-two rule, which is the part that actually changes what a reader should do. Add carriers to sourcedCarriers only with a URL that states the number. | Confirmed | Primary source |
| F22 | All four numbers now come out of the specification text rather than memory. ETSI TS 123 038 V17.0.0 (= 3GPP TS 23.038 Rel-17), clause 6.1.2.1.1, does the first two arithmetically in its own words: “Therefore, in 140 octets, it is possible to pack (140x8)/7=160 characters”, and for the other alphabet, “the message can consist of up to 140 octets, i.e. up to 70 UCS2 characters”. ETSI TS 123 040 V17.2.0 (= 3GPP TS 23.040) supplies the 140: “The text messages to be transferred by means of the SM MT or SM MO contain up to 140 octets.” The concatenated pair follows from clause 9.2.3.24.1, where the 8-bit-reference concatenation information element carries three octets of data — “Concatenated short message reference number”, “Maximum number of short messages in the concatenated short message”, and the sequence number — which sit behind a UDHL, an IEI and an IEDL octet. That is 6 octets of header, leaving 134: (134x8)/7 = 153 septets, and 134/2 = 67 UCS2 characters. Cite 23.038 as the source URL because it is the document that states the character counts; 23.040 is the supporting reference for the 140-octet payload and the concatenation header. | Confirmed | Primary source |
| F24 | Google’s RCS FAQ: “If all the participants don’t have RCS chats turned on, you still may be able to create SMS/MMS groups.” Google’s RCS overview page states the requirement from the other side: “everyone in the Google Messages conversation must turn the RCS chats on.” The behaviour when someone is added mid-thread is still not documented by Google. | Confirmed | Primary source |