When you expose your app's actions to Siri, the Shortcuts app, and Spotlight through App Intents, the modern framework that succeeds the older SiriKit and NSUserActivity-based shortcuts, you gain a great way for users to trigger your features by voice or automation. You also create two considerations that are easy to miss. The content your app surfaces as suggestions and shortcut details can show up in places like the lock screen, so it should not be sensitive. And an App Intent is an action that can be invoked outside your normal UI, including from an automation, so anything sensitive it does still needs proper authorization. Here is how App Intents and Shortcuts can expose data and actions, and how to use them safely.
Short answer
App Intents (and the older Siri Shortcuts) let your app expose actions and content to Siri, the Shortcuts app, Spotlight, and system suggestions. Per Apple, this means two things to handle: content you surface, suggestion text, shortcut titles, donated activity, can appear in system surfaces including the lock screen, so it must not contain sensitive information; and an intent is an action that can be triggered outside your app's normal flow, including by automations, so a sensitive intent must still enforce authorization rather than assume the user came through your UI. App Intents let you require device authentication for sensitive actions. So keep surfaced content non-sensitive, enforce authorization on sensitive intents, and validate intent parameters as untrusted input.
What you should know
- App Intents expose actions and content: to Siri, Shortcuts, and Spotlight.
- Surfaced content can appear on the lock screen: so it must be non-sensitive.
- An intent can run outside your normal UI: including from automations.
- Sensitive intents still need authorization: do not assume your UI flow.
- Require device authentication for sensitive actions: where appropriate.
Where are data and actions exposed?
In the system surfaces App Intents feed, and in how intents can be run. The table lists them.
| Surface or path | Exposure |
|---|---|
| Siri and voice | Actions invoked by voice, with spoken or shown content |
| Shortcuts app and automations | Intents run, and chained, by the user |
| Spotlight and suggestions | Donated content surfaced as predictions |
| Lock screen suggestions | Suggested content shown without the app open |
| Intent parameters | Inputs to an intent that should be validated |
App Intents connect your app to several system surfaces, and each is a place content or actions appear. Siri can invoke your actions by voice and present spoken or displayed content. The Shortcuts app lets users run your intents and chain them into automations that fire on triggers you did not design for. Spotlight and system suggestions can surface content your app donates as predictions, and those suggestions can appear on the lock screen, where they are visible without the app being open. And intents take parameters, which are inputs. So there are two distinct exposure concerns: the content you surface, titles, suggestion phrases, donated activity, which can be seen in these surfaces including the lock screen, and the actions themselves, which can be triggered through paths other than your normal UI.
Why do sensitive actions via intents need authorization?
Because an intent can be invoked outside the flow where you would normally check. In your app's UI, you control the path to a sensitive action, you can require the user to be signed in, or to confirm, before they reach it. An App Intent breaks that assumption: it can be run from Siri, the Shortcuts app, or an automation, without the user going through your screens, so if a sensitive intent performs its action on the assumption that the user already passed your UI checks, it can be triggered in a context where those checks never happened. The fix is to enforce authorization in the intent itself: confirm the user is authenticated and permitted to perform the action as part of handling the intent, rather than assuming the entry path. App Intents also let you require device authentication for an intent, so a sensitive action can demand the user authenticate before it runs. Treating an intent as a trusted internal call because you defined it is the mistake; it is an entry point that needs the same authorization as any other path to the action.
How do you use App Intents and Shortcuts safely?
Keep surfaced content non-sensitive, authorize sensitive intents, and validate parameters. For everything you surface, suggestion text, shortcut and intent titles, content you donate for predictions, keep it free of sensitive information, since it can appear in Spotlight, suggestions, and on the lock screen where others might see it; surface a generic or non-sensitive label rather than private details. For intents that perform sensitive actions, enforce authorization within the intent, confirming the user is authenticated and permitted, and require device authentication for the action where appropriate, so it cannot be triggered by voice or automation without the proper checks. Validate an intent's parameters as untrusted input, since they can come from a shortcut or automation you did not author. For anything truly sensitive, verify server-side as you would for any action. And donate only non-sensitive activities for prediction, mindful that donations feed lock-screen and Spotlight suggestions. The principle is that App Intents are public entry points to your app's content and actions, so the content must be safe to show in system surfaces and the actions must enforce their own authorization, never relying on the user having come through your UI.
What to watch out for
The first trap is surfacing sensitive content in shortcut titles, suggestion phrases, or donated activity, where it can appear in Spotlight or on the lock screen; keep surfaced content non-sensitive. The second is a sensitive intent that assumes the user came through your authenticated UI, when it can be run from Siri or an automation; enforce authorization in the intent and require device authentication where appropriate. The third is trusting intent parameters, which are untrusted input. App Intents are defined in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled IPA against OWASP MASVS, assesses your app's authentication and data handling, while keeping surfaced content non-sensitive and authorizing intents is yours to implement.
What to take away
- App Intents (and Siri Shortcuts) expose your app's actions and content to Siri, the Shortcuts app, Spotlight, and suggestions, creating two concerns: surfaced content and triggerable actions.
- Content you surface, titles, suggestion phrases, donated activity, can appear in system surfaces including the lock screen, so keep it free of sensitive information.
- An intent can be triggered outside your normal UI, including by automations, so enforce authorization within sensitive intents, require device authentication where appropriate, and validate parameters as untrusted input.
- Use a pre-submission scan such as PTKD.com to assess your authentication and data handling, and keep App Intent content non-sensitive and actions authorized.
