Thank you @Engineer! Do all the properties on my IndexedEntity also exist as properties on the CSSearchableItem that backs it automatically? Or is there an additional step there? Update – I found more details about this here: https://developer.apple.com/documentation/appintents/making-app-entities-available-in-spotlight

I ran into this last year. If you're struggling to conform your existing App Intents, I believe you can throw this flag on the duplicate ones to keep them hidden from Shortcuts. https://developer.apple.com/documentation/appintents/assistantschemaintent/isassistantonly

@Frameworks Engineer thank you so much!! I figured there had to be a way

Thanks for your guidance and feedback on this, I really appreciate it! The tail chasing ensued around trying to smooth out edge cases (i.e. a truncation on iPhone SE), but fix one break another. So I left it alone at generally better than where it started. FB23039158

Thank you. FB23038760

Thank you, I will review that session. Yes, this is on iOS. In my app, the SwiftUI navigationTitle was getting truncated at larger sizes. My solve was to shorten it, and add in a subtitle at largest sizes to still convey meaning. private func navigationTitleAbridged(for title: String) -> String { if dynamicTypeSize >= .accessibility2 { return fullSqueeze(title) } if dynamicTypeSize >= .xxxLarge { return halfSqueeze(title) } return title }

@Frameworks Engineer thanks. Is Apple Intelligence powered Voice Control generating its own set of input labels for all the elements in our view hierarchy? And if so, are these getting merged with the input labels we provide?

Thank you! FB23037860

Fixed in iOS 26.4 beta 1!

Thanks @DTS Engineer – I've filed a fresh feedback specific to the flexible matching issue. FB17433375

Hi @DTS Engineer – I just received a response to FB16432161 that the App Shortcuts Preview tool has been fixed. I tested the Trails Sample App again in the latest Xcode, Version 16.3 (16E140). Entering an exact utterance from the App Shortcut's phrases array does now match to the expected App Intent, so we're making progress! However, using any variation from these predefined phrases still results in No Matching Intent. In the build settings for this project, Enable App Shortcuts Flexible Matching is set to Yes. (build settings reference) With this build setting enabled, I would expect both of these utterances to match successfully to the same intent. AppShortcut( intent: OpenFavorites(), phrases: [ "Open Favorites in \(.applicationName)", "Show my favorite \(.applicationName)" ], shortTitle: "Open Favorites", systemImageName: "star.circle" ) From Spotlight your app with App Shortcuts (WWDC23): In iOS 17, we're giving you the ability to speak more naturally to trigger your App Shortcuts. This takes advantage of on-device machine learning to allow phrases similar to the ones you've provided in your App Shortcut to also just work. This is powered by a new Semantic Similarity Index. With this new flexible matching feature, people can use more natural ways of invoking app shortcuts, and you don't have to provide every possible different phrasing.

Hey @mvc2522 – I've been trying to better understand how transferable works with App Intents too. Here's something I discovered. In the second action block (i.e. send email), tap on the AppEntity instance that's been passed in from the first action block (your app's AppIntent action). A sheet pops up, with some configuration options related to the type. The Type selector likely defaults to your entity type. And below this, there is a parameter selector that once again lists your type (selected by default) followed by all the @Parameter from your app entity. If you tap the parameter containing your string and re-run the shortcut, it should get passed into the email. I'm not sure the purpose of entity type the default - in my testing I had similar behavior to you - a new email window opening up that was blank. Alternatively, based on the transferable conformance you added, try changing the Type selector from your entity's type to Text and re-run the shortcut. This should work too. I posted about something similar in this thread but haven't gotten any guidance yet. Let me know what you discover!

Hi Ed @DTS Engineer, I'm encountering the same issue. Even in the Trails Sample App from WWDC. If you build and run this project, the App Shortcuts are recognized in an iOS simulator and on a device. But in Xcode's App Shortcuts Preview tool, every utterance seems to return No Matching Intent, even when entering verbatim ones defined in the App Shortcut's phrases array. FB16432161

Thanks for boosting this @vincent123. I found some new guidance on this in the App Intent docs. via Integrating actions with Siri and Apple Intelligence: Your existing app intents might overlap with functionality that assistant schemas provide. If you can make an existing app intent conform to a schema without making changes to parameters that the intent uses, proceed with adding schema conformance. However, changing existing app intent implementations or removing app intents can directly impact people because their custom shortcuts may no longer work. To not break people’s existing workflows, create a new app intent in addition to an existing app intent. As a result, both intents appear in the Shortcuts app as actions. To avoid them appearing as duplicates, mark your new app intent as available to Apple Intelligence only by setting isAssistantOnly to true. Similarly, you can set isAssistantOnly to true for any applicable app entities and app enums that conform to an assistant schema. After some time, you can remove the isAssistantOnly code and remove your old app intent. So there's a short term solution, but creating near duplicate code as needed for app intents, entities and enums feels a little kludgy. Ideally we could write one schema conforming app intent with custom display properties (title, description, etc). Hopefully someone from  will chime in as this will likely come up for other developers adopting various other schemas.

Thanks for your response @Frameworks Engineer! I explored the .accessibilityHint modifier but in this instance that made the VoiceOver output more verbose. Feedback ID: FB16354752