Oops, that was an earlier version of the AskyMyAppSnippetView, I had added a prompt display: struct AskMyAppSnippetView: View {     var question: String     init(_ prompt: String) {         question = prompt     }     var body: some View {         Text("Your question was: \(question)")     } } I don't think it really matters, since that didn't change the way the view displayed at the intent result but this is the corrected version thats compatible with the intent code above.

Just to follow up on this in case anyone else has similar questions. I think I have found the root of my issue and it was indeed user error. It turns out the device we were using to test had the "Always Show Siri Captions" and "Always Show Speech" options enabled in /Settings /Siri&Search /SiriResponses Resetting those options back to the defaults gets the App Intents Views to show up without competing for screen space. Since I cant find a way to detect in code whether the user has those options enabled, we've added settings in our app to toggle the App Intent views. This is what it looks like on an iPhone 8 which seems to be the smallest screen for an iOS 16 device.

Here is a quick video showing the behavior: https://youtube.com/shorts/v2j51T7Kdxw In the clip, the user starts the ask intent and is prompted for "What would you like to ask?" They say "What's the most recent album from Sting" and it prompts them again. Then they say "What's the last album from Tame Impala" and it prompts them again. Finally they say "Is this thing on" which the system accepts and hands off to our code as the prompt parameter.

I tried to request Apple Developer Technical Support with at Technical Support Incident, but they responded saying I should create an entry in the Feedback Assistant. Which I have done: https://feedbackassistant.apple.com/feedback/12185568 I've also gone back through the documentation and WWDC videos but nothing I've tried (like building a struct to encapsulate the String as an entity) has changed the behavior. From the tone of the TDI response I'm not really filled with optimism that the issue in the feedback system will bubble up into the attention of anyone working on Siri/AppIntents. But I suppose it could happen?

Im working with a potentially long running perform() function as well. In my case there is a streaming data operation that gets triggered when the AppIntent starts. It may be quick, or it may take quite some time. What I have found is that we can extend the operation of the perform() method by periodically updating the user with the data that has been received so far and asking them if they want to continue. dialogRespone = partialDataRecived + " --- There is more. Would you like to continue?" try await requestConfirmation(result: .result(dialog: "\(dialogResponse)")) I have that in a loop that waits a conservative 15 seconds, which in practice seems to be below the time threshold we have seen Siri/Shortcuts timeout the perform(). Its also monitoring a flag that indicates when the data is completely received and proceeds when either the timer or data is complete.

Users have provided additional examples of filtering by requestValueDialog. I suspect it all boils down to the same thing. If the user says a phrase such as "Do you think Swift is better than Java" they see that text in the display if they have Settings/ Siri & Search/ Siri Responses/ Always Show Speech enabled. So it's clear that the system recognized the entire phrase. But the String value that gets provided to the AppIntent is "Swift is better than Java" without the "Do you think" at the start. requestValueDialog is accepting the user's spoken input in cases like that but it is filtering the String before it gets to the AppIntent. Our users would very much like to be able to get the prompt to the AppIntent as they have spoken it, without being filtered.