@DTS Engineer Thanks for checking. One data point that may be useful: on our side, the crashes only appeared after we started building with Xcode 27 (watchOS 27 SDK). Builds made with Xcode 26 did not show this signature on watchOS 26.2–26.3, even during the period when most of our users were on those releases. We'll advise affected users to update to watchOS 26.4 or later.

@DTS Engineer Thanks for following up. Here is what we know, sticking to what the data shows. Reproducibility We have not been able to reproduce this ourselves. None of our own Apple Watch devices are running watchOS 26.2 or 26.3, so we haven't been able to test developer, TestFlight, or App Store builds on an affected OS version. Every report we have comes from the crash reports Xcode Organizer collects. Distribution channel None of the reports contain a Beta Identifier field. The reports don't contain a distributor field either, so we can't tell whether any of the affected installs came through VPP/MDM. OS versions All of the crash reports with these signatures come from watchOS 26.2 (23S303), 26.2.1 (23S314) and 26.3 (23S620). We have not seen either signature on any other watchOS version, including watchOS 27. We can only speak to what the crash reports show, though, so we can't say for sure that later versions are unaffected. Other details from the reports: Only devices running the arm64 slice are affected. Nearly all of the crashes happen during background / non-UI launches. The crashes keep recurring on the same device. One Watch7,5 has crashed every day since October 12. Build environment For the affected builds we have archives from Xcode Cloud: Xcode 27.0 (27A266a) and Xcode 27.1 (27A9275) watchOS 27.0 SDK (24R360) Deployment target watchOS 10.0 Default linker, with no custom linker flags Build machines on macOS 26A428, 26A434 and 26B5091g The archives and dSYMs for these builds are attached to FB25270892, along with the crash reports. Happy to provide anything else that would help.

This issue also exists in iOS 27 beta.

Can anyone answer this?

Debuging Apps Icon not shown, TestFlight and App Store Apps will show.

@DTS Engineer Thank you for your reply. What I mean is that if I only add SharedTypes.swift to the widget target and remove it from the watchOS target, AppEnum will correctly display internationalized text. However, I cannot use this workaround because while the project would compile normally, clicking the control widget would fail to navigate correctly to the watchOS app since the main target lacks the corresponding code. Additionally, the iPhone Watch App functions correctly. When configuring watch faces in the Watch App, AppEnum displays internationalized text properly. This issue only occurs on the Apple Watch physic devices.

@andrewfromCanada @bernyz It seems that restarting the iPhone can temporarily fix the issue, but it may come back after a while. A permanent solution hasn’t been found yet.

@bernyz Hello，any update for this issue?

resolved

App Group is device level, iPhone and Apple Watch are two devices. You can consider WCSession.

It seems that this issue has been fixed in the new beta version. @haozes

@DTS Engineer hi, Ziqiao I have a similar issue FB17024450, but there has been no progress. Could you take a look at it as well?

I have the same problem, I am monitoring HRV data using HKOberserQuery + enableBackgroundDelivery with HKUpdateFrequency.hourly . in HKOberserQuery i only gets the latest one HRV sample. I make sure HKObserverQueryCompletionHandler is called correctly, but I see a lot of CSLHandleBackgroundHealthKitQueryAction crash log on the watch logs, and I'm seeing the same logs on other apps too!

@DTS Engineer I have created a Feedback FB17024450 report and included more details about the environment along with additional video recordings. Hope this helps.

@DTS Engineer Hi, I'm having an issue with HealthKit background delivery on watchOS 11.3.1, I'm using HKObserverQuery and I'm experiencing CSLHandleBackgroundHealthKitQueryAction watchdog transgression crash. I confirm that I have called HKObserverQueryCompletionHandler correctly and in time. Is there any special requirement for the code to call HKObserverQueryCompletionHandler? For example, does it have to be in the main thread?