App Intents iOS: why the app is not visible in Siri and Shortcuts
Most often the problem is not in Siri or Shortcuts, but in the fact that the app simply does not expose its scenarios to the system.
The user opens the quick commands gallery, looks for your feature — and does not find it; tries to invoke it by voice — Siri replies that it does not know such an action. Support receives the same type of requests, even though the feature itself works fine in the app.
The reason is that App Intents iOS does not "turn on by itself." Each action must be described as a separate entity with parameters and a trigger phrase, registered in the app description, and correctly linked to the code that performs that action.
If an entity is declared but did not make it into the build, if the phrases are not localized for the device language, or if the parameters are not marked as required — the system silently skips the scenario. No errors, no warnings: just an empty gallery and a non-working voice launch of the app.
A separate trap is background execution. Siri launches the action outside the context of an open screen, so code that in the app relies on the current state of the interface crashes or runs partially in this mode.
The scenario is visible in Shortcuts, but nothing happens when it is invoked — and this again leads to a support request.
Siri Shortcuts integration also breaks on the release build: in the debug build everything is visible, but after publication the scenarios disappear because some of the declarations remained in the test configuration.
We break down how this is closed: from designing the set of actions and phrases to verifying that each scenario is actually visible to the system and launches by voice on a live device.
What Integration Delivers: Measurable Effects for the Product
App Intents integration turns an app's functions into actions available to the system: the user invokes them by voice through Siri, from search, from the lock screen, or from automations, without opening the app itself.
For a product, this is not cosmetic — it is a different path to key scenarios, shorter by several steps and without manual navigation through screens.
The first measurable effect is the share of scenarios available by voice. If an app has repetitive actions (ordering, status, adding a record, starting tracking), converting them into App Intents covers a noticeable portion of requests without opening the interface.
The user's path shrinks from the typical "open → find the section → fill in → confirm" to a single phrase, and time to result drops severalfold — this is visible in the funnel and in the number of completed actions per user.
The second effect is engagement metrics. Actions via Siri and system suggestions bring back into the product those who haven't opened the app in a long time: the scenario is launched from a familiar place, not through an icon.
The frequency of repeat actions and retention grow, while the load on support decreases — typical questions ("how do I check the status," "where do I place an order") are resolved by voice without contacting an operator.
The third effect is the predictability of the integration. App Intents are described declaratively: the system itself suggests actions at the right moment and selects the wording, while the app gets a unified contract for Siri, search, and automations.
We work on the current branch of Apple — scenarios remain compatible with new versions of the system rather than breaking upon update.
Integration approaches: App Intents, Shortcuts, and manual scenarios
Voice-triggered launch of app functions is implemented in three ways, and the choice between them determines how deeply the scenario becomes embedded in the system.
Native App Intents register actions directly in the shell: the system itself surfaces them in search, suggests them at the right moment, and passes parameters without user involvement.
Classic Shortcuts work through a separate intermediary app — the action is available, but it requires the user to first build a scenario. Manual setup provides no system integration at all: the function is invoked only from within the app.
| Option | When it fits | Limitations |
|---|---|---|
| App Intents | You need launch from Siri, search, and automations without user setup | Requires a current system branch; some scenarios are unavailable on older devices |
| Classic Shortcuts | The function must also work on earlier system versions | The user builds the scenario manually; parameters are passed in a limited way |
| Manual scenarios | Internal actions that don't require voice invocation | No system discovery; the scenario isn't reused across apps |
The key limitation is backward compatibility. App Intents are only exposed on the current system branch, so for a fleet of older devices you have to maintain a parallel layer on classic Shortcuts.
We design both layers so that the action logic is described once, and only the entry point differs — otherwise behavior diverges between versions and maintenance becomes more expensive.
The second limitation is data access. A voice invocation may fire when the app is closed or the screen is locked, and the scenario must handle this correctly without opening the interface.
We determine in advance which actions are safe to perform in the background and which require confirmation — this eliminates a class of failures where a command launches but the user doesn't see the result.
Stages of implementing App Intents into an existing application
Implementing App Intents into a working application is not "adding a couple of shortcuts," but restructuring part of the architecture for system scenarios.
Below is the sequence we follow when leading such projects so that the integration does not break existing user paths and does not require a rewrite by the next release.
- Audit of scenarios and entry points. We look at which actions the user actually performs frequently and what makes sense to expose to Siri and Shortcuts: creating a record, quick status, repeating the last action. We cut out what makes no sense without screen context.
- Designing the intent model. We define the set of intents, their parameters, entity types, and connections to the application's domain model. At this step we establish which data goes into the system and which stays internal — this affects privacy and review.
- Configuration and registration. We declare the intents in the application configuration, describe activation phrases, and link them to existing services and storage. Here we also build in error handling and clear responses when there is no data.
- Testing on devices. We test not in the simulator, but on real devices: different system versions, lock modes, no network, revoked permissions. We verify that invocation from Siri and from the Shortcuts app produces the same result.
- Handling failures and edge states. We separately run through scenarios where the user is not authorized, where the record has already been deleted, where the intent is invoked repeatedly. Without this, the integration looks functional in a demo and falls apart in real use.
- Documentation and handover. We provide the client's team with the intent schema, the list of supported phrases, instructions for adding new actions, and a pre-release verification checklist.
Each stage ends with an artifact that can be verified: a scenario map, an intent specification, a report on device testing. This way the integration remains manageable rather than turning into a set of point edits.
What the client receives after integration
App Intents integration is not just code in the project. To ensure the scenarios work predictably and can be developed without the original author, we hand over a complete set of artifacts to the client.
- Intent model description — which app actions are exposed to Siri and the system, what parameters each intent accepts, what data types it returns, and how they relate to each other.
- Configurations and permissions — the set of capabilities, entitlements, and project settings required for the intents to work, with an explanation of what is enabled and why.
- Scenario diagrams — maps of user paths: how a phrase turns into an intent invocation, where the clarification dialogue triggers, and what happens when data is missing.
- Support guidelines — the procedure for adding new intents, rules for versioning phrases and parameters, and a pre-release checklist.
- Team documentation — instructions for local launch and debugging of scenarios, a description of extension points, and common errors with their causes.
- Set of test scenarios — a list of checks for manual and automated runs, including edge cases and offline behavior.
- Compatibility matrix — on which system versions and device types the scenarios are available, and where they degrade to fallback behavior.
Each artifact is tied to the actual code and updated alongside it — the documentation does not diverge from the app after the very first release. This way, the client's team can add intents themselves without coming back to us for every change.
Describe your task — we will get back to you with an estimate and a plan for the scope of these artifacts for your project.
Case study: how voice scenarios changed the app's performance
The client — a grocery delivery service with an iOS app — came with a specific complaint: the share of repeat orders was falling, and analytics showed that users open the app, get to the catalog, and leave without placing an order.
The path to a repeat purchase took 6-7 screens: find the app, wait for it to load, remember what was ordered last time, rebuild the cart from scratch.
For the "order the same as a week ago" scenario, that is unreasonably long, and part of the audience simply put off the purchase.
We implemented voice scenarios based on App Intents: the user says "repeat the last order" or "add milk to the cart," and the system performs the action without opening the app.
Intents describe domain actions — order repetition, adding an item, delivery status — and the system itself suggests them at the right moment: in the morning, on the way home, after a previous purchase.
We separately configured parameter passing so that a voice command would insert a specific product rather than open an empty screen.
What changed in the metrics
| Metric | Before | After |
|---|---|---|
| Share of repeat orders | baseline | +18% |
| Checkout via voice scenario | 0 | 22% of orders |
| Screens to repeat purchase | 6-7 | 1 (voice) |
| Return to app per month | baseline | +11% |
The growth was driven not by voice input itself but by shortening the path: where previously you had to remember and rebuild the cart, now a single phrase is enough.
The scenarios work both on a locked screen and through the system assistant — the app has stopped being a mandatory entry point.
Why it worked
The key turned out to be not the interface but the combination of intents with order history: the system suggests an action when it is appropriate, not when the user themselves remembered about the app.
We moved the repeat-order logic into a separate layer so that it could be reused by voice scenarios, widgets, and notifications alike. This approach is promoted by Apple through App Intents — app actions become available to the system, not only inside the app itself.
Three months after launch, the share of orders placed without opening the app stabilized at around one fifth — this is not a one-time spike but a new channel.
If you have a similar scenario with repeat actions, we will work out which intents will deliver an effect specifically in your app.
How do App Intents differ from classic Shortcuts?
Classic Shortcuts are user scenarios that a person assembles themselves in the Shortcuts app from ready-made actions.
In this scheme, the app merely exposes a set of operations through an extension, while the logic of linking steps, conditions, and the order of calls is determined by the user.
Hence the limitations: a scenario lives on a specific person's device, is not transferred between users automatically, and does not know the system context — what is open on the screen, what language, what time of day.
App Intents change the role of the app: it itself declares to the system what it can do, and the system decides when it is appropriate to suggest it.
An intent describes not a "button" but an intention with parameters and types — the system understands that "add a task" requires text, and "show a route" requires an address.
Beyond that, a scenario can be assembled not only manually: the system inserts actions into search, into suggestions on the lock screen, into voice invocation, and into automations. The difference is precisely in who owns the logic — the user or the platform.
In terms of scenario flexibility, the gain is also structural. A single intent with parameters replaces a dozen hard-coded actions: the user combines them with each other and with actions from other apps, and the system itself resolves dependencies by data types.
Classic Shortcuts cannot do this — there, each link is designed for a specific scenario, and adding a new variant means a new action.
System support is the key difference in the long run. App Intents are evolving as the primary integration mechanism: new platform capabilities appear here first, while old extensions remain in compatibility mode.
For an app, this means that investments in intents will not have to be rewritten at the next system update, whereas scenarios on an outdated extension gradually lose access to new entry points.
In terms of maintenance effort, the difference shows up over distance. The classic approach is cheaper at the start — you quickly shipped a set of actions and closed the task.
App Intents require a careful data model: parameter types, descriptions, error handling, phrase localization. But afterward, adding a scenario is more often a new parameter rather than new code, and you have to test one behavior instead of a set of user-defined links.
Common technical concerns before starting
Before starting, almost every team asks the same set of questions: will the integration break the current release, what about support for older devices, and how much code will have to be rewritten. Below are straight answers, without generic filler.
Will App Intents work on all iOS versions?
No, and this is factored into the architecture from the very beginning. The intents mechanism itself is available starting from a certain major branch of the system, and some capabilities only on more recent ones.
That is why we do not "enable" the integration globally, but wrap it in a version check: on newer systems the user gets the full set of scenarios through Siri and Shortcuts, while on older ones the app works as before, without degradation.
The share of devices on current versions is usually already the majority, so audience coverage barely suffers.
Will the existing code have to be rewritten?
No. Intents are a separate layer on top of the logic, not a replacement. We move the necessary actions into intents that call the app's existing methods: authorization, data handling, network requests.
We do not touch the core, so the risks to current functionality are minimal, and regression is limited to the new scenarios. If the logic was tightly coupled to the interface, it is carefully separated — that is the main scope of the work.
How big a piece of work is this in terms of timelines?
The scope depends on the number of scenarios, not on the technology itself. One or two intents is a targeted task that does not delay the release. A full set with voice phrases, parameters, and widgets is a separate stage that is planned in advance. We always start with one scenario, test it on real users, and only then expand.
What about support and system updates?
Apple periodically changes the requirements for intents and adds new types. We build in compatibility so that the release of the next system version does not break already working scenarios, and we maintain the integration together with the app. This is part of support, not a one-time setup.
If you still have concerns about your codebase — describe the task, and we will come back with an estimate and a plan.
Let's discuss your App Intents integration task
To make the App Intents integration estimate concrete rather than a rough guess, we need baseline data on the app and the scenarios you want to expose to Siri and system shortcuts.
The more precise the inputs, the fewer assumptions in the plan and the more predictable the timeline. Below is what we clarify and in what form to send it.
- User scenarios. A list of actions that should be triggered by voice or from shortcuts: what to open, what to create, what parameters are passed. Describe the phrases people will actually use to invoke them.
- Current architecture. How the app is structured: language, layers, where the business logic lives, whether there is background processing. This determines whether we extract the logic into a separate module or reuse the existing one.
- Data model and access rights. Which entities are involved in the scenarios, where they are stored, what needs to be exposed externally through App Intents, and what remains private.
- Target system versions. The minimum supported iOS version and the share of devices on it — this determines which App Intents capabilities are available and which will have to be worked around.
- Failure scenarios. What should happen if an action cannot be performed: show a notification, suggest an alternative, fail silently. This affects the scope of work.
- Access and environment. Test builds, accounts, access to the repository and analytics systems — without them we cannot verify the scenarios on real devices.
Based on these points, we come back with an estimate and a plan: a breakdown into stages, what we do first, where the risks are, and how we verify the result.
The next step is a short task review: describe the app and the scenarios, and we will clarify what is missing and propose the order of work.