If Siri can act on your app, your app needs to be worth acting onIf Siri can act on your app, your app needs to be worth acting on

Reporting through 2026 has consistently described a rebuilt, context-aware Siri drawing on a Gemini-derived model, and a system that reaches into third-party apps through App Intents.

Set aside how well it works at launch. The architectural implication is the interesting part, and it applies whether or not the first version impresses anyone.

Intents make your app addressable

An App Intent is a declaration that your app can do a specific thing with specific inputs. Historically that mattered for Shortcuts and Spotlight, which most teams treated as a nice-to-have shipped in a quiet sprint.

If the assistant becomes a primary way people reach functionality, intent coverage stops being a nice-to-have. An app whose capabilities exist only as screens is an app the assistant cannot use - and being unreachable is a worse position than being unpolished.

The comparison worth holding in mind is search. An app with no intents is in roughly the position a website with no crawlable markup was in: perfectly functional for anyone who arrives, and invisible to the system that decides who arrives.

The refactor this implies

Apps that will adopt this cheaply already separate what the app does from how it is presented. Apps that will struggle have business logic living in view controllers and view models, reachable only by a human tapping in a particular order.

• Model each user-meaningful action as a function with explicit inputs and outputs.
• Make those functions callable without a view, and test them that way.
• Expose the ones that make sense as intents; keep the rest internal.
• Design for partial input, because a spoken request rarely arrives complete.

That is good architecture regardless of Siri. The assistant just raises the cost of not having it.

There is a quick way to find out where you stand. Take your three most valuable user actions and ask whether each can be performed by a test with no view in the hierarchy. If it can, you are most of the way there. If it needs a screen on screen, the work is not intent adoption; it is separating the logic, and the intent is an afternoon on top of it.

Partial input is the part teams get wrong

A tapped flow collects everything before it runs, because the form will not submit without it. A spoken request arrives with whatever the person happened to say.

That means each intent needs to know which inputs it can sensibly ask for, in what order, and which it can infer. Send a message to my wife has a recipient and no body. Add it to my list has a body and no list. Both should work, and both fail badly when the intent is written as a function that either has all its arguments or errors.

The related discipline is being specific about what cannot be inferred. An intent that guesses which of four lists the user meant will be right often enough to be trusted and wrong often enough to matter, and the cost of a wrong guess is paid in confidence rather than in an error message.

Not everything should be an intent

Exposure is a decision per action, not a coverage target. Some actions are worse through an assistant than through a screen.

• Anything irreversible. Deleting, sending and paying deserve a screen with a confirmation, not a one-shot voice command.
• Anything needing real review. If the user should read something before agreeing, an intent that skips the reading is not a convenience.
• Anything that only makes sense in context. An action whose meaning depends on what is currently on screen usually does not survive being invoked from nowhere.

The good candidates are the small, frequent, low-stakes actions people already wish were faster. Starting something, logging something, checking something. That is a short list for most apps, and a short list done properly beats broad coverage that nobody trusts.

What we would not do yet

We would not rebuild an app around a voice-first premise on the strength of pre-release reporting. Assistant capabilities have been announced, delayed and rescoped repeatedly, and a product whose core interaction depends on one shipping as described is a product with a single point of failure outside your control.

Expose your app to the assistant. Do not bet the product on the assistant.

Cover your intents, keep the app fully usable by hand, and let the assistant be an additional route in rather than the only one.

The pleasant part of this position is that it costs almost nothing to hold. The work that prepares an app for the assistant is the work that makes it testable, automatable and easier to change. If the rebuilt Siri arrives and is excellent, you are ready. If it slips again, you have a better codebase and have lost nothing at all.