Add home screen shortcuts and you get four slots on each platform, filled by two different rules.

The two names, and the two caps, from the two vendors

Apple's Human Interface Guidelines page for Home Screen quick actions was read on 3 October 2026. It says people get the menu when they touch and hold an app icon. On a 3D Touch device they can press on the icon with increased pressure instead. The same page sets the ceiling in one clause: you can provide a total of four. The menu also carries system items for removing the app and editing the Home Screen. Those are not yours and they do not come out of your four.

Each iOS action gets a title, an optional subtitle, and an interface icon. The icon sits on the left or the right depending on where your app sits on the Home Screen. Apple says to prefer SF Symbols and not to use an emoji. Quick action symbols are monochrome and change appearance in Dark Mode. Apple publishes no character limit for the title. It says to keep the text short to avoid truncation and to account for localisation. That is weaker than a number, and a number invented here would be worse than the gap.

Google's wording differs in a way that changes what you can plan for. The Android app shortcuts documentation says most supported launchers display up to four shortcuts at a time. That count includes static and dynamic together. It then says the maximum a device supports varies, and that you should call getMaxShortcutCountPerActivity() to find out. There is no published figure for the device limit. Read it at runtime rather than trusting a number from a tutorial. Android does publish label guidance: aim for about 10 characters on the short label and about 25 on the long one.

This is a different feature from the voice one. If you came here to add siri shortcuts, that is a separate declaration and a separate framework. Nothing you write here will appear there.

Apple, Human Interface Guidelines: Home Screen quick actions (read 3 October 2026)

Which four appear, and in what order

Both platforms publish the order, and both put the fixed ones first. Apple's UIKit reference for UIApplicationShortcutItem says the system limits how many quick actions are displayed. Your static quick actions are shown first, starting at the topmost position. A dynamic action appears only if the static ones have not used up the permissible number. Android's shortcut management documentation, read on 3 October 2026, says the same thing in its own terms. The launcher must display static shortcuts first and then dynamic ones, each group sorted by increasing rank. Static ranks follow the order the entries appear in your XML file.

The split is the part only Android has. That page states it without hedging. For any combination of static and dynamic shortcuts, the launcher displays a maximum of two static shortcuts and two dynamic shortcuts. Its own worked example is four static plus three dynamic. That produces the first two static shortcuts and the two most highly ranked dynamic ones. Five of those seven never reach a screen. Exceeding the device maximum is not silent either: adding past getMaxShortcutCountPerActivity() throws an IllegalArgumentException.

iOS has two timing quirks that cost an afternoon if you meet them by surprise. Both are stated in Apple's reference. Between installing your app and first launching it, only the static actions exist. The system registers those at install time, and your code has not run yet. And if a user installs an update but has not opened it, long pressing the icon shows the dynamic actions from the previous version. Apple's suggested handling is to put version information in the action's userInfo dictionary so you can tell.

Android adds a constraint you cannot see in the interface. All shortcut information is stored in credential encrypted storage. Your app cannot read a user's shortcuts until the device has been unlocked, and the matching API behaviour is an exception when the user is locked. Pinned shortcuts behave differently again. There is no limit on how many a user creates, and your app cannot remove one. The only thing you can do to a stale pinned shortcut is disable it with a message that explains why.

Android Developers, Manage shortcuts: display order and limits (read 3 October 2026)

Where you declare them, field by field

On iOS the fixed actions are a UIApplicationShortcutItems array in Info.plist, one dictionary per action. Xcode labels the key Home Screen Shortcut Items. Each dictionary needs UIApplicationShortcutItemType, a unique string the system hands back so you can tell the actions apart, and UIApplicationShortcutItemTitle. Everything else is optional: a subtitle, a userInfo dictionary, and three ways to set the icon. Apple documents the icon precedence, and it matters if you are copying from an old page. UIApplicationShortcutItemIconSymbolName wins, then UIApplicationShortcutItemIconFile, then the older UIApplicationShortcutItemIconType template list. The symbol name key is the current one.

Dynamic iOS actions are an array you assign to the shared application's shortcutItems property. Apple's own sample advises against trimming that array yourself, because the system displays only what fits. The handling moved with scenes. A cold launch arrives as a shortcutItem on the connectionOptions of scene(_:willConnectTo:options:). An app that is already running gets windowScene(_:performActionFor:completionHandler:) on the scene delegate. The app delegate method, application(_:performActionFor:completionHandler:), is what pages written before scenes describe. Expect to see it, and expect it to be the wrong place in a scene based app.

On Android the fixed ones live in res/xml/shortcuts.xml. A meta-data element named android.app.shortcuts points at it, on the activity that handles the MAIN action and the LAUNCHER category. Only main activities can carry shortcuts. Each shortcut element needs android:shortcutId and android:shortcutShortLabel, and must contain an intent with an action. The short label has to be a string resource rather than a literal. The runtime side is ShortcutManagerCompat: pushDynamicShortcut publishes or updates one, removeDynamicShortcuts takes them away. Publishing is rate limited, setDynamicShortcuts returns false when the limit is active, and there is an isRateLimitingActive check. Do not drive it from a scroll handler.

Every shortcut is an intent or a type string, so the real work is routing. The user taps Compose and lands on the compose screen, cold start included. That is the same problem as mobile app deep linking, and an action that dumps the user on your home screen is worse than no action at all. One Android trap worth knowing before you test: a static shortcut cannot carry custom intent flags. Its first intent always gets FLAG_ACTIVITY_NEW_TASK and FLAG_ACTIVITY_CLEAR_TASK, which destroys the activities your app already had open.

The permission, the refusal, and the old API people still describe

For the menu itself there is no permission on either platform. Nothing to declare, nothing to request, nothing a user can refuse. The long press app shortcuts menu is drawn by the system from what you declared. A user who does not want it simply does not long press. The approval in this feature exists on one side only, and it is for pinning: putting a second icon on the launcher that opens straight into one action.

Google's documented flow is check, build, request. Call isRequestPinShortcutSupported() first. Build a ShortcutInfoCompat with an id, an intent and a short label. Then call requestPinShortcut() from a foreground activity or foreground service, or it throws. The reference for that method says the default launcher receives the request and asks the user for approval. It also says that if a request is denied by the user, no response will be sent to the caller. There is no denied callback. Silence is the refusal, so never leave your interface waiting on a result. A true return value only tells you the launcher supports pinning, not that anything was pinned. It returns false when the default launcher does not support pinning, and when App Lock is enabled for your app.

This is also where an API was replaced, which matters because many pages on this subject predate it. Android 8.0 made the com.android.launcher.action.INSTALL_SHORTCUT broadcast a private implicit broadcast with no effect on your app. The documentation says to create the shortcut with requestPinShortcut() from ShortcutManager instead. Anything telling you to send an INSTALL_SHORTCUT broadcast is describing something that stopped working. Google's compatibility library still falls back to that legacy intent below Android 8.0, which is the only context where the old name is still correct.

Neither platform's documentation names special hardware for any of this. Apple's own debugging recipe is to install the app and quit it. Then open Product, then Scheme, then Edit Scheme, and set the Run scheme's Info tab to Wait for executable to be launched. Then touch and hold the icon and pick an action. Google's recipe is to install on a device with a launcher that supports shortcuts, touch and hold the icon, and drag a shortcut to pin it. What varies is the launcher, not the hardware, which is exactly why the support check exists. Plan the test accordingly: the menu lives on the home screen, outside your app, so confirm it on an installed build rather than inside a running preview. If what you wanted was a surface showing data without a tap, that is widgets on iOS, a different API with a different budget.