Model Context Protocol on iOS: interesting, and not yet a foundation
MCP gives models a standard way to reach tools and data. The idea is sound and the direction is right, but there is a difference between a promising protocol and something to build a client product on.
Speculation in late 2025 pointed at Model Context Protocol support arriving on Apple's platforms as a way for models to reach app data and capabilities through a standard interface rather than a bespoke integration per app.
The idea is genuinely good. Standardising how a model discovers and calls tools is the kind of unglamorous plumbing that makes a category usable. Our position on building client products on it is more cautious, and the reasoning generalises.
The case for it
Without a standard, every integration is bespoke. Each model vendor gets its own adapter, each adapter has its own auth and error semantics, and the integration layer becomes the largest untested part of the system.
A common protocol collapses that into one interface. That is the same argument that made HTTP clients boring, and boring is the goal.
Why we are not building on it for clients yet
- Protocol maturity is not the same as ecosystem maturity. The question is not whether the spec is sound but whether the implementations agree.
- Exposing app capabilities to a model is a security surface, and the failure modes are not yet well understood by anyone.
- Client work needs a support answer for five years. A protocol that is eighteen months old does not have a track record to point at.
None of that is a criticism of the design. It is a statement about where the risk sits when you are spending someone else's budget.
The security surface is the part to think hardest about
The second bullet deserves more than a line, because it is the one people underestimate.
Exposing an action to a model means something other than your code decides when it runs. The decision is made by a system whose inputs include text you did not write and cannot fully anticipate, which is a category of authorisation problem most app architectures have never had to handle.
The questions worth answering before exposing anything: what is the worst action available through this interface, whose authority does it run under, can it be triggered by content the user did not author, and is there an action here that cannot be undone. An interface offering only reads and reversible writes is a different proposition from one that can spend money or delete records.
We have no settled answer to this. That is the honest position, and it is precisely why we are not putting a client's product on the wrong side of it.
What we do instead
Build the capability layer properly - actions modelled as functions with explicit inputs, outputs and permissions - and keep the exposure mechanism thin. If a protocol wins, adopting it is an adapter. If it does not, you have lost nothing, because that layer was the right design anyway.
Bet on the shape of the abstraction, not on which vendor's version wins.
Concretely, that means each capability is a named function with typed inputs, a typed result, an explicit permission, and a description of what it does written for a reader rather than a compiler. Nothing in it references a model, a vendor or a protocol.
This is not speculative work. The same layer is what a well-built app needs for its own interface, for automation features, and for tests. If the AI integration never happens, it was still the correct structure, which is the property that makes it safe to build now.
What would change our answer
Waiting is only a defensible position if you can say what you are waiting for. For this we can.
- Independent implementations that interoperate without per-vendor special cases. Two is a standard; one is a product with a specification.
- A documented security model for authorisation and for untrusted input, from the platform rather than from a blog post.
- A platform commitment with a deprecation policy attached, so there is an answer to what happens in year three.
- Somebody other than us running it in production at a size where the failure modes have been found.
When those are true this stops being a judgement call and becomes an adapter, which is a fortnight of work against a capability layer that already exists.
That has been the correct move through several cycles of integration standards, and we have not yet found a reason to think this one is different.
Sources
Reporting and images linked above belong to their respective publishers and are shown from their own servers. The analysis here is our own.
