I have an app that's capable of playing podcasts via Siri requests, e.g. "Hey Siri, play [Podcast Name]". I’m using INPlayMediaIntentHandling, that is, the SiriKit domain intents, as opposed to the newer AppIntents framework for its ability to select my app for audio playback without the need to specify the name of the app in the user's request to Siri. This works great overall for the many podcasts I’ve tested the app with, with the exception of one. There's a podcast called "The Headlines", and I when I test the app with the request "Hey Siri, play The Headlines", my app is never selected. Instead, Apple Podcasts begins playback of a show called "NPR News Now". Oddly, if the Apple Podcasts app is deleted, my app will still not be selected by the system, and instead, Siri responds with "I don’t see an app for that. You’ll need to download one" with a button to open the App Store. Additionally, if I do add the app name to the request using this style of intent, Siri responds with "[App Name] hasn’t added support for that with Siri." However, I’d still like to accomplish this without requiring the app name in the Siri request. There's nothing complex in my setup: The target declares one supported intent, INPlayMediaIntent, with "Podcasts" selected as a supported media category. The Siri entitlement is enabled. My INSiriAuthorizationStatus is .authorized. My intent handler is specified in my AppDelegate as follows: func application(_ application: UIApplication, handlerFor intent: INIntent) -> Any? { return IntentHandler.shared } My intent handler is simple: final class IntentHandler: NSObject, INPlayMediaIntentHandling { static let shared = IntentHandler() func handle(intent: INPlayMediaIntent) async -> INPlayMediaIntentResponse { print("IntentHandler: processing intent: \(intent)") /** code to start playback based on information found in `intent` **/ } When requesting Siri to "Play The Headlines", my handler code is not called at all. For all other supported shows, the print statement executes, and playback begins as expected. Is there any way I can get my app to be selected instead of Apple Podcasts for this request?

I'm returning the following result in one of my AppIntents: return .result(value: "Done!", dialog: IntentDialog("Speed limit \(speedLimit)")) With iOS 18.0.1 it was nicely confirming the user the result of their command by saying e.g. "Speed limit 60" and showing it on top of the screen. With iOS 18.1, it only shows/says "That's done" or "Done" at the bottom of the screen. Am I missing something that changed in the AppIntents API since iOS 18.1?

Ive been having issues with downloading my apple intelligence for a while now.

VoiceOver does not support the plist property CFBundleSpokenName. This is wrong and should be fixed. Ultimately the issue I am dealing with is that our app name is UWCU, and instead of VoiceOver pronouncing each letter, it tries to read this as a word and horribly butchers our organization's/app's name. Alternatives such as using U.W.C.U. and U W C U are not acceptable. @Apple, I know you're first response is going to be "no, it is working perfectly," but quite frankly you are wrong. I know you feel strongly about this, given your response in posts like this: https://forums.developer.apple.com/forums/thread/734545?answerId=760084022 HOWEVER, with iOS 18, your argument for "VoiceOver should read what's on the screen" doesn't hold water anymore. With iOS 18, you Apple have added a new feature that lets users customize their home screens and completely remove the name of apps. Here's your own guide: https://support.apple.com/guide/iphone/customize-apps-and-widgets-on-the-home-screen-iph385473442/ios Quoted from your guide: Make the icons bigger: Tap Large. (In large size, the names of the apps disappear.) With large icons + VoiceOver turned on, VoiceOver still reads the app name even though it has disappeared from the screen. So, your own argument "VoiceOver should read the text as it appears on the screen" is invalid, because there is NO text on the screen. If you can't tell, I'm pretty peeved about all this. There's a reason why screen readers support aria attributes to help deliver the right accessible experience. It's a simple ask for VoiceOver to do the same thing.