About this site

Why this exists

You searched why your text went green and landed on a page selling a messaging API to a marketing team. That is why this exists.

That is not a rhetorical flourish. When we looked at what actually ranks for the questions ordinary people ask about this — why a message sent as SMS instead of RCS, whether a chat between an iPhone and an Android phone is encrypted, why one contact is green — most of the first page was business-to-business vendor pages aimed at marketing departments buying bulk messaging. Apple's own support documentation did not appear at all. The remaining results were a support-forum thread, a paid answers site, and somebody's personal newsletter.

That pattern usually means one thing: nobody has written the page properly. And in this case there is a good reason nobody has. The answer is different for every combination of phones, software versions and carriers, and it changes every few months. An article can be right on the day it is published and wrong by the time you find it. So instead of an article, this is a tool that answers for your combination, sitting on top of a fact table we maintain deliberately.

Who writes it

Green Bubble Check is written and maintained by one independent publisher. We are not a company, not a carrier, not a phone manufacturer, and not connected to any of them. Nobody pays us to say that one platform is better than another, and if they tried we would say no, because the entire value of this site is that you can trust the tables.

We are not insiders. We have no access to unreleased software and no relationship with anyone at Apple or Google. What we have is a process: we read the primary documentation, we check behaviour on actual devices where we can, we record the date, and we publish what we found — including the gaps.

How we verify

This is the part worth reading, because it is the difference between this site and the articles it is competing with.

Every version-dependent claim on this site is a numbered entry in one table. Not a sentence in a paragraph — an entry, with an identifier, a value, a confidence level, a primary source URL and a date. Nothing on the site restates a fact independently. The checker, the feature matrix, the timeline, the carrier page and the guides all read from the same entries. When one changes, everything that depends on it changes at once, and no page can quietly disagree with another.

Primary sources only. A fact counts as verified when we have confirmed it in documentation from the party that decides it: Apple's support and security documentation for iPhone behaviour, Google's help pages and security papers for Google Messages, the GSMA's specifications for the RCS profile itself, and a carrier's own site for what that carrier has enabled. Reporting from technology publications is useful for finding out that something happened, and we use it that way — but it is not what we cite. Secondhand summaries are what we are trying to improve on, so we cannot be built out of them.

Unverified means marked, not hidden and not stated. Where an entry has a value we believe but have not yet confirmed at the source, the site shows the value with an unverified marker next to it. Hover or tap it and it tells you which fact it is and what specifically we are unsure about. It is deliberately visible rather than a footnote, because a reader deciding whether a conversation is private deserves to know how confident we are.

We publish a build gate that blocks release until the table is clean. There is a check in the repository that scans every entry and fails if any of them lacks a verified status with a primary source and a date. Right now, it fails. We are telling you that rather than hiding it.

We re-check on a schedule. The schedule below starts once the first verification pass is complete — no entry has been re-checked yet, because none has been checked a first time. From then on, every entry gets reviewed quarterly. Apple-related entries will get reviewed immediately after any iOS release, including point releases, because point releases are exactly where messaging behaviour has changed before. Google Messages entries will get reviewed after significant app updates. And any reader report of a wrong fact triggers an immediate re-check of that entry, ahead of the schedule.

Every correction is published. When we get something wrong we fix it and write down what it said before, what it says now, which pages changed, and what the source was. That is the update log. Articles get quietly edited; we would rather you could see our working.

The current state, honestly

Of 27 version-dependent facts underpinning this site, 15 is currently confirmed against a primary source, 10 are our best understanding pending verification, and 2 are things we have deliberately declined to answer. That is a worse-looking number than any competing page would print, and printing it is the point.

What we don't do

We don't guess at version numbers. A wrong version boundary is the most damaging mistake this site could make, because it would shift every answer in the same direction while looking perfectly authoritative. If we do not know which release changed something, we say so.

We don't publish carrier data outside the US. There are hundreds of operators announcing changes in their own languages on their own sites, and we could not keep a list of them accurate. A stale list about someone's privacy is worse than no list. We show you the on-device check instead, which works everywhere and cannot go out of date.

We don't generate a page per carrier, per phone model, or per combination. It would be easy: the tool already has the data, and it would produce thousands of URLs. It would also be exactly the kind of thin, templated content that makes the web worse. Combinations live in the address fragment, not in separate pages.

We don't answer questions we cannot answer. There are things on this site marked as unknown and they will stay that way until we can check them properly. Currently that includes:

• F12 — Samsung has moved between its own Messages app and Google Messages by region and by model, and the encryption story differs across that split. We will not guess.
• F20 — MVNO and prepaid lines ride on a host network but do not always inherit its RCS provisioning, and the picture changes brand by brand. We publish no per-brand values here. 2026-09-01 verification pass: Apple does publish a per-brand list at support.apple.com/en-us/109526 (Mint, Cricket, Metro, Visible, Boost, Consumer Cellular, Straight Talk/TracFone and Xfinity Mobile appear with encrypted RCS; Total Wireless appears with plain RCS; Google Fi and US Mobile were not on it). That confirms the claim — provisioning really does differ brand by brand — but it is a living document, so copying it into static data would go stale silently. We keep the value empty deliberately and send people to the on-device check instead.

How this is paid for

Eventually advertising, and nothing else — but there are no ads on this site today, so at the moment it is paid for by nobody. There are also no affiliate links, no sponsored placements, no paid reviews and nothing for sale, and that part does not change when the ads arrive. When they do, they will be clearly labelled and kept out of the diagnostic form and the result card so they cannot get in the way of the answer you came for.

Tell us when we are wrong

Seriously. Reader corrections are a real input to how this site stays accurate, and the contact page lists exactly what to include so we can act on it quickly. If you are the person who finds the version boundary we got wrong, you will have done more for this site than any amount of writing.