Add Siri shortcuts with App Intents, because SiriKit is now the legacy path Apple tells you to leave.

The current framework is App Intents, and the old one has a name

Apple describes App Intents as the way to make content and actions discoverable by Apple Intelligence and to support system experiences like Siri, Spotlight, Shortcuts and widgets. You express each action as an app intent, your data types as app entities, and any fixed list of choices as an app enum. The compiler then generates what Siri and other system features need to find and run your code, so there is no registration step.

A Siri shortcut from an app sits one layer above that. Apple's App Shortcuts documentation says you define a type that adopts the AppShortcutsProvider protocol and build AppShortcut values from static data, and that the shortcuts are available as soon as someone installs your app, with nothing for you to register. Both types are listed as iOS 16.0 and later, iPadOS 16.0, macOS 13.0, tvOS 16.0 and watchOS 9.0.

Name the old one, because readers arrive from pages that describe it. It was SiriKit, with the Intents and IntentsUI frameworks underneath, custom intents, and an Intents app extension to handle them. Apple still publishes a sample called Soup Chef with App Intents: Migrating custom intents, which exists to show the changes needed to move off a custom intent. App Intents carries its own Deprecated symbols collection too, so check it before copying an API name out of an old post.

Apple Developer, SiriKit framework overview and its legacy support note, read 3 October 2026

The permission the user is asked for, and what a refusal does

On the App Intents path, nothing. Apple's App Shortcuts documentation describes no permission prompt and no authorization call: the shortcut is there as soon as the app is installed. There is no Siri usage description in that path either. If you expected an alert, you are thinking of SiriKit.

The prompt belongs to the legacy path, and it is still in a lot of shipped code. Apple's property list reference defines NSSiriUsageDescription as a message that tells people why the app is requesting to send user data to Siri, and marks it required if your app uses APIs that send user data to Siri. SiriKit's authorization article, read the same day, says to enable the Siri capability on the target, put that key in Info.plist, then call requestSiriAuthorization on INPreferences. It also carries the note that matters most: you do not need to request authorization if your app only supports Shortcuts app actions.

Refusal is documented precisely. INSiriAuthorizationStatus has four cases. notDetermined means nobody has been asked. authorized means Siri can interact with your app. denied means the user explicitly denied authorization for this app. restricted means the app is not authorized, which Apple says can come from restrictions on Siri services rather than the user's choice, so do not report it as a refusal. Apple adds that the system remembers the answer, later calls do not prompt again, and the user can change it in the Settings app. So keep every action behind a phrase reachable by tapping.

One naming trap. App Shortcuts on iOS is an App Intents type. App shortcuts on Android is an icon in the launcher. If the icon is all you wanted, you can add app shortcuts without going near Siri, and it is a much shorter job.

Android asks the user for less and still makes this harder

Android is the harder platform, and not because of permissions. Google's App Actions documentation, read 3 October 2026, says you enable voice support by declaring capability tags in shortcuts.xml, then states the step that catches people out: when you upload your app using the Google Play console, Google registers the capabilities declared in your app and makes them available for users to access from Assistant. A phrase on iOS works on a development build. On Android it is not live until the app has been through Play.

The same page sets three more limits. App Actions work through built-in intents, Google's prewritten models of common requests such as starting an exercise or creating a message, so you pick the closest one rather than inventing wording. App Actions are supported on Android 5, API level 21, and higher. Users can only access them on Android phones, and Assistant on Android Go does not support them. Where no built-in intent fits, Google says you can fall back to a custom intent.

The launcher side is separate and simpler. Google documents three shortcut types: static ones defined in a resource file packaged into the APK or app bundle, dynamic ones your app pushes at runtime, and pinned ones added to a supported launcher if the user grants permission. That pinned case is the only user-facing prompt in the Android story: Google says the user gets a confirmation dialog asking permission to pin, the launcher cancels the request if they decline, and your app receives no callback. Most supported launchers display up to four shortcuts at a time, and the per device maximum varies, so read it with getMaxShortcutCountPerActivity().

To tie a launcher shortcut to a spoken command you add a capability-binding element inside the shortcut, keyed to a built-in intent such as actions.intent.CREATE_MESSAGE, and point a manifest meta-data entry at the shortcuts resource. None of this is speech recognition. To let someone dictate into your own text field, add voice input instead.

Android Developers, Google Assistant for Android and App Actions, read 3 October 2026

A simulator will not prove this works

Plan on a real phone. Apple's Xcode guidance on running an app, read 3 October 2026, says simulators do not replicate the performance or features of a physical device, and that to verify an app runs exactly as intended you run it on one or more physical devices. It adds that some hardware specific features might not be available in a simulator, and that to test a feature itself you run the code on a device. Apple publishes no feature list naming Siri as unavailable in Simulator, so treat that as a reason to book a device rather than a flat statement either way.

Apple's App Intents verification guide is more specific about the step people skip. It says Spotlight indexing depends on device behavior that does not always match Simulator, and to validate Spotlight integration and entity discoverability on a physical device. It also sets out four layers in order: integration tests with the App Intents Testing framework, checking that your intents appear under your app name in the Shortcuts app Action Library, searching Spotlight for the entities you donated, then speaking real phrases at Siri. A passing test suite says nothing about whether a parameter summary reads like a sentence.

Android has the same shape with a sharper edge. Google says you use the Google Assistant plugin for Android Studio to create a preview of your App Actions in Assistant for your Google Account, then trigger the action on your test device from the tool window. Read the scope: the preview is tied to your account, so a colleague cannot try the phrase until the build is uploaded.

Two features that look related are not. A phrase that runs an action is App Intents. A card that keeps updating on the Lock Screen while something is in progress is live activities, a separate framework with its own constraints, and worth its own walkthrough rather than a paragraph here.