iOS 27 reached every compatible iPhone on 14 September, and most of the coverage has understandably been about Siri - the new architecture, the conversational mode, the access to personal context. Underneath that consumer story is a change in who can reach into your app, and most development and testing teams haven't caught up with it.
The side doors are not new
The UI is the storefront: browse, add to cart, check out, in that order. Apple has been opening side doors into that shop for a decade.
SiriKit (2016) was a voice side door, but only for a few Apple-approved jobs: send a message, request a ride, start a workout, pay someone. Uber did not have to invent a general “Siri API.” It implemented “book a ride,” and Siri knew how to ask for pickup and destination. A person could complete a core action without opening the app. That is already a second interface.
Shortcuts (2018) was a recipe side door. A user, or your team, could save a sequence: “log this workout,” “order my usual,” “set Do Not Disturb and open Maps.” Tapping the shortcut, or saying “Hey Siri, run Morning,” ran those steps without walking the screens. QA rarely treated Shortcuts as a first-class surface, but customers were already using the app that way.
App Intents (2022) was Apple replacing those one-off side doors with a catalog of actions the system can call: Siri, Spotlight search, the Action Button, widgets, Shortcuts. “Create event,” “play this playlist,” “show my order.” Same idea as publishing a short list of APIs, except the callers are Apple’s system features instead of a website.
So the surface is old. What arrived this year is a far more capable visitor using it.
What changed is the visitor
Siri AI doesn't need the ten phrases you published. It reads the catalogue, looks at what's on screen and at personal context, forms a plan from a sentence, and calls actions in whatever order that plan requires.
Apple has been promising this visitor since WWDC 2024, where personal context, onscreen awareness and App Intents-powered in-app actions were announced together. The features were officially delayed in March 2025, slipped through that year and into early 2026, and landed on phones in September. The long gap matters here, because it means many teams filed App Intents under "did that in 2022" and stopped thinking about it. Three things are true now that weren't then.
Discovery flipped. Previously a user had to know a Shortcut existed or say a phrase you'd published. Now the assistant finds the action. Anything in the catalogue is in play — including intents someone added years ago for a Shortcuts integration and nobody has looked at since.
Sequence is no longer your design. A Shortcut runs the order you wrote. A screen flow only offers the next legal step. An assistant composing "move lunch, tell the attendees, book a car" calls whatever functions it decides it needs, in combinations no screen ever permitted. Every invariant a team relies on because "the user can't get there from here" needs rechecking.
Absence became a product problem. In 2022, skipping App Intents made you weaker in Shortcuts and the app still worked. Apple's documentation now describes SiriKit, Intents and IntentsUI as providing legacy support for existing interactions and points developers to App Intents for modern integration. SiriKit still covers its old domains; it does not carry you onto the new surface. Users will ask Siri to do the thing, Siri will do it in a competitor's app, and nothing will appear in your crash reports.
Google made the same move this year. Android 17 expanded AppFunctions, described in the release announcement as contributing an app's capabilities as orchestratable tools for Android MCP, the on-device equivalent of the Model Context Protocol. MCP is how agents call tools on servers; Google has pointed the same idea at the apps installed on a phone. Gemini integration is still in private preview with trusted testers, so Android teams have more runway — but two platforms converged on one pattern inside a single cycle. That's why 2026 is the story and 2022 wasn't.
Why this lands on QA
An App Intent or an AppFunction is a function signature: typed parameters, entity types it accepts and returns, discoverability settings, and a policy governing what authentication is required before it runs. Nothing a UI test depends on is present on that path — no screen to read, no element to tap, no navigation sequence quietly establishing state along the way.
Beyond the ordering problem above, three properties make this hard to verify.
Parameter values arrive from an interpreter. A UI constrains its own input: a date picker only emits a valid date, a dropdown only emits a member of a known set. An intent parameter is populated by a model reading a sentence, which makes "next Friday," spoken by someone in a timezone the app was never tested in, a live input to a function whose date picker never had to handle it.
Authentication and confirmation moved off the screen. When the action executes outside your UI, so does the moment where the user agrees to it. Apple exposes settings that govern this, and getting them wrong doesn't fail loudly — it means something happens the user never clearly consented to, a defect that surfaces in a review rather than in CI.
The caller changes without your code changing. This one has no precedent. A UI test pins a contract between your code and a human whose behaviour is stable. An intent's caller is a model updated on the platform's schedule. The same function, with the same tests green, can start being invoked differently after an OS update you didn't ship.
The tooling exists. Its scope is the issue.
Worth being precise, because the gap isn't an absence of tools. Apple shipped App Intents Testing alongside iOS 27 — an XCTest framework that runs intents, entities, enums and queries out of process, the way Siri and Shortcuts perform them, with type-erased APIs letting a test reference an intent by name and set its parameters without linking against the app target. It covers onscreen context through view annotations. On Android, adb shell cmd app_function list-app-functions enumerates what a package registers, execute-app-function invokes one with a JSON parameter string, and the AppFunctions Testing Agent goes further, letting you observe behaviour in a conversational flow.
These are good tools and anyone publishing intents should be using them. What they verify is that a function does what it claims when called. That layer is well served.
What remains unverified is the system the function now sits inside: whether a model read an ambiguous utterance the way you expected, whether an agent composing across three apps called your functions in an order your data model survives, whether any of that held after the platform updated the assistant underneath you. Those are properties of an interaction rather than of a function, and the discipline for testing them hasn't formed yet. Security teams recognised the shape early — tooling that inventories published intents and audits what they expose appeared quickly, because a new caller with access to an app's data and actions reads immediately as a threat model worth mapping. The quality equivalent is further behind.
Where a team can start
Inventory first. List every intent or function the app publishes, and record its parameters, its authentication policy, and what data it can reach. That list is usually longer than expected, for the reason above: intents accumulate, and the ones added for Shortcuts in 2022 are now exposed to a caller nobody anticipated.
Then use the platform tools for what they're good at, and be explicit about what sits outside them. Boundary cases on every parameter. Invocation from states the UI cannot produce. Confirmation behaviour when the app isn't in the foreground. Behaviour when the underlying data has changed between the agent reading it and acting on it. Past that, a team is making judgement calls without a safety net — and knowing that is better than assuming a green suite covers it.
The doors have been there for years. What's new is that something on the other side can now read the whole catalogue and decide for itself which ones to open.