Privacy is becoming a product feature. Build it like one.Privacy is becoming a product feature. Build it like one.

Reporting on Apple's 2026 AI direction keeps returning to the same positioning: privacy as the differentiator, as much processing as possible kept on-device, and strict rules for developers who want access to the personal-context APIs.

You can be sceptical about how much of that is marketing and still have to deal with the consequence, which is that users are being trained to ask a question most apps cannot answer clearly.

The question is where does my data go

Not whether it is encrypted. Not whether you have a policy. Where it goes, who can read it, and how long it stays.

Most apps cannot answer that precisely, and not out of bad faith. They cannot answer it because nobody wrote it down while the app was being built, analytics and crash reporting arrived through SDKs that changed behaviour across versions, and the answer is now distributed across four vendors' documentation.

What we do differently now

• A data inventory written during the build, not reconstructed for a privacy label afterwards.
• Every third-party SDK justified by a named feature. If nobody can name it, it comes out.
• A default of on-device processing where the choice is close, because it removes a whole category of question.
• Retention periods decided deliberately rather than defaulting to forever.

The inventory is the one that pays for itself. It takes an afternoon during the build and days to reconstruct later, and it is the difference between filling in a privacy label confidently and guessing.

What goes in the inventory

It does not need to be elaborate. A table with one row per piece of data and five columns answers nearly every question anybody will later ask.

• What it is, in the user's language rather than the column name.
• Why it is collected, named as a feature. If the feature is deleted, this row should be too.
• Where it goes: our server, a named third party, or nowhere because it stays on the device.
• How long it is kept, as a number rather than as appropriate.
• What happens to it when the account is deleted.

The last two columns are where the interesting arguments happen, and having them in a table is what makes the arguments possible. Retention is usually undecided rather than deliberately long, and deletion is usually assumed to be handled by somebody else's system.

Collect less, not more carefully

The strongest position on data you do not want to mishandle is not to have it. That sounds obvious and it is routinely ignored, because storage is cheap and someone might want the data later.

Data you never collected cannot leak, cannot be subpoenaed, and cannot be misused.

The cost of holding data is not storage. It is every future decision it constrains - every breach it widens, every deletion request it complicates, every acquisition due-diligence question it adds.

Analytics is where this is worth being strict, because the default in most tooling is to capture everything and decide later. Events chosen deliberately to answer a question somebody asked are useful. A full behavioural record captured in case it is useful is a liability that nobody reads, and it is the most common thing we remove from projects we inherit.

The SDK is your data processor

Every third-party SDK in the app collects on your behalf and under your name. Users have no way to distinguish your collection from your analytics vendor's, and regulators do not particularly try to.

This is why the named feature rule matters more than it first appears. It is not tidiness. Each SDK is an ongoing obligation to know what it does, which changes without your involvement across versions, and the only practical way to keep that manageable is to have few of them and to know why each is there.

Reading the diff of a dependency update sounds excessive until an analytics library adds a collection category in a patch release and your privacy labels become quietly wrong.

On-device is a design decision, not a performance one

The interesting thing about processing locally is not speed or cost. It is that it changes what you can say.

An app that processes something on the device can state that the data never left, and that sentence ends a category of conversation with users, procurement teams and regulators alike. One that sends it to a server can only describe safeguards, which is a weaker claim requiring more trust and more documentation.

Where the two options are close on capability, the local one is usually worth a modest amount of extra work for that reason alone.

The commercial angle

For a client this is not only an ethics conversation. Being able to state plainly what an app does with data is increasingly a sales asset in enterprise deals, and increasingly a requirement in regulated sectors. The teams that treated it as paperwork are the ones rewriting their onboarding in a hurry.

The concrete version: a security questionnaire from an enterprise buyer asks the questions in the inventory almost verbatim. A team that has one answers in a morning. A team that does not spends a fortnight reconstructing it while the deal waits, which is how a privacy document that nobody wanted to fund becomes the thing holding up revenue.