Privacy is an architecture decision, not a policy page

Every app says it respects your privacy. The sentence costs nothing to write, survives a change of ownership badly, and can be revised in an afternoon. What cannot be revised in an afternoon is an app that has no network code in it. That is the difference worth caring about: a promise about what a company chooses to do, versus a structure where the unwanted thing is not possible.

Two very different claims

"We do not sell your data" is a policy. It describes a decision, and decisions get remade when priorities change. It also quietly assumes the data reached a server in the first place, which means it exists somewhere, subject to whoever ends up holding it.

"The app has no way to send your data anywhere" is an architecture. It describes what the software can do. Nothing in that sentence depends on anyone's continued good intentions, because there is no pipe to misuse. When Receiptd says every receipt is stored only on your device, that is not restraint, it is the absence of a mechanism.

A policy is a promise about behavior, and an architecture is a statement about capability, which is why only one of the two can be broken quietly.

How to tell the difference as a user

You do not need to read source code. A few signals are reliable.

Does it work in airplane mode? Turn the network off and use the app for a few minutes. If everything works, the important work is happening on your device. If it stalls, something is going out.

Does it require an account for the core feature? An account exists so a server can recognize you. Sometimes that is genuinely necessary, like booking a visit with a person or looking up live data. If a card maker or a scoreboard wants a login, ask what the login is for.

Where does sharing happen? A standard system share sheet means you pick the destination, one file at a time. A built-in feed means the content passed through someone else first.

Does the feature list mention analytics or third-party SDKs? Most tracking arrives as a library added for a reasonable-sounding purpose and left in place.

What this costs, and what it buys

Local-first is more work. You cannot fix a weak feature by upgrading the server behind it, and some things are honestly not possible without a connection. We say that plainly, app by app, instead of blurring the line: an app that needs live market data or a real person on the other end needs a network, and pretending otherwise would be worse than the tradeoff itself.

The payoff is that the guarantee holds without anyone maintaining it. Your data cannot leak from a server it never touched. The feature keeps working on a plane, in a basement, and after the app stops getting updates.

The most useful question to ask about a new app is not what it promises, but what it would still be able to do if the promise were withdrawn tomorrow. Our apps are built so the answer is boring, and you can check the network behavior of any of them yourself from the full app list.