I developed a XCode project using Flutter (v. 3.35.6). The application basically has a IntentExtension to handle intents donation and the related business logic. We decided to go with ShortcutExtension in place of AppIntents because it fits with our app's use case (where basically we need to dynamically donate/remove intents). We have an issue building the project, and it is due to the presence of the IntentExtension .appex file in the Build Phases --> Embed Foundation Extensions. If we remove it , the project builds however the IntentHandling is not invoked in the Shortcuts app. Build issue: Generated error in the console: Cycle inside Runner; building could produce unreliable results. Cycle details: → Target 'Runner' has copy command from '/Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/ShortcutsExtension.appex' to '/Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/PlugIns/ShortcutsExtension.appex' ○ That command depends on command in Target 'Runner': script phase “[CP] Copy Pods Resources” ○ That command depends on command in Target 'Runner': script phase “[CP] Embed Pods Frameworks” ○ That command depends on command in Target 'Runner': script phase “FlutterFire: "flutterfire upload-crashlytics-symbols"” ○ That command depends on command in Target 'Runner': script phase “FlutterFire: "flutterfire bundle-service-file"” ○ That command depends on command in Target 'Runner': script phase “Thin Binary” ○ Target 'Runner' has process command with output '/Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/Info.plist' ○ Target 'Runner' has copy command from '/Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/ShortcutsExtension.appex' to '/Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/PlugIns/ShortcutsExtension.appex' Raw dependency cycle trace: target: -> node: -> command: -> node: /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Intermediates.noindex/Runner.build/Release-quality-iphoneos/Runner.build/Objects-normal/arm64/ExtractedAppShortcutsMetadata.stringsdata -> command: P0:target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49-:Release-quality:ExtractAppIntentsMetadata -> node: -> command: P0:::Gate target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49--fused-phase10-copy-files -> node: <Copy /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/PlugIns/ShortcutsExtension.appex> -> CYCLE POINT -> command: P0:target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49-:Release-quality:Copy /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/PlugIns/ShortcutsExtension.appex /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/ShortcutsExtension.appex -> node: -> command: P0:::Gate target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49--fused-phase9--cp--copy-pods-resources -> node: /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/GoogleMapsResources.bundle -> command: P2:target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49-:Release-quality:PhaseScriptExecution [CP] Copy Pods Resources /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Intermediates.noindex/Runner.build/Release-quality-iphoneos/Runner.build/Script-B728693F1F2684724A065652.sh -> node: -> command: P0:::Gate target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49--fused-phase8--cp--embed-pods-frameworks -> node: /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Products/Release-quality-iphoneos/Runner.app/Frameworks/Alamofire.framework -> command: P2:target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49-:Release-quality:PhaseScriptExecution [CP] Embed Pods Frameworks /Users/federico.gatti/Documents/comfort-mobile-app/apps/comfort/ios/DerivedData/Runner/Build/Intermediates.noindex/Runner.build/Release-quality-iphoneos/Runner.build/Script-1A1449CD6436E619E61D3E0D.sh -> node: -> command: P0:::Gate target-Runner-18c1723432283e0cc55f10a6dcfd9e0288a783a885d8b0b3beb2e9f90bde3f49--fused-phase7-flutterfire---flutterfire-upload-crashlytics-symbols- -> node: <execute-shell-script-18c1723432283e0cc55f10a6dcfd9e024008e7f13be1da4979f78de280354094-target-Runner-18c1723432283e

We implemented AppIntents using EnumerableEntityQuery and @Dependency and we are receiving these crash reports: AppIntents/AppDependencyManager.swift:120: Fatal error: AppDependency of type MyDependency.Type was not initialized prior to access. Dependency values can only be accessed inside of the intent perform flow and within types conforming to _SupportsAppDependencies unless the value of the dependency is manually set prior to access. I can't post the stack because of the Developer Forums sensitive language filter :( but basically it's just a call to suggestedEntities of MyEntityQuery that calls the dependency getter and then it crashes. My understanding was that when using @Dependency, the execution of the intent, or query of suggestedEntities in this case, would be delayed by the AppIntents framework until the dependency was added to the AppDependencyManager by me. At least that's what's happening in my tests. But in prod I'm having these crashes which I haven't been able to reproduce in dev yet. Does anyone know if this is a bug or how can this be fixed? As a workaround, I can avoid using @Dependency and AppDependencyManager completely and make sure that all operations are async and delay the execution myself until the dependency is set. But I'd like to know if there's a better solution. Thanks!

Here is the appleScript part of my script: tell application "Finder" activate open application file "Messages.app" of folder "Applications" of folder "System" of startup disk end tell What I need is a step to send the message already inside the Mesage.app. The message is ready to send. I just would like a step that will act as "Return" to send the message. Again I have already prepared message to send but just need a step to send the message. Is there a possible step to perform the" Return" command to iMessage?

App intent has a perform method that is async and can throw an error, but I can't find a way to actually await the result and catch the error if needed. If I convert this working but non-waiting, non-catching code: Button("Go", intent: MyIntent()) to this (so I can control awaiting and error handling): Button("Go") { Task { do { try await MyIntent().perform() // 👈 } catch { print(error) } } } It crashes: AppDependency with key "foo" of type Bar.Type was not initialized prior to access. Dependency values can only be accessed inside of the intent perform flow and within types conforming to _SupportsAppDependencies unless the value of the dependency is manually set prior to access. Although it is invalid since the first version is working like a charm and dependencies are registered in the @main App init method and it is in the perform flow. So how can we await the result of the AppIntent and handle the errors if needed in the app? Should I re-invent the Dependency mechanism?

I've heard that when a Mac app implements their version of the Standard AppleEvent suite, the developer can copy "CocoaStandard.sdef" and trim out whatever they don't need. What are the constraints on this trimming? I guess that we could remove commands wholesale, but can we remove sub-parts of a command? Can we change an enumeration? A record type?

I was looking through: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html And wondered how these are handled for SwiftUI apps. What would I add or override?

I'm implementing app intents for my tasks app which supports recurrence rule for tasks. I see that when creating a todo for Reminders via Siri it allows to set a recurrence rule via natural language. Is there a built in way to receive that recurrence rule as a @Parameter in my AppIntent? If not, is it possible to receive the full user dictated text in the AppIntent:perform method so that I can use some ML model to convert the text to EKRecurrenceRule or similar?

I am building an automation using Shortcuts. The shortcut reads text from my Notes, sends it to Apple Intelligence, converts the result into dictionary values, and then saves those values into a Numbers sheet by adding rows through a form. The problem is that when the automation processes multiple lines and adds multiple rows, the Numbers app opens every time a row is added. I would like this process to run automatically at a scheduled time without opening the Numbers app repeatedly on my iPhone. Is there a way to update the Numbers sheet in the background without launching the Numbers app? Please let me know if there is a solution.

I’ve created several shortcuts that tell me the stock price of a given company. The shortcut queries Yahoo Finance using Get Contents of URL, with the URL https://finance.yahoo.com/quote/TICKER SYMBOL/, for example https://finance.yahoo.com/quote/PLTR/ for Palantir or https://finance.yahoo.com/quote/AAPL/ for Apple, etc. Then it uses RegEx to parse out the numbers which it then formats and displays in a notification. Simple. It works great for several stocks, but for some reason, it does not work correctly for Palantir. It shows an older “previous close” price. Oddly, when I go to the website myself, it shows me the current stock price. So for today Mar 21 https://finance.yahoo.com/quote/PLTR/ shows me $90.96 (correct) but the shortcut, via Get Contents of URL, shows $87.39 (incorrect). This $87.39 price is listed further down in the page as a "previous close” price. I don’t get it. Here is a link to my Palantir shortcut: https://www.icloud.com/shortcuts/edea6ee0261245f49b078efc74d632dd Here is a link to my Apple shortcut: https://www.icloud.com/shortcuts/54a416393203432aa356fe76373e3f8b So the question is, why does Get Contents of URL show an old stock price but when I go to the site myself, it shows the correct stock price … and only for Palantir? I have about six shortcuts running correctly. Palantir is the only one that does not work. Been banging my head on this one for weeks. Any advice would be much appreciated. Thank you, Rob

IOS can record a key, a key video, but there is no key recording function, which is really bad👎Yeah, i hope you guys come on.💪

Hello, experts! I'm working on a VOIP application that handles audio calls and integrates with CallKit. The problem occurs when attempting to redial a previously made audio call from the system's call history. When I try to handle the NSUserActivity in the application(_:continue:restorationHandler:) method, it intercepts the INStartAudioCallIntent instead of the expected INStartCallIntent. Background Deprecation Warnings: I'm encountering deprecation warnings when using INStartAudioCallIntent and INStartVideoCallIntent: 'INStartAudioCallIntent' was deprecated in iOS 13.0: INStartAudioCallIntent is deprecated. Please adopt INStartCallIntent instead. 'INStartVideoCallIntent' was deprecated in iOS 13.0: INStartVideoCallIntent is deprecated. Please adopt INStartCallIntent instead. As a result, I need to migrate to INStartCallIntent instead, but the issue is that when trying to redial a call from the system’s call history, INStartAudioCallIntent is still being triggered. Working with Deprecated Intents: If I use INStartAudioCallIntent or INStartVideoCallIntent, everything works as expected, but I want to adopt INStartCallIntent to align with the current iOS recommendations. Configuration: CXProvider Configuration: The CXProvider is configured as follows: let configuration = CXProviderConfiguration() configuration.supportsVideo = true configuration.maximumCallsPerCallGroup = 1 configuration.maximumCallGroups = 1 configuration.supportedHandleTypes = [.generic] configuration.iconTemplateImageData = UIImage(asset: .callKitLogo)?.pngData() let provider = CXProvider(configuration: configuration) Outgoing Call Handle: When making an outgoing call, the CXHandle is created like this: let handle = CXHandle(type: .generic, value: callId) Info.plist Configuration: In the info.plist, the following key is defined: &lt;key&gt;NSUserActivityTypes&lt;/key&gt; &lt;array&gt; &lt;string&gt;INStartCallIntent&lt;/string&gt; &lt;/array&gt; Problem: When trying to redial the audio call from the system's call history, the NSUserActivity received in the application(_:continue:restorationHandler:) method is an instance of INStartAudioCallIntent instead of INStartCallIntent. This happens even though INStartCallIntent is listed in NSUserActivityTypes in the info.plist and I want to migrate to the newer intent as recommended in iOS 13+. Device: iPhone 13 mini iOS version 17.6.1

Platform and Version iOS Development Environment: Xcode 16.2.0, macOS 15.3 Run-time Configuration: iOS 18.3, 17.x Description of Problem We have started migrating some of the app’s core functionality over to App Intents. Our first release of App Intent support focused on two settings a user can modify on their Bose products, Audio Modes and Immersive Audio, giving users the ability to modify these settings via Siri and shortcuts. The implementation uses two separate shortcuts for each setting type, with each shortcut supporting a single phrase for Siri each: “Change my Bose mode to ” and “Change my Bose immersive audio to ”. Each shortcut uses their own App Intent, and each App Intent has support for optionally providing both a product and a setting when performing the intent. Failing to provide a device, which happens when the intent is performed via Siri, simply auto selects a currently connected Bose product. Failing to provide a setting, like in cases where a user says “Change my Bose ” without providing a setting will simply have Siri confirm the setting the user wants to change before changing the setting. We are using AppEntity to identify a Bose product for both App Intents. Because the App Intent for the Audio Modes setting has a larger number of supported values (up to 15 maximum), we are also using AppEntity to identify these settings. We are using AppEnum to identify available settings for the Immersive Audio App Intent, as only 3 static values are supported. Our original implementation of App Intent support had quite a few phrases supported for each shortcut. We had explicit support for direct synonyms of the verb “Change” in other phrases, supporting words like “Switch” and “Set”. We also had support for words that are like the word “Change”, but not directly related, like the word “Toggle” for instance. We also had support for phrases with or without the setting in each phrase. However, early on we had a lot of trouble with phrase detection with Siri. Siri had a hard time identifying what shortcut was being requested, as well as not being able to identify what settings the user was providing for the setting parameter of each App Intent. While researching potential fixes for this issue, we found a response to a thread in the Apple forums (https://developer.apple.com/forums/thread/759909) that seemed to indicate that Siri phrase recognition was very much an aggregate process. With the total number of phrases supported combined with the available settings for each phrase further compounding the total number of phrases Siri needs to learn to recognize for each shortcut. So, to hopefully improve Siri phrase detection, we added logic to limit the amount of Audio Mode settings supported based on what Audio Modes the user had setup on their Bose products. But, more importantly, we limited the number of explicit phrases supported for each shortcut to just a single phrase. In our testing, not only did this improve phrase recognition, but support for synonyms like “Set” or “Switch” seemed to implicitly still be recognized by Siri. The issues we ran into with Siri phrase detection above has us a bit concerned about scaling App Intent support to other settings and features for our products in the future. Our app supports the ability to modify a large number of settings on their Bose products, with support constantly expanding to new products as they are released. Our roadmap for App Intent support was initially very ambitious, supporting much more than just the two settings mentioned above. But our initial experience with App Intents has us tapering our expectations a little bit as far as how much can be supported in total for App Intents. One thing we also noticed is less than optimal display of default shortcuts in the Shortcuts app. The default shortcuts appeared like so, with shortcuts displayed based on available settings fro each shortcut: However, we could not find a way to indicate to users that one particular section pertained specifically to the Audio Mode setting and the other to the Immersive Audio setting. The only information the user has to make this determination for themselves is the available settings (or shortcuts) for each. This may not be immediately clear to a new customer who might be using one of our products for the first time. This display of default shortcuts in the Shortcuts app has us wondering if our shortcuts implementation is what is intended as far as support for the Shortcuts app is concerned. We did survey default shortcuts displayed by other third-party applications and they mostly dealt with navigation with a single section containing default options clearly indicating where the user can navigate with a shortcut. We couldn’t find an example of an application supporting the ability to change different setting types, with each setting type having their own available values for each. So, to summarize the questions we have concerning App Intent support: What can we do with our App Intents and Shortcuts implementation to guarantee optimal performance with Siri? What is an ideal number of phrases to support for each Shortcut. What limitations should we be placing as far as the total number of available settings for each Shortcut. Are there phrases that might work better than others for what we’re trying to achieve with App Intent support? i.e. Is “Change my Bose mode” or “Change my Bose immersive audio” a good phrase to use for this kind of functionality? Or should we be using different verbs or wording? Assuming optimal support of each Shortcut above. What is a reasonable expectation as far as how many different supported shortcuts we can scale to support at the same time. One issue we ran into early on was Siri confusing one shortcut with the other and triggering the wrong App Intent at times. While this was ultimately resolved, this outcome seems much more likely the greater the number of individual shortcuts supported. Are there any recommendations on how to display these App Intents to customers as far as default shortcuts in the Shortcuts app is concerned? Is what we currently display for default shortcuts in the Shortcuts app what was initially intended for third party support for App Intents? If what we are currently displaying is expected, would it be possible to support the ability to provide additional context to each section of default shortcuts displayed? We would like to indicate to the user that one set of shortcuts pertains to the Audio Modes settings, and the other to Immersive Audio. Something along the lines of a section header like some of the first-party apps use. Are there any recommendations or tips for supporting App Intents, particularly phrases for Siri, in other languages?

When using NSScriptCommand, is there any way to create an NSAppleEventDescriptor from an NSDictionary with arbitrary keys without using keyASUserRecordFields? Am I correct in thinking that this constant is deprecated? I ask because there is still active documentation using it. Is there another way to return a record where the keys aren't known at compile-time?

While playing around with AppShortcuts I've been encountering some problems around getting the invocation phrase detected and/or the parameter get recognized after invocation phrase via Siri. I've found some solutions or explanations here in other posts (Siri not recognizing the parameter in the phrase & Inform iOS about AppShortcutsProvider), but I still have one issue and it's about consistency. For context, I've defined the parameter to be an AppEntity with it's respective query conforming to the EntityStringQuery Protocol in order to be able to fetch entities with the string given by Siri struct AnIntent: AppIntent { // other parts hidden for clarity @Parameter var entity: ModelEntity } For an invocation phrase akin to "Do something with in ", if the user uses the phrase with a entity previously donated via suggestedEntities() the AppShortcut get executed without problems. If the user uses a phrase with no parameter, like "do something with ", if the user gets asked to input the missing parameter and inputs one, it may or may not get recognized and be asked to input a parameter again, like in a loop. This happens even if the parameter given is one that was donated. I've found that when this happens the entities(matching string: String) function in the EntityQuery doesn't get called. The input can be of one word or sometimes two and it will not be called. So in other words entities(matching string: String) does not get called on every user parameter input Is this behavior correct? Do parameters have some restrictions on length or anything? Does Siri shows the user suggested entities when asked for entity input? It doesn't on my end. Additional question related to AppShortcuts: On AppShortcut definition, where the summary inside the parameter presentation is used? I see that it was defined in the AppIntentsSampleApp for the GetTrailInfo Intent but didn't find where it was used

I'd like to display a list of items to disambiguate for a fulltext search intent. Using the Apple AppIntentsSampleApp, I added TrailSearch.swift: import AppIntents @AssistantIntent(schema: .system.search) struct TrailSearch: AppIntent { static let title: LocalizedStringResource = "Search Trail" static let description = IntentDescription("Search trail by name.", categoryName: "Discover", resultValueName: "Trail") @Parameter(title: "Trail") var criteria: StringSearchCriteria func perform() async throws -> some IntentResult & ReturnsValue<TrailEntity> { if criteria.term.isEmpty { throw $criteria.needsValueError(IntentDialog("need value")) } let trails = TrailDataManager.shared.trails { trail in trail.name.contains(criteria.term) } if trails.count > 1 { throw $criteria.needsDisambiguationError(among: trails.map { StringSearchCriteria(term: $0.name) }) } else if let firstTrail = trails.first { return .result(value: TrailEntity(trail: firstTrail)) } throw $criteria.needsValueError(IntentDialog("Nothing found")) } } Now when I type "trail" which matches several trails and thus lets us enter the disambiguation code path, the Shortcut app just displays the dialog title but no disambiguation items to pick from. Is this by design or a bug? (filed as FB17412220)

The built-in Books and iMessages on the latest macOS can not handle Shortcuts properly. If Books (no matter the Home scheme or the reading scheme) or iMessages is the current focused application, Shortcuts doesn't work. Once I move out and focus app turns to Finder or any other app, Shortcuts works properly. An exception is that when I pin the shortcut in the Menu Bar, the Menu Bar one works, while the one in the application's menu doesn't work. I have no idea why this would happen. Could it be part of privilege control or something?

Hi Community, I'm new on Siri intents and I'm trying to introduce into my App a Siri Intent for Car Commands. The objective is to list into the Apple Maps the Car list of my App. Currently I've created my own target with its corresponding IntentHandlings, but in the .intentdefinition file of my App, I'm not able to find the List Car Intent. https://developer.apple.com/documentation/sirikit/car-commands Do I need some auth? Also I share my info.plist from the IntentExtension. Thank you very much, David.

Sorry if topic is not exact. I write Ainu in various Roman Latin scripts on English GUI Catalina ,Text Edit. The Ainu words are similar to English ex. 'an' in Ainu is 'exist' ,Ainu Language exists 'Ne Ainu itak an ',so spell checker will not red dot many words also some Ainu words look like other foreign words. I open LocalDictionary and find it blank ,so I open TextEdit and open show spelling grammar 100 words out of 200 are red dotted !the others are not learned, so I press' learn' and it skips to some words not Allan after 100 it stops ,then I go to LocalDictionary and see all those words alphabetical order ,! great ! but what about the rest ? why does select half of the words and /part/ of a phrase/ 'Itak a-e-yay-/han-nok-kar-a' = to study language by oneself.

Guys has anyone here used the PlayVideoIntent protocol while implementing app intents? If yes can you please walk me though what purpose it solves and what features and functionality I can unlock with it? Link to apple's documentation -> https://developer.apple.com/documentation/appintents/playvideointent

I am creating scripts to automatically switch the wallpapers on my multiple displays. System Events exposes almost all of the options accessible in the Wallpapers pane of system settings, but not the option to "Show on all Spaces". I want to add that option to the following script: tell application "System Events" set intervalSeconds to 900.0 set wpDir to POSIX file "/Path/to/Folder/" set picture rotation of every desktop to 1 set random order of every desktop to true set pictures folder of every desktop to wpDir set change interval of every desktop to intervalSeconds do shell script ("killall Dock") end tell Also, the foregoing script does not seem to successfully set the interval value, although it does not throw an error. Not sure why that does not work. Any thoughts or insights would be welcome. Thank you