Thanks for chiming in here as well as on the other thread, Kevin! I appreciate the precision and promptness. I believe the only way to do this at the moment is to stream the incoming video like any other video feed while using a PlayAndRecord audio session to capture audio from the user. This is exactly what we switched to trying after I posted. Hats off to the AI bots for being able to help us prototype this approach quickly. Our preliminary results indicate that we will still be able to use some LCK call signaling with this approach, which is nice since we want users to have a native-feeling experience. Once we finalize our approach here I might take you up on submitting a feedback (although tbh I think the watchOS team is getting sick of us submitting demanding Feedbacks).

Same here. Latest upload got an internal server error warning from App Store Connect and builds are now approaching 24 hours of processing when normally it takes under 10 minutes. Of course, https://developer.apple.com/system-status shows all systems go, so no indication of whether Apple even sees the issue let alone when it will resolve.

Following up here. This is of course infernally annoying to test and debug: there is no response from Apple on this issue or documentation about VPP vs App Store differences. Furthermore we can only test our attempted changes by submitting a new build to the app store, waiting for approval, and then trying to deploy to our devices with VPP. What we can confirm is: – This is happening with other watch companion apps installed through VPP. HOWEVER a couple of watch companion apps I tested DID work. I would be happy to provide a list for comparison to Apple if it's helpful. – We tried adjusting a bunch of project settings related to optimization, dead code stripping, symbol stripping, etc. following a mix of online and AI-based guidance about potential objective-c metadata issues flagged from the crash logs. Our app is primarily based on Swift 5 but it does target some objective-c pods and frameworks which haven't changed in years. This didn't help. – Our app used the old WatchKit architecture with both an app target and an extension target. We tried rearchitecting our entire project to use the modern WatchKit approach to companion apps in the hope that it would change the way that VPP handles install and licensing. Unfortunately, after another round of app submission and testing, this also didn't work. – This regression persists in watchOS 26.3. As a reminder, this issue was introduced in watchOS 26.2. This leaves us in a pretty pathetic situation. There is no documentation, logging, or testing framework that we have been able to find to further figure out this problem. Apple won't answer us here or in feedback and DTS won't accept a ticket without a minuscule sample project file. Creating a sample project would be a huge hurdle, as it would involve creating a dummy app that can be submitted to the app store, and then iteratively guessing about potential issues, adding to the project, submitting to the store, and testing on VPP. Any feedback or help is appreciated.

Thanks for the information. I'll go ahead and submit a feedback.

Understood! I didn't know how much overlap there was between the two areas. I'll focus on the feedback for now, and will only update here with any final answers that could be helpful for posterity.

I must have expressed myself poorly then. My observation about the time zone was meant to raise a hypothesis for why the system delayed the alert for 5 hours and 4 minutes. But, it's clear that the alert was delayed. – The user reported an approximately 5 hour delay in the alert delivery from the observed event. – Our logs also reported the 5 hour delay. Recall that our logging output code is "Fall detected at (event.date) with status (event.resolution.rawValue) at (Date())". The resulting output prints the dates in UTC time, as shown in the fragments in my original post. The gap between the event.date value and the value returned by the Date() function (both printed in UTC) in this instance was 5 hours and 4 minutes. So to be crystal clear and to reiterate, we did see a 5 hour 4 minute delay for a user, and while the 4 minute component seems to be accounted for by this explanation, the 5 hour component remains a mystery.

I got followup from the submitted feedback, which I'm posting here: "Please know that our engineering team has determined that this issue behaves as intended based on the information provided. The API won't get notified until the first party flow and SOS resolution is complete. For example if an emergency call is placed, the API wont get notified until the call ends and emergency contacts have been notified (if setup). This could explain the 3-5 minute delay observed by the developer between the time of the fall and the API getting notified." While the feedback response explains the 3-5 minute delay, it does not explain the 5 hour delay we witnessed. I answered the feedback to emphasize that the core issue remains unaddressed, but the FB is already marked as "closed" so I don't expect any further action. Is there any way to get further guidance here?

I should add that the user was located in Central time which is -5 hours from UTC. Since the observed delay was 5 hours and 4 minutes, I wonder if there is an issue with time zones and message delivery to our app. If you remove the 5 hours component we end up with a 4-minute delay which is still not ideal but in line with what we've seen on those other events. Also, the watch was running watchOS 10.2. To be clear, though, the vast majority of our users are located in the continental U.S. and we haven’t seen similar multi-hour delays from their devices. I have updated the feedback with this information as well.

Thank YOU for being responsive to all of this! The team can feel free to send us either flowers or a lump of coal, depending on how they feel about getting these :) FB13788575 submitted.

Reporting back from the feedback so others can note, this appears to be fixed for an upcoming watchOS release. Thanks to the Watch system team to being attentive to this issue.

Confirmed, this appears to be fixed now. I appreciate the follow-up and follow-through. Definitely a step in the right direction for developer relations.

A note to anybody still following this: as of 2 days ago, Apple is now signing 17.3.1 again, making downgrading iPhones possible. This is a partially effective temporary fix for this issue. Unfortunately, I don't know if the IPSW for 10.3.1 is available for download and being signed, or how to go about applying it to a watch. 15 minutes of Googling wasn't helpful. Anybody have ideas?

Confirmed that this is still an issue on iOS 17.4.1, released today.

Thanks again for the quick followup. Feedback FB13692821 submitted with a sysdiagnose attached.

Thank you!!