Sovatun Guide

RCS Messages on Public Wi-Fi: What a VPN Does and Doesn't Change on iPhone

RCS is the default iPhone-to-Android texting channel — but it isn't end-to-end encrypted. Here's what a VPN on public Wi-Fi actually protects, and what it can't.

Answer First

Definition: RCS (Rich Communication Services) is the modern messaging standard your iPhone now uses to text Android phones. With iOS 18, Apple added RCS support to Messages: when you message someone who isn’t on iMessage, your iPhone sends an RCS message over the internet instead of falling back to the old SMS/MMS standard. Apple’s implementation uses the GSMA Universal Profile — the same interoperable standard carriers and Android messaging apps have used for years.

Why: It matters on public Wi-Fi because RCS is a data protocol, not a cellular one. It runs over your internet connection, so it works on Wi-Fi — and its security model is different from iMessage. iMessage is end-to-end encrypted (E2EE). Apple’s RCS implementation is not. That single difference defines what a VPN can and cannot do for your texting.

Example: You’re on airport Wi-Fi messaging a friend with an Android phone. Without a VPN, the network operator sees an encrypted stream between your iPhone and your carrier’s RCS servers: they can’t read the words, but they see that you’re messaging, when, and how much. Turn on a VPN and the operator sees only an encrypted tunnel to the VPN server, with no way to tell it’s RCS. What the VPN doesn’t change: your carrier still receives the message content, because the RCS connection to the carrier is exactly where that TLS encryption ends.

Think in layers: a VPN covers the Wi-Fi hop between your phone and the internet — not the carrier hop, and it is not a substitute for end-to-end encryption.

Key Facts

  • With iOS 18 (2024), Messages on iPhone can send RCS to non-Apple devices, with carrier support rolling out since — availability still depends on your carrier.
  • RCS travels as data over your internet connection, so it works over Wi-Fi with no cell signal — something SMS could never do.
  • Apple’s RCS uses the GSMA Universal Profile without end-to-end encryption. iMessage is E2EE; RCS on iPhone is not.
  • In transit, RCS is protected by TLS between your iPhone and your carrier’s servers — the same encryption family that secures HTTPS — so eavesdroppers can’t read the words.
  • On public Wi-Fi, what’s left for the network operator to observe is mostly metadata: who you message, when, and how much. That metadata is what a VPN hides.
  • A VPN covers the Wi-Fi hop only; nothing protects message content from the carrier — the RCS endpoint.

Expert Explanation

The three messaging tiers on iPhone

Messages on iPhone has a clear priority order: when both people use iMessage, messages are end-to-end encrypted and route through Apple’s infrastructure. When the recipient is on Android — or iMessage isn’t available — Apple’s documentation describes the fallback: RCS first, then SMS/MMS. Since iOS 18, your iPhone-to-Android texts are RCS whenever your carrier supports it, which is why the green-bubble standard quietly became the default iPhone-to-Android channel.

Why RCS changed the public Wi-Fi question

Before RCS, an iPhone-to-Android text on Wi-Fi was still an SMS: it traveled over the cellular network, and the Wi-Fi network you were on didn’t matter. RCS flips that: because it’s an IP-based protocol, the message leaves your phone over whatever internet connection you’re using — including the coffee shop’s Wi-Fi. That puts the network operator in the path of your texting for the first time, and “can they read it?” now depends on layers.

The layers: Wi-Fi hop, carrier hop, device-to-device

Who is in the pathWithout a VPNWith a VPN
Public Wi-Fi operatorSees TLS-encrypted traffic to your carrier’s RCS servers plus metadata (when, how much). Cannot read the words.Sees only an encrypted tunnel to the VPN server — no RCS, no carrier destination, no timing.
Your carrier and its RCS infrastructureSees message content and metadata — the TLS connection ends at the carrier, and Universal Profile RCS is not E2EE.Identical — a VPN reroutes traffic but doesn’t re-encrypt it for the carrier.
The VPN providerN/A.Sees that you use the service and the tunnel’s metadata, governed by the provider’s own privacy practices.
Recipient’s phone and messaging appReceives the message through their own carrier’s RCS infrastructure.Unchanged.

What the Wi-Fi operator can and can’t see

The words are already protected: RCS transport uses TLS between your iPhone and your carrier’s servers, so a Wi-Fi operator — or anyone sniffing the network — can’t read your message text. The FTC makes the same point about public Wi-Fi: modern encryption stops network eavesdroppers; its limits show up at the destination, not on the wire. CISA’s wireless guidance likewise treats unencrypted traffic as the risk on public networks.

What encryption doesn’t hide is the envelope: the destination, the timing, and the volume of your messaging. That envelope is exactly what a VPN removes — once your traffic is inside a VPN tunnel, the operator sees one opaque connection to one server and nothing about the RCS inside it.

What a VPN changes — and what it can’t

A VPN’s job on public Wi-Fi is to hide your connection and its metadata from the network operator. That’s a real, bounded benefit: the operator no longer sees that you’re messaging, when, or how much, and can’t link your traffic to your carrier’s RCS service.

The honest limits matter just as much. A VPN does not add E2EE to RCS: after traffic exits the VPN server, it travels to your carrier’s RCS infrastructure the same way it always did, and the carrier still sees the content. A VPN also does not prevent phishing, malware, or account compromise — no tunnel makes a login-code request safe. And a VPN is only as trustworthy as its operator — not every “VPN” is what it claims, as the Onavo episode showed, and Apple has pushed misbehaving VPN apps off the App Store before. It’s worth knowing how a VPN behaves on iPhone, including how it handles local network access.

For our part, SovaTun is an iPhone-focused VPN for everyday connection privacy, and public Wi-Fi is exactly the scenario it targets. But “it covers the Wi-Fi hop” is the whole claim — not “it encrypts your RCS messages end to end.”

Decision Framework

Use a VPN for RCS on public Wi-Fi when:

  • You’re on an untrusted network — airport, hotel, cafe — and you’d rather the operator not see you messaging your carrier, when, or how much.
  • You’re doing anything else sensitive on that network (mail, banking, logins) and want one tunnel for it all.
  • You’ve picked a provider whose privacy practices you’ve actually read, and you know what it logs.

Don’t expect a VPN to:

  • Add E2EE to RCS, or hide message content from your carrier.
  • Protect you from phishing texts, malware, or stolen credentials.
  • Make RCS work where your carrier hasn’t enabled it, or fix a network that blocks the RCS data connection.

If RCS content privacy is the goal, the only real answer is a channel that is actually end-to-end encrypted: iMessage (iPhone to iPhone) or an E2EE messaging app. A VPN is the wrong tool for that job.

Key Takeaways

  • RCS is now the default iPhone-to-Android messaging channel since iOS 18; it works over Wi-Fi because it’s an IP-based data protocol.
  • Apple’s RCS uses the GSMA Universal Profile with no end-to-end encryption — unlike iMessage.
  • On public Wi-Fi, TLS already stops the network operator from reading RCS message words; a VPN adds protection for the connection and its metadata.
  • A VPN covers the Wi-Fi hop, not the carrier hop: the carrier still sees RCS content, and no VPN is a substitute for E2EE.
  • Choose a VPN like any privacy tool: check what the provider actually logs, and keep expectations bounded.

FAQ

Does RCS work on public Wi-Fi with an iPhone?

Yes. RCS messages travel as data over your internet connection, so they work on Wi-Fi — with no cellular signal needed, unlike SMS. You need iOS 18 or later and an RCS-enabled carrier. A VPN doesn’t change how RCS works; it only changes what the network operator can observe.

Is RCS on iPhone end-to-end encrypted like iMessage?

No. iMessage is end-to-end encrypted — Apple’s security documentation says so. Apple’s RCS implementation uses the GSMA Universal Profile without E2EE, so content is readable at the carrier’s RCS infrastructure in transit. Some Android RCS apps add E2EE, but only when both people use that same app — not in the iPhone-to-Android cross-platform case.

Can the Wi-Fi operator read my RCS messages?

They can’t read the words either way: RCS transport is TLS-encrypted between your iPhone and your carrier’s servers. Without a VPN, though, the operator can still see the envelope — that you’re messaging your carrier’s RCS service, when, and how much. A VPN hides that envelope inside an encrypted tunnel to the VPN server.

Does a VPN make RCS private?

Partially, and only on the Wi-Fi hop. A VPN hides your connection and its metadata from the network operator. It does not add end-to-end encryption, and it does not hide message content from your carrier, because the RCS connection ends at the carrier’s servers. For content-level privacy, use iMessage with another iPhone user or an E2EE messaging app.

Sources

  • Apple Support — “What is the difference between iMessage, RCS, and SMS/MMS?” (support.apple.com/en-us/104972): how Messages chooses between iMessage, RCS, and SMS/MMS.
  • Apple Support — “Turn on RCS messaging on your iPhone” (support.apple.com/en-us/122195): RCS availability with iOS 18+ and carrier requirements.
  • Apple Platform Security — “iMessage security overview” (support.apple.com/guide/security/imessage-security-overview-secd9764312f/web): documents iMessage’s end-to-end encryption.
  • Apple Platform Security — “VPN security” (support.apple.com/guide/security/vpn-security-sec802e8ab55/web): what a VPN does and doesn’t do on Apple platforms.
  • FTC — “Are Public Wi-Fi Networks Safe? What You Need To Know” (consumer.ftc.gov/articles/are-public-wi-fi-networks-safe-what-you-need-know): how encryption protects traffic on public Wi-Fi, and where that protection ends.
  • CISA — “Securing Wireless Networks” (cisa.gov/news-events/news/securing-wireless-networks): risks of unsecured wireless networks, including sniffing and evil-twin attacks.