When you correctly implement EntityPropertyQuery on an AppEntity, Shortcuts will expose a "Find Entity" action that calls into entities(matching:mode:sortedBy:limit:). This is demoed in the "Dive into App Intents" session and works as expected. However, with this action, you can change the "All Entity" input to a list variable which changes the action text from "Find All Entity" to "Filter Entity where" still giving you the same filter, sort and limit options. This appears to work as expected too. But, what's unexpected is that this filter action does not appear to call any method on my AppEntity code. It doesn't call entities(matching:mode:sortedBy:limit:). One would think there would need to be a filter(entities:matching:mode:sortedBy:limit:) to implement this functionality. But Shortcut just seems to do it all on it's own. I'm mostly wondering, how is this even working? Here's some example code: import AppIntents let books = [ BookEntity(id: 0, title: "A Family Affair"), BookEntity(id: 1, title: "Atlas of the Heart"), BookEntity(id: 2, title: "Atomic Habits"), BookEntity(id: 3, title: "Memphis"), BookEntity(id: 4, title: "Run Rose Run"), BookEntity(id: 5, title: "The Maid"), BookEntity(id: 6, title: "The Match"), BookEntity(id: 7, title: "Where the Crawdads Sing"), ] struct BookEntity: AppEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation = "Book" var displayRepresentation: DisplayRepresentation { DisplayRepresentation(title: "\(title)") } static var defaultQuery = BookQuery() var id: Int @Property(title: "Title") var title: String init(id: Int, title: String) { self.id = id self.title = title } } struct BookQuery: EntityQuery { func entities(for identifiers: [Int]) async throws -> [BookEntity] { return identifiers.map { id in books[id] } } } extension BookQuery: EntityPropertyQuery { static var properties = QueryProperties { Property(\BookEntity.$title) { EqualToComparator { str in { book in book.title == str } } ContainsComparator { str in { book in book.title.contains(str) } } } } static var sortingOptions = SortingOptions { SortableBy(\BookEntity.$title) } func entities( matching comparators: [(BookEntity) -> Bool], mode: ComparatorMode, sortedBy: [Sort<BookEntity>], limit: Int? ) async throws -> [BookEntity] { books.filter { book in comparators.allSatisfy { comparator in comparator(book) } } } } The example Shortcut first invokes entities(matching:mode:sortedBy:limit:) with comparators=[], sortedBy=[], limit=nil to fetch all Book entities. Next the filter step correctly applies the title contains filter but never calls entities(matching:mode:sortedBy:limit:) or even the body of the ContainsComparator. But the output is correctly filtered.

Hi, new to this forum. Recently discovered how to share a location in Maps app with my Tesla to automatically start navigating. How cool is that! Being the nerd that I am, I wrote a shortcut to select a contact and share it's address with my Tesla. That way, I don't leave the Maps app in memory to use up my battery, and don't have to go to all the trouble of swiping Maps out of memory. JK. Anyway, when I share the shortcut-selected address with the Tesla, it says "Error this content could not be shared". To me this means the address as shared by the shortcut is not in the same format as when you share it directly from Maps. So the question is, how can I send a properly formatted location from my shortcut? Thanks...

Hi! I have an AppShortcutsProvider that has been marked @available(iOS 17.0, *), because all Intents used within it are only available in iOS 17. So the static var appShortcuts should only be accessible in iOS 17, obviously. Now this code has been released and works fine for iOS 17 users. But I just noticed that around 150 iOS 16 users have crashed in the static var appShortcuts, or more specifically, the defaultQuery of one of the Intents. This should not be possible, as neither the AppShortcutsProvider, nor the Intent is exposed to iOS 16, they are marked as @available(iOS 17.0, *). Any idea why this could happen? Here is the crash log: Crashed: com.apple.root.user-initiated-qos.cooperative 0 libswiftCore.dylib 0x3e178c swift::ResolveAsSymbolicReference::operator()(swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*) 1 libswiftCore.dylib 0x40bec4 swift::Demangle::__runtime::Demangler::demangleSymbolicReference(unsigned char) 2 libswiftCore.dylib 0x408254 swift::Demangle::__runtime::Demangler::demangleType(__swift::__runtime::llvm::StringRef, std::__1::function<swift::Demangle::__runtime::Node* (swift::Demangle::__runtime::SymbolicReferenceKind, swift::Demangle::__runtime::Directness, int, void const*)>) 3 libswiftCore.dylib 0x3e9680 swift_getTypeByMangledNameImpl(swift::MetadataRequest, __swift::__runtime::llvm::StringRef, void const* const*, std::__1::function<swift::TargetMetadata<swift::InProcess> const* (unsigned int, unsigned int)>, std::__1::function<swift::TargetWitnessTable<swift::InProcess> const* (swift::TargetMetadata<swift::InProcess> const*, unsigned int)>) 4 libswiftCore.dylib 0x3e4d9c swift_getTypeByMangledName 5 libswiftCore.dylib 0x3e50ac swift_getTypeByMangledNameInContext 6 MyApp 0x3f6b8c __swift_instantiateConcreteTypeFromMangledName (<compiler-generated>) 7 MyApp 0x640e3c one-time initialization function for defaultQuery + 146 (IntentAction.swift:146) 8 libdispatch.dylib 0x3eac _dispatch_client_callout 9 libdispatch.dylib 0x56ec _dispatch_once_callout 10 MyApp 0x64109c protocol witness for static AppEntity.defaultQuery.getter in conformance IntentAction + 124 (IntentAction.swift:124) 11 AppIntents 0x15c760 _swift_stdlib_malloc_size 12 AppIntents 0x19dfd4 __swift_destroy_boxed_opaque_existential_1Tm 13 MyApp 0x52dadc specialized ActionIntent.init(action:) + 41 (ActionIntent.swift:41) 14 MyApp 0x52df80 specialized static MyShortcuts.appShortcuts.getter + 17 (MyShortcuts.swift:17)

Hello. How to write this command correctly on a Macbook, in the script editor, so that I can click the "Run script" button and the script will give the result: if there is no folder, then report that there is no folder, if there is a folder, then report that the folder exists. do shell script "test -d 'Users/user/Desktop/New folder'" Now, if the folder exists, an empty string ("") is returned, if the folder does not exist, the script editor reports that an error has occurred. In general, my task is to write a script that checks the existence of a folder.

I have added an "App Intents Extension" target to my main application in macOS. This generated the below two files: TWAppIntent.swift import AppIntents struct TWAppIntent: AppIntent { static var title: LocalizedStringResource = "TWAppIntentExtension" static var parameterSummary: some ParameterSummary { Summary("Get information on \(\.$TWType)") } //launch app on running action static var openAppWhenRun: Bool = true // we can have multiple parameter of diff types @Parameter(title: "TWType") var TWType: String func perform() async throws -> some IntentResult & ReturnsValue<String> & ProvidesDialog { return .result(value: TWType, dialog: "Logged break.") } } TWAppIntentExtension.swift import AppIntents @main struct TWAppIntentExtension: AppIntentsExtension { } I m able to build the extension target and I my intent action is available in the shortcuts app. However, on launching a shortcut with the above created intent action. I m getting the below popups: I have identified what is causing this error. Setting the openAppWhenRun to true is causing this error. I don't get this when it is set to false. This property is supposed to launch the application, but can someone help me understand why is it happening? This is only causing the error when using this property for AppIntent Extension and not for In app handling for the AppIntent. Can we not launch our application from AppIntent extension?

My team is preparing for iOS 18, and wanted to add intents using assistant schemas that are iOS 18 and above restricted. We noticed that the result builder for AppShortcuts added support for limitedAvailabilityCondition from iOS 17.4 so we marked the whole struct as available from it. The app compiles but writing a check like below inside appShortcuts property a crash will happen in iOS 17.5 runtime. (Removing the #available) is solving this problem. if #available(iOS 18, *) { AppShortcut( intent: SearchDonut(), phrases: [ "Search for a donut in \(.applicationName)" ], shortTitle: "search", systemImageName: "magnifyingglass" ) } We tried out putting the os check above and returning shortcuts in arrays and that both compiles and runs but then AppShortcuts.strings sends warnings that the phrases are not used (This phrase is not used in any App Shortcut or as a Negative Phrase.) because the script that extracts the phrases somehow fails to perform when shortcuts are written like below: static var appShortcuts: [AppShortcut] { if #available(iOS 18.0, *) { return [ AppShortcut( intent: CreateDonutIntent(), phrases: [ "Create Donut in \(.applicationName)", ], shortTitle: "Create Donut", systemImageName: "pencil" ) ] } else { return [ AppShortcut( intent: CreateDonutIntent(), phrases: [ "Create Donut in \(.applicationName)", ], shortTitle: "Create Donut", systemImageName: "pencil" ) ] } } This is very problematic because we can't test out on TF with external users new intents dedicated for iOS 18. We filed a radar under FB15010828

I am trying to implement URLRepresentableEntity on my AppEntity I am following along with the WWDC video here All compiles fine when I use the ID as in the video: extension SceneEntity: URLRepresentableEntity { static var urlRepresentation: URLRepresentation { "https://example.com/scene/\(.id)" } } but my URLs need to use a different property on the Entity. The WWDC video clearly states: "Notice that I'm using the entity’s identifier as an interpolated value. You can use an entity’s ID or any of its properties with the @Property attribute as interpolations in the URL string." So I annotated my entity with the @Property attribute and expected that to work but it doesn't compile. struct SceneEntity: AppEntity { let id: UUID @Property(title: "Slug") var slug: String } extension SceneEntity: URLRepresentableEntity { static var urlRepresentation: URLRepresentation { "https://example.com/scene/\(.slug)" } } Type 'EntityURLRepresentation.StringInterpolation.Token' has no member 'slug' How can I use this API with a property that is not the ID?

使用APPIntent 的AppShortcutsProvider方式，最多只能添加10个AppShortcut，超过10个，代码编译就会报错 struct MeditationShortcuts: AppShortcutsProvider { static var appShortcuts: [AppShortcut] { AppShortcut( intent: StartMeditationIntent(), phrases: [ "Start a (.applicationName)", "Begin (.applicationName)", "Meditate with (.applicationName)", "Start a (.$session) session with (.applicationName)", "Begin a (.$session) session with (.applicationName)", "Meditate on (.$session) with (.applicationName)" ] ) } } 如何能做到像特斯拉APP一样

how to register more than 10 shortcuts

The following code works perfectly fine in iOS 17, where I can retrieve the desired dependency value through @IntentParameterDependency as expected. However, in iOS 18, addTransaction always returns nil. struct CategoryEntityQuery: EntityStringQuery { @Dependency private var persistentController: PersistentController @IntentParameterDependency<AddTransactionIntent>( \.$categoryType ) var addTransaction func entities(matching string: String) async throws -> [CategoryEnitity] { guard let addTransaction else { return [] } // ... } func entities(for identifiers: [CategoryEnitity.ID]) async throws -> [CategoryEnitity] { guard let addTransaction else { return [] } // ... } func suggestedEntities() async throws -> [CategoryEnitity] { guard let addTransaction else { return [] } // ... } } Has anyone else encountered the same issue? Any insights or potential workarounds would be greatly appreciated. iOS: 18.0 (22A3354) Xcode 16.0 (16A242d)

Description The Shortcut Automation Trigger Transaction frequently times out, ultimately causing the shortcut automation to fail. Please see the attached trace for details. Additionally, the Trigger is activated even when the Transaction is declined. Details In the trace I see the error: [WFWalletTransactionProvider observeForUpdatesWithInitialTransactionIfNeeded:transactionIdentifier:completion:]_block_invoke Hit timeout waiting for transaction with identifier: <private>, finishing. Open bug report: FB14035016

(Public dupe of FB16477656) The Shortcuts app allows you to parameterise the input for an action using variables or allowing "Ask every time". This option DOES NOT show when conforming my AppEntity.defaultQuery Struct to EntityStringQuery: But it DOES shows when confirming to EntityQuery: As discussed on this forum post (or FB13253161) my AppEntity.defaultQuery HAS TO confirm to EntityStringQuery to allow for searching by String from Siri Voice input. To summarise: With EntityQuery: My Intent looks like it supports variables via the Shortcuts app. But will end up in an endless loop because there is no entities(matching string: String) function. This will allow me to choose an item via the Shorcuts.app UI With EntityStringQuery: My Intent does not support variables via the Shortcuts app. I am not allows to choose an item via the Shorcuts.app UI. Even weirder, if i set up the shortcut with using a build with EntityQuery and then do another build with EntityStringQuery it works as expected. Code: /* Works with Siri to find a match, doesn't show "Ask every time" */ public struct WidgetStationQuery: EntityStringQuery { public init() { } public func entities(matching string: String) async throws -> [Station] { let stations = [Station(id: "car", name: "car"), Station(id: "bike", name: "bike")] return stations.filter { $0.id.lowercased() == string.lowercased() } } public func entities(for identifiers: [Station.ID]) async throws -> [Station] { let stations = [Station(id: "car", name: "car"), Station(id: "bike", name: "bike")] return stations.filter { identifiers.contains($0.id.lowercased()) } } public func suggestedEntities() async throws -> [Station] { return [Station(id: "car", name: "car"), Station(id: "bike", name: "bike")] } public func defaultResult() async -> Station? { try? await suggestedEntities().first } } /* DOES NOT work with Siri to find a match, but Shortcuts shows "Ask every time" */ public struct WidgetBrokenStationQuery: EntityQuery { public init() { } public func entities(matching string: String) async throws -> [Station] { let stations = [Station(id: "car", name: "car"), Station(id: "bike", name: "bike")] return stations.filter { $0.id.lowercased() == string.lowercased() } } public func entities(for identifiers: [Station.ID]) async throws -> [Station] { let stations = [Station(id: "car", name: "car"), Station(id: "bike", name: "bike")] return stations.filter { identifiers.contains($0.id.lowercased()) } } public func suggestedEntities() async throws -> [Station] { return [Station(id: "car", name: "car"), Station(id: "bike", name: "bike")] } public func defaultResult() async -> Station? { try? await suggestedEntities().first } }```

I'm currently trying to use the new @UnionValue macro. From what I understood, it allows multiple types for a parameter. I created the following enum: @UnionValue enum IntentDuration { case int(Int) case duration(Measurement<UnitDuration>) } Then, I tried to use it in the following AppIntent: struct MyIntent: AppIntent { static let title: LocalizedStringResource = "intent.title" static let description = IntentDescription("intent.description") static let openAppWhenRun: Bool = true @Parameter var duration: IntentDuration @Dependency private var appManager: AppManager @MainActor func perform() async throws -> some IntentResult { // My action return .result() } } However, I get the following error from Xcode at the @Parameter line: 'init()' is unavailable Did I wrongly understand how this works? Is there another way to accept multiple types for a parameter? I didn't manage to find any docs on this.

I'll ask Siri: What is the weather?" and will get a valid response I'll ask Siri to execute a shortcut my app has created I get "what is the order?" (a phrase nowhere in my app) I'll repeat the question about the weather I now get "what is the order?" ***?

On iOS 18, I'm trying to index documents in Spotlight using the new combination of AppIntents+IndexedEntity. However, I don't seem to be able to index the textContent of the document. Only the displayName seems to be indexed. As recommended, I start with the defaultAttributeSet: /// I call this function to index in Spotlight static func indexInSpotlight(document: Document) async { do { if let entity = document.toEntity { try await CSSearchableIndex.default().indexAppEntities([entity]) } } catch { DLog("Spotlight: could not index document: \(document.name ?? "")") } } /// This is the corresponding IndexedEntity with the attributeSet @available(iOS 18, *) extension DocumentEntity { var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title attributeSet.textContent = docContent attributeSet.thumbnailData = thumbnailData attributeSet.kind = "document" attributeSet.creator = Constants.APP_NAME return attributeSet } } How can I have more that the displayName to be indexed? Thanks :-)

I need to have a dynamic parameter for Shortcuts, so a person can say something like Hey Siri, order a pizza with The parameter code in the appIntent is @Parameter(title: "Title") var itemName: String In the Shortcut I use: AppShortcut( intent: NewItemIntent(), phrases: [ "order \(\.$itemName) using \(.applicationName)" ], shortTitle: "Order Item", systemImageName: "sparkles" ) When I call it "hey Siri, order pizza using ***" where pizza should be passed via the parameter then handed off to the appintent. However, it ignores the spoken parameter in lieu of putting up a dialog asking "What's the name?" I can say "pizza" and it now works. How can I pick up the parameter without having to go to that second step as the code implies?

I dont know if this is the appropriate forum for this. Answers I've found on the web points me towards intentions, but somehow I couldnt make it work. Im trying to activate siri on carplay to ask user for voice input then make a search. Is this a custom intent capability or is there any other way.

I'm developing an AppIntent with a Duration parameter, the definition looks like this: @Parameter(title: "Duration", description: "Time entry duration") var duration: Measurement<UnitDuration> When I run this AppIntent using Siri voice command (by a shortcut) the system asks for the duration value, however when I try to say "1 hour 10 minutes" the "hour" component is ignored, in the AppIntent's perform() method I see only the minutes set (so in this case only 10 minutes). Is there any way to use the Duration type for this type of natural language input? When I try to set only 10 minutues, or 1 hour separately it works, just the combination of these two fails. Thank you

Hi all, Since updating to iOS 18.4, I'm experiencing a regression with AppIntents triggered from Widgets. In my app, I use AppIntents inside a WidgetKit extension to control HomeKit devices. This setup was working perfectly up to iOS 18.3. However, starting with iOS 18.4, when the AppIntent is triggered from the widget and the main app is not running, the action fails with this error: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={ NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API. } Interestingly, the exact same AppIntent works fine if the app is still alive in the background — it seems like the failure only occurs when the intent is handled by the widget process. This looks like a behavior change or new restriction introduced in iOS 18.4. Has anyone experienced the same? Is there a new entitlement needed, or a recommended workaround? Thanks in advance!

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?