Siri, Not Available Here

I bought an iPhone knowing exactly what I was getting into. Apple’s ecosystem is closed, sometimes frustratingly so, but that’s a trade-off I’ve willingly accepted. I like the integration between my devices, I like how the software and hardware work together, and I’m comfortable with Apple’s approach.

So when Apple introduced Siri AI, with personal context, screen awareness, and actions across applications, I was interested. I want an assistant that can work with the information and applications already on my phone.

On June 8, 2026, Apple announced it would withhold Siri AI from iOS 27 and iPadOS 27 in the EU, citing its disagreement with the European Commission over the Digital Markets Act (DMA). The assistant began rolling out elsewhere in beta on September 14. As of October 23, Apple has announced no EU release date for iPhone or iPad.

I find that frustrating. My preference for Apple’s ecosystem does not exempt it from the law, but I am the customer living with the consequences of a dispute I have no control over.

Two sides, two very different stories

Apple argues that the Commission’s interpretation would expose sensitive data and system actions to competing assistants without adequate protections. It says it proposed an intermediary called Trusted System Agent and a gradual rollout over 18 months.

The Commission’s account is more pointed than a general assurance that interoperability is possible. It says Apple did not develop a concrete interoperability proposal compliant with the DMA, beyond requesting an exemption lasting more than 18 months. It considers that exemption unlawful and liable to entrench Apple’s position in AI.

The Commission also says the DMA does not prohibit launching Siri AI: Apple decides where to offer it, and must provide equivalent features to third parties, subject to user consent. That consent requirement is part of its stated position, not evidence that every security problem is solved.

Those are substantially different accounts of the same negotiations. Without the full technical proposals and the precise requirements against which they were evaluated, there’s no reliable way for an outside developer to determine whether Apple presented a serious engineering solution or simply asked for more time.

I have no intention of taking either party’s word for it. Apple has a commercial interest in maintaining control over iOS, and the Commission has a responsibility to enforce the legislation it administers. Neither position automatically makes its technical claims correct.

I chose a closed ecosystem

Nobody forced me to buy an iPhone. I know Apple favors its own services. I know Siri has privileges that competing assistants don’t necessarily enjoy. For my personal use, I’m comfortable with that arrangement.

Of course, my willingness to accept a closed platform doesn’t invalidate competition rules or the DMA. The latter is intended to protect competition across a market, not merely to satisfy the individual preferences of existing Apple customers.

But consumer preference shouldn’t disappear from the discussion either. The quality of an integrated experience is part of what people buy. Opening a platform can bring real benefits, but it can also introduce complexity, new security boundaries, and changes to how that platform works.

Those costs deserve examination. In fact, I’d welcome the ability to use ChatGPT or Claude with the same system-level capabilities as Siri. I’d probably experiment with both.

What I object to is the possibility of spending years waiting for functionality that already exists while the regulatory and technical arguments remain unresolved.

macOS makes this particularly interesting

Apple’s current support page draws a curious line: EU users with compatible devices can use Siri AI on macOS 27 and visionOS 27 with an EU Apple Account and both device and Siri languages set to English. iOS 27 and iPadOS 27 remain excluded.

The legal distinction is specific. The Commission designated Apple for iOS in its decision of September 5, 2023, then added iPadOS on April 29, 2024. Both are designated core platform services. macOS and visionOS are absent from Apple’s current list of designated services. The operating-system interoperability obligation at issue therefore does not apply to them in the same way.

That makes me look more closely at Apple’s security argument. A Mac can hold sensitive correspondence, credentials and access to company systems. Apple nevertheless offers its integrated assistant there.

That doesn’t prove equivalent third-party access on iOS would be safe. Running Apple’s own assistant within its security architecture is a different problem from exposing comparable capabilities to external developers.

The distinction helps locate the disagreement: under what conditions must Apple give competing assistants comparable capabilities? That is the question I want answered.

Apple’s announcement also says EU-based developers cannot test or use the new Siri AI features for their iOS, iPadOS and watchOS apps. The restriction affects what they can build as well as what customers can use.

Giving an AI agent access to an operating system is not trivial

As a software engineer, I care about the interface that would make this possible. Extending operating system capabilities to AI assistants requires a permission model as well as an API.

Consider an assistant that can read your emails and create calendar events. The individual operations are familiar. The difficult part is deciding when they should be allowed, and whose instructions the assistant should trust.

Imagine asking an assistant to check your inbox and schedule a meeting. It encounters an email containing instructions to forward your private correspondence to an external address.

An application displaying the email need not treat its contents as commands. An AI agent interpreting those contents might do exactly that. This is an indirect prompt injection: instructions arrive through material the agent was supposed to read. Anthropic describes this threat with an email-exfiltration example in its browser-agent research.

Now imagine the assistant has access to messages, contacts, files, and the ability to trigger actions across applications. An incorrectly interpreted instruction can become something much more serious than an inaccurate answer.

If I were designing an interface for this, I’d want a separate execution layer to enforce permissions independently of the model. The model could propose an action; the execution layer would check whether the user had authorized that operation on those resources.

For example, reading an email should never implicitly authorize forwarding it. Retrieving contact information shouldn’t grant permission to export an address book. And an assistant’s interpretation of a document should never be sufficient to expand its own permissions.

The distinction between data and authority needs to remain enforceable even when the model fails. I would isolate each assistant’s access, keep grants narrow and revocable, and require confirmation for sensitive actions. A confirmation needs to show the actual recipient and payload, not merely ask whether the user trusts the assistant. These are design requirements I would examine, not a description of Apple’s unpublished implementation.

None of this makes interoperability impossible. It means that equivalent capabilities need an enforceable security model. User consent to install an assistant cannot, by itself, tell an execution layer whether an instruction came from the user or from an email.

What exactly is being demanded?

There is already a legal framework for that discussion. Article 6(7) requires free and effective interoperability with the relevant hardware and software features available to the gatekeeper’s own services or hardware. Its second subparagraph also permits strictly necessary and proportionate measures to protect the integrity of the operating system, virtual assistant, hardware or software features, provided the gatekeeper duly justifies them. The Commission reproduces this provision in paragraph 56 of its connectivity decision.

The law therefore leaves room for safeguards. It also requires Apple to justify them. A necessary safeguard can restrict access; the question is whether that restriction is proportionate. I want to know how the proposed protections were assessed against that test.

The Commission’s March 19, 2025 decisions address nine iOS connectivity features, mainly for connected devices, and Apple’s process for handling interoperability requests. They do not directly specify how Siri AI must be opened to competitors. They establish useful requirements and procedures, but do not resolve this particular dispute.

Nor is Apple the only company facing this obligation. The Commission’s final Android decision of July 16, 2026 requires Google to open 11 features relevant to competing AI services, including access to context and actions across apps. Its published guidance gives implementation deadlines in 2027, and 2028 for concurrent voice activation. It also provides for consent and justified safeguards. Those deadlines do not establish what Apple is entitled to, but they make implementation sequencing a concrete subject for discussion.

What I still cannot evaluate from the public accounts is how Siri AI’s specific capabilities map to the required access, what Apple proposed, and why the Commission found it insufficient. Apple’s security claims and the Commission’s rejection of its compliance approach need that detail.

I want to see the requested capabilities alongside a threat model showing which protections enforce each trust boundary.

I’m not expecting every implementation detail to become public, particularly where security-sensitive information is involved. But the present discussion offers very little that an engineer can independently evaluate.

Who pays for the disagreement?

Apple wants to preserve control over its platform. The Commission wants to ensure that competitors can access capabilities that might otherwise give Apple an unfair advantage.

Apple can continue selling iPhones in Europe. The Commission can continue enforcing the DMA. Meanwhile, customers who want the new Siri can’t use it on their phones, and European developers can’t build against those capabilities.

The Commission says the requested exemption would be unlawful. I have no basis to overrule that assessment, nor enough technical detail to judge Apple’s proposed arrangement. I would not support an indefinite exemption simply because Apple dislikes the rules.

I would like to see a concrete assessment of incremental interoperability and measurable compliance milestones, including whether a sequence can comply with the law without giving Apple an exclusive head start. I cannot assume such a route exists. If it does not, explaining the obstacle would be more useful than another general statement about safety or choice.

I want to understand why I’m waiting

I’m not asking Apple to ignore European law, and I’m not arguing that the Commission should simply give Apple whatever it wants.

I’m asking for a better explanation of why the outcome of their disagreement is an indefinite delay for European customers.

Apple has made its decision not to ship Siri AI on iPhone in the EU. The Commission maintains that Apple could ship it while complying with the DMA. Neither has provided enough public technical detail to settle the dispute.

As a developer, I want enough detail to examine the permissions and trust boundaries. As a customer, I want to know what must change before the feature can reach my phone, and who is responsible for making that change.

An open market for deeply integrated assistants could eventually offer something I prefer to Siri. I’d welcome that choice. For now, Apple has withheld the feature and the Commission says a compliant launch is possible. I want them to explain the remaining obstacle in terms more concrete than each other’s refusal to cooperate.