Our watchOS app uses CMFallDetectionManager (with the proper entitlement) to help alert our users and their caregivers when a fall occurs. We have had a simple implementation in our app for a couple of years now and it seems to work fine. Recently, we received a report of delayed fall alerts and have traced back the root cause to a failure from the system to call func fallDetectionManager(_ fallDetectionManager: CMFallDetectionManager, didDetect event: CMFallDetectionEvent, completionHandler handler: @escaping () -> Void) promptly when a fall occurs. Our implementation of this method begins with the following logging statement: "Fall detected at \(event.date) with status \(event.resolution.rawValue) at \(Date())" When we check our logs, we see a number of events that occur as expected, for example: Fall detected at DATE_AND_HOURS:42:09 +0000 with status 1 at DATE_AND_HOURS:42:51 +0000 However, many events show a period of several minutes from fall detection to a report: Fall detected at DATE_AND_HOURS:28:09 +0000 with status 0 at DATE_AND_HOURS:32:42 +0000 or Fall detected at DATE_AND_HOURS:44:26 +0000 with status 1 at DATE_AND_HOURS:48:14 +0000 And in the instance from our customer, we had a fall detected that evidently wasn't reported for 5 hours and 4 minutes (I'm not sharing exact timestamps publicly to maintain user privacy). We are aware of the documentation regarding the delegate and have programmed it appropriately not to receive duplicate events: Additionally, each time the user launches your app, the system checks to see if a fall event has occurred during the recent past. If one has occurred, it calls this method. Note that your app may receive the same event multiple times, for example, if the app crashes and relaunches. Always check the event’s date property to determine whether your app has already received the event. The system guarantees that different fall events have different date values. Moreover, our logger persists logs when there is no network access, and the delegate callback also requests a network post to our servers that, again, is preserved in a background queue until connectivity is restored if it's not available. Our app's other updates (watchOS complication, etc.) from this user's Watch also show that our app was running in the background and communicating with our servers during that time. We have very high confidence that the watch and our app did not miss any more timely calls to that delegate method. While this one five-hour delay was an exceptionally bad occurrence, we also find the other delays of several minutes to be concerning, considering the time-sensitive nature of falls. Does Apple or do any developers have any insights about what's going on and what expectations we should be setting for our users?

XCode 15.3, watchOS 10.4 SDK Our health-related app is exploring adding an additional feature that would make use of extended runtime sessions to guide users through an activity. A user starts a session by tapping a button on the watchOS app's interface. If a session is already running, pressing that button should cause the current session to invalidate, and a new session should be created so we can start again from the beginning. TLDR: Running new sessions works as expected on the simulator but not on a real device. Why? We currently have a barebones implementation that includes logging in the extended runtime session delegate functions, on the button push, and when the new session is about to start. Here's what our logging output for the simulator looks like when we try to invalidate the current session and run another one: Invalidating extended session Optional("<WKExtendedRuntimeSession: 0x60000262d7a0> state=2, sessionID=4894EB1D-96F7-4921-8263-378E304E719F, expirationDate=2024-03-20 13:01:10 +0000") at 12:01:21 PM Extended runtime session <WKExtendedRuntimeSession: 0x60000262d7a0> state=3, sessionID=4894EB1D-96F7-4921-8263-378E304E719F, expirationDate=2024-03-20 13:01:10 +0000 invalidated for reason WKExtendedRuntimeSessionInvalidationReason(rawValue: 0) with error nil at 12:01:21 PM Requesting new extended session in application state 0 at 12:01:22 PM Starting new extended session Optional("<WKExtendedRuntimeSession: 0x600002644540> state=0, sessionID=B34ECCFF-A0DA-45C1-9FD1-FD0F335FBE02, expirationDate=(null)") in application state 0 at 12:01:23 PM Did start extended session <WKExtendedRuntimeSession: 0x600002644540> state=2, sessionID=B34ECCFF-A0DA-45C1-9FD1-FD0F335FBE02, expirationDate=2024-03-20 13:01:23 +0000 at 12:01:23 PM As you can see, we successfully invalidate a running session, a button press requests a new one, and then we create and start a new runtime session instance which ends in the running (2) state. We can repeat this over and over without issue. The exact same code running on an actual device produces this: Invalidating extended session Optional(\"<WKExtendedRuntimeSession: 0x15db5750> state=2, sessionID=889FE2E8-0FDA-4826-9094-4D48094FEBED, expirationDate=2024-03-20 12:53:55 +0000\") at 11:56:04AM Extended runtime session <WKExtendedRuntimeSession: 0x15db5750> state=3, sessionID=889FE2E8-0FDA-4826-9094-4D48094FEBED, expirationDate=2024-03-20 12:53:55 +0000 invalidated for reason WKExtendedRuntimeSessionInvalidationReason(rawValue: 0) with error nil at 11:56:04AM Requesting new extended session in application state 0 at 11:56:05AM Starting new extended session Optional(\"<WKExtendedRuntimeSession: 0x15e0aba0> state=0, sessionID=D5020337-D20B-48BE-B2EE-EE44BE580AEC, expirationDate=(null)\") in application state 0 at 11:56:06AM Extended runtime session <WKExtendedRuntimeSession: 0x15e0aba0> state=3, sessionID=D5020337-D20B-48BE-B2EE-EE44BE580AEC, expirationDate=(null) invalidated for reason WKExtendedRuntimeSessionInvalidationReason(rawValue: 1) with error nil at 11:56:06AM The difference is in the last line: starting the session was unsuccessful and it was immediately invalidated, with the reason WKExtendedRuntimeSessionInvalidationReason(rawValue: 1) which maps to the enum sessionInProgress. This is surprising, since we just invalidated and dereferenced the old runtime session. What else can we do to tear down this session? In fact, no other extended runtime sessions can be created and started successfully until the device is rebooted. One note is that on the simulator we do get the following warning right after invalidating the running session: -[WKExtendedRuntimeSession _invalidateWithError:]_block_invoke_2:527: Got error Error Domain=com.apple.CarouselServices.SessionErrorDomain Code=3 "Session not running <CSLSession: 0x600003b4eca0; pid: 8833; dismissed: NO; ended: YES; duration: 3600.0; autoEnd: NO; launchable: NO; mutuallyExclusive: YES; managed: YES; persisted: NO; requiresFGActiveInitiation: YES; lastForeground: 2024-03-20 12:01:21 +0000> |CSLSSession = { | sessionID: 4894EB1D-96F7-4921-8263-378E304E719F; bundleID: com.bundle; type: "physical therapy"; running: NO; paused: NO; expirationDate: 2024-03-20 13:01:10 +0000; supportsAOT: NO; lastStartWasScheduled: NO; remote: NO; |}" UserInfo={NSLocalizedDescription=Session not running <CSLSession: 0x600003b4eca0; pid: 8833; dismissed: NO; ended: YES; duration: 3600.0; autoEnd: NO; launchable: NO; mutuallyExclusive: YES; managed: YES; persisted: NO; requiresFGActiveInitiation: YES; lastForeground: 2024-03-20 12:01:21 +0000> |CSLSSession = { | sessionID: 4894EB1D-96F7-4921-8263-378E304E719F; bundleID: com.bundle; type: "physical therapy"; running: NO; paused: NO; expirationDate: 2024-03-20 13:01:10 +0000; supportsAOT: NO; lastStartWasScheduled: NO; remote: NO; |}} This appears to be thrown by some part of Carousel, for which no public documentation exists, and it clearly doesn't disrupt the expected behavior on the simulator. I don't know if this is being thrown on the device, since our logging wouldn't be able to pick it up. Please let me know if we are approaching this incorrectly or if there are any known solutions to this issue.

Our app is pushed to supervised iPhones through our MDM. We have a watchOS companion app that we install to paired Apple Watches as well. Our watches are NOT enrolled in the MDM using the new watchOS 10 MDM features, and are just paired normally to the supervised phones. Historically (the past 2 years), the watchOS companion app has been installed automatically after our iOS app has been pushed by our MDM (through VPP) and the Watch has been paired. NEW IN iOS 17.4/watchOS 10.4, the watchOS companion app is NOT installed automatically and when we press “Install” in the Watch app on the iPhone, we see a spinner for about 1 second and then a silent failure, with the button reverting back to “Install”. This is occurring with other apps purchased through VPP. We purchased the CityMapper app through VPP, assigned it to a supervised iPhone, and attempted to install CityMapper's watchOS companion app and got the same failed result. This is NOT occurring on a clean & reset supervised iPhone and its paired watch running iOS 17.3.1 / watchOS 10.3. On a personal unsupervised device running iOS 17.4/watchOS 10.4 with a copy of our app purchased through the App Store, installing the watchOS companion app is not an issue. I filed radar FB13687404 but in 10 years of developing for iOS, I have never ever ever heard of Apple responding to one of those. Posting here in the hope that other users/developers can share their issues or solutions.

I'm trying to find out if the new "Time in Daylight" feature in the Health app has a corresponding HealthKit data type that our app will be able to query in the release versions of iOS 17 / watchOS 10. So far, I cannot find any reference such a type in beta documentation. Can someone confirm if this will be available? Please note that this is not an inquiry about data collection for "Time in Daylight." We are successfully seeing samples collected on our Watch/iPhone pair running the latest betas.