What Airplane Mode Tells You About an App

Switch on airplane mode, open a companion app, and send a message. What happens next tells you something the app’s marketing usually will not: whether the conversation is generated on the operator’s servers or on your phone, and how much of your history is stored locally. If you get an error, the work happens remotely. If you get a reply, some of it happens on the device.

It costs nothing, takes ten seconds, and is one of the few claims in this category you can verify yourself.

Why the answer is almost always “remote”

For the models that make current companion apps feel conversational, the honest expectation is that generation happens on a server.

A useful conversational model is large, and phones are constrained. On-device models exist and are improving, but the ones that fit comfortably on a phone are meaningfully smaller than the ones running in data centres. An app promising rich, long-memory conversation is very unlikely to be doing it locally, whatever the phrasing on the listing suggests.

So an offline error message is not a criticism. It is the expected result, and it confirms something useful: your messages leave your device. That was already true, but people frequently assume otherwise, and a blunt “no connection” screen removes the ambiguity.

Reading the four possible outcomes

The test has more resolution than pass or fail.

Nothing loads at all — not even past conversations. The app holds essentially no local state; history is fetched every time. Your device backup contains almost nothing of your conversations, and a fresh install on a new phone will restore everything from the account.

Past conversations are readable, new messages fail. Generation is remote, storage is at least partly local. This is the most common result. It means there is a local database with your history in it, which matters for backups, for device residue after account deletion, and for anyone with access to your unlocked phone.

You get a reply, but it is generic and short. Some apps ship a small local fallback model, or canned responses, for exactly this situation. A noticeably different voice offline is the tell.

You get a full-quality reply. Genuinely unusual. If it happens consistently, the app is doing real local inference, which is a meaningful privacy property — and one worth confirming rather than assuming, using the further checks in what on-device processing would look like.

What the app does when the connection returns

The second half of the test is more interesting than the first, and most people stop before it.

Watch whether messages you typed offline are sent on reconnection. A queue that flushes automatically means the app retained your input locally and transmitted it later, without a further action from you. That is ordinary engineering and it is also worth knowing: something you typed and thought better of may already be in a queue.

Watch for a burst of activity. Some apps sync analytics, session logs, and diagnostics on reconnection, which is invisible in normal use because it happens continuously. A period offline batches it into something you can sometimes notice as a brief delay or a spike in the app’s data usage figure.

Then check the per-app data usage counter in your phone’s settings, which both platforms provide. It does not tell you what was sent, but the volume is informative. An app that has transmitted far more than the text of your conversations could account for is sending something else — most plausibly telemetry, images, or audio.

What this cannot establish

The test has firm limits and overstating it would be a mistake.

It does not tell you what is sent. You are observing whether the app functions, not inspecting traffic. Assuming otherwise is the main way this diagnostic gets misused.

“Local” does not mean “private”. An app can process something on the device and still transmit the result, or the input, or a log of both. On-device processing is a necessary condition for a message not leaving your phone, never a sufficient one.

A single test is a snapshot. Behaviour changes across releases, and an app that failed offline last month may ship a local fallback this month, or the reverse. See what an app update can change without asking.

Some failures are unrelated to architecture. An app can require a connection purely for authentication or entitlement checks, then be perfectly capable of local work once online. An offline error is weaker evidence than an offline success.

Why it is still worth doing

Because it resolves the most common misconception in the category cheaply. People routinely assume that a conversation which feels private is private in a technical sense — held on their phone, seen by nobody. Ten seconds in airplane mode replaces that assumption with an observation.

It also tells you what to expect on a train, a plane, or a bad connection, which is a mundane practical benefit. And it gives you the local-storage answer that feeds into decisions elsewhere: whether to exclude the app from device backups, as covered in what ends up in your phone backup, and how much cleanup a device actually needs afterwards.

Run it once when you install something, and note the result. It is the closest thing to a free measurement available here, and unlike almost everything else in this category, the answer comes from the app’s own behaviour rather than from its description of itself.