My apologies, I realized I was accidentally testing on an iOS 27 device without Apple Intelligence, so that explains why INAddTasksIntent was being used. I just tested on a device with the Apple Intelligence beta and confirmed the App Intent schema is being used. I'm still not sure why INAddTasksIntent sometimes worked without needing to specify the app name though.

I'm having the exact same issue. Copying the symbols from my watch always stalls out after a few percent. I've tried rebooting all devices many times, clearing various caches, removing and re-adding devices in Xcode and nothing has fixed it. The Xcode Downloads window is also showing this error: Failed with HTTP status 403: forbidden Domain: DataGatheringNSURLSessionDelegate Code: 1 User Info: { DVTErrorCreationDateKey = "2026-06-10 19:29:37 +0000"; } -- Failed with HTTP status 403: forbidden Domain: DataGatheringNSURLSessionDelegate Code: 1 -- System Information macOS Version 26.5.1 (Build 25F80) Xcode 26.5 (24943) (Build 17F42) Timestamp: 2026-06-10T12:29:37-07:00 I've tried signing out of my Apple Account in Xcode and signing back in, but that has not fixed it.

Thanks to a tip from the developers of another app, we found that changing the deployment target of the watch app from watchOS 7 to watchOS 8, allowed the app to be installed on devices running watchOS 8. Since all devices that supported watchOS 7 also support watchOS 8, this was an acceptable workaround and we have now released an app update with this change.

I was just now able to submit my app for App Store review. I use the same build I uploaded last night (built with Xcode 15.0.1) that was previously saying it couldn't be submitted because it was built with a beta version of Xcode.

I'm also seeing the issue where the Watch app on the phone seems to be showing both the ClockKit and WidgetKit complication, at least in my local development builds. I haven't tried with a TestFlight build yet (which for our app uses a different bundle identifier). This is on watchOS 10.0.1. Did Apple ever respond to your feedback or did you ever figure out how to fix that issue?

This appears to be a Siri Shortcuts bug with String parameters that accept multiple values, as I was able to reproduce the issue by modifying the toppings parameter in the SoupChef sample app to be a String parameter and unchecking "Options are provided dynamically". I've filed this issue as FB12150054, as it still occurs on iOS 16.5 beta 3.

We haven't seen any instances of this crash in our app on iOS 15.5, so I think it may have been finally been fixed in that release of iOS.

Just to follow up for others that are experiencing this issue: Activating our shortcut by voice is still not working with watchOS 8.2. Activating our shortcut from the Shortcuts app on watchOS 8 works fine and activating it by voice still works on watchOS 7. Unfortunately, I haven't received any followup from Apple, either here on the forums or in FB9541952.

We're having exactly same issue with the Shortcut for our app on watchOS 8. Activating our shortcut from the Shorcuts app on watchOS 8 works fine and activating it by voice still works on watchOS 7. I originally reported the issue here and filed FB9541952 on August 20 as instructed by @edford. Unfortunately, I haven't received any follow up in that thread or in the bug report and the issue is still occurring in watchOS 8.2. I haven't tested the watchOS 8.3 beta yet myself, but another developer in the other thread says they're seeing the issue with their shortcut on watchOS 8.3 beta.

updateApplicationContext() is still not working for me in the simulator with Xcode 13 RC, which is preventing us from being able to see how our app looks on the Series 7 watch. @sal_from_new_york, did you ever receive any updates from Apple after they said they were able to duplicate the issue?