This page contains 7 additions and 138 deletions.
Need
Validation loop
Default options
xcodebuild, simulator checks, and focused runtime routing verification
Why it's needed
The hard part is not just compiling the intents target, but proving that the app opens or routes to the right place when the system invokes an intent.
11name: Add iOS app intents# Add iOS app intents | Codex use cases
2tagline: Use Codex to make your app's actions and content available to
3 Shortcuts, Siri, Spotlight, and newer assistant-driven system experiences.
4summary: Use Codex and the Build iOS Apps plugin to identify the actions and
5 entities your app should expose through App Intents, wire them into system
6 surfaces like Shortcuts and Spotlight, and prepare your app for more
7 assistant-driven workflows over time.
8skills:
9 - token: build-ios-apps
10 url: https://github.com/openai/plugins/tree/main/plugins/build-ios-apps
11 description: Use the iOS build and SwiftUI skills to add App Intents, app
12 entities, and App Shortcuts, then validate that the app still builds and
13 routes intent-driven entry points correctly.
14bestFor:
15 - iOS apps that already have useful actions or content but are still invisible
16 to Shortcuts, Siri, Spotlight, or the wider system
17 - Teams that want to expose a few high-value actions now and build toward more
18 assistant-friendly workflows over time
19 - Apps with clear objects like accounts, lists, filters, destinations, drafts,
20 or media that can become app entities instead of staying locked inside the
21 UI
22starterPrompt:
23 title: Add App Intents for System and Assistant Surfaces
24 body: >-
25 Use the Build iOS Apps plugin to audit this iOS app and add App Intents for
26 the actions and entities that should be exposed to the system.
27 2
3Need
28 4
295 Constraints:Validation loop
30 6
317 - Start by identifying the app's highest-value user actions and core objectsDefault options
32 that should be available outside the app in Shortcuts, Siri, Spotlight,
33 widgets, controls, or newer assistant-driven system surfaces.
34 8
359 - Keep the first pass focused. Pick a small set of intents that are`xcodebuild`, simulator checks, and focused runtime routing verification
36 genuinely useful without opening the full app, plus any open-app intents
37 that should deep-link into a specific screen or workflow.
38 10
3911 - Define app entities only for the data the system actually needs toWhy it's needed
40 understand and route those actions. Do not mirror the entire internal model
41 layer if a smaller entity surface is enough.
42 12
4313 - Add App Shortcuts where they make the experience more discoverable, andThe hard part is not just compiling the intents target, but proving that the app opens or routes to the right place when the system invokes an intent.
44 choose titles, phrases, and display representations that would make sense in
45 Siri, Spotlight, and Shortcuts.
46 14
47 - If the app needs to handle the intent inside the main UI, route the result
48 back into the app cleanly and explain how the app scene reacts to that
49 handoff.
50
51 - Build and validate the app after the first pass, then summarize which
52 actions, entities, and system surfaces are now supported.
53
54
55 Deliver:
56
57 - the recommended intent and entity surface for a first release
58
59 - the implemented intents, entities, and App Shortcuts
60
61 - how the app routes or handles those intents at runtime
62
63 - which Apple system experiences this unlocks now and which ones are logical
64 next steps
65relatedLinks:
66 - label: App Intents overview
67 url: https://developer.apple.com/documentation/appintents/making-actions-and-content-discoverable-and-widely-available
68 - label: Apple system experiences sample
69 url: https://developer.apple.com/documentation/appintents/adopting-app-intents-to-support-system-experiences
70techStack:
71 - need: Action exposure
72 goodDefault: "[App
73 Intents](https://developer.apple.com/documentation/appintents/making-acti\
74 ons-and-content-discoverable-and-widely-available)"
75 why: App Intents are the system contract that lets your app’s actions show up in
76 Shortcuts, Siri, Spotlight, widgets, controls, and newer assistant-facing
77 surfaces.
78 - need: App data surface
79 goodDefault: "`AppEntity`, `EntityQuery`, and display representations"
80 why: A small, well-shaped entity layer makes it possible for the system to
81 understand your app’s objects without exposing your entire model layer.
82 - need: Discoverability layer
83 goodDefault: "`AppShortcutsProvider` with clear phrases, titles, and symbols"
84 why: App Shortcuts make the first set of exposed actions easier to find and run
85 without asking users to build everything from scratch.
86 - need: Validation loop
87 goodDefault: "`xcodebuild`, simulator checks, and focused runtime routing verification"
88 why: The hard part is not just compiling the intents target, but proving that
89 the app opens or routes to the right place when the system invokes an
90 intent.
91
92## Make the right parts of your app visible to the system
93
94App Intents are one of the clearest ways to make an iOS app more useful outside its own UI. Instead of treating your app as a sealed destination that only works after someone launches it and taps around, use Codex to expose the actions and objects that should be available to Shortcuts, Siri, Spotlight, widgets, controls, and newer assistant-driven system experiences.
95
96That is useful today for discoverability and automation, and it is a strong preparation step for a more assistant-driven future. If your app already knows how to compose, open, filter, route, or summarize something valuable, App Intents give the system a structured way to ask for that capability.
97
98## Start with actions and entities, not with every screen
99
100The best first App Intents pass is usually not “mirror the whole app.” Ask Codex to identify:
101
102- the few actions a user would want to trigger without navigating the full interface
103- the app objects the system needs to understand to route those actions correctly
104- the workflows that should open the app in a specific state versus the ones that should complete directly from a system surface
105
106Apple’s App Intents guidance is a good frame here: define the action, define the entity surface the system needs, then make those actions discoverable and reusable across system experiences. The most useful references are [Making actions and content discoverable and widely available](https://developer.apple.com/documentation/appintents/making-actions-and-content-discoverable-and-widely-available), [Creating your first app intent](https://developer.apple.com/documentation/appintents/creating-your-first-app-intent), and the system-experience sample [Adopting App Intents to support system experiences](https://developer.apple.com/documentation/appintents/adopting-app-intents-to-support-system-experiences).
107
108## Think in system surfaces, not just in shortcuts
109
110The opportunity is broader than “add one shortcut.” A good App Intents surface can make your app useful in several places:
111
112- Shortcuts, where users can run actions directly or compose them into larger automations
113- Siri, where the app can expose meaningful verbs and deep links instead of only opening generically
114- Spotlight, where app entities and app shortcuts become discoverable system entry points
115- widgets, Live Activities, controls, and other intent-driven UI surfaces
116- newer assistant-facing experiences, where structured actions and entities are much easier for the system to understand than arbitrary UI flows
117
118## Follow a real app pattern
119
120This usually works best when the app adopts a structure like this:
121
122- a dedicated App Intents target instead of scattering intent types across unrelated app files
123- `AppShortcutsProvider` entries for high-value user actions like composing a post or opening the app on a specific tab
124- small `AppEntity` types for things the system needs to reason about, such as accounts, lists, and timeline filters
125- intent handling that routes back into the main app scene cleanly, so an invoked intent can open the right compose flow or switch the app to the right tab
126
127That is the pattern I would ask Codex to follow for most apps: start with a small system-facing action layer, keep the entity surface narrow, and wire a predictable runtime handoff back into the app when the intent needs the main UI.
128
129## Ask Codex to design the first intent surface
130
131The strongest prompt here is one that gives Codex your app’s core objects and top user actions, then asks it to choose the smallest useful first App Intents surface instead of blindly exposing everything.
132
133## Practical tips
134
135### Expose verbs users actually want outside the app
136
137Good first intents are usually things like compose, open, find, filter, start, continue, or inspect. If an action is only useful after a long in-app setup flow, it may not belong in the first App Intents pass.
138
139### Keep entities smaller than your model layer
140
141The system usually does not need your full persistence model. Ask Codex to define the smallest app entity surface that still gives Siri, Shortcuts, and Spotlight enough context to route and display the action correctly.
142
143### Treat this as assistant infrastructure, not only a shortcuts feature
144
145Even if your first release only visibly improves Shortcuts or Siri, the deeper win is that your app starts speaking in structured actions and entities. That makes it easier to participate in future system and AI-driven entry points than an app whose capabilities are only encoded in taps and view hierarchies.
