Dear Apple Developer Relations & Technical Support Team, I am an iOS developer based in Mainland China. We are currently developing an on-device AI-powered translation assistant for reading original English books, targeted at a global market. We have upgraded our development setup to Xcode 27.3 Beta and iOS 27.3 Beta. When attempting to invoke the FoundationModels API on an iPhone 15 Pro (Mainland China SKU: MTQA3CH/A), the system fails to initialize and returns the following diagnostics: Availability: unavailable(FoundationModels.SystemLanguageModel.Availability.UnavailableReason.deviceNotEligible) Raw Error: FoundationModels.SystemLanguageModel.Error Code 0 ("The assets required for the session are unavailable.") Language Support: supportsLocale(zh-Hans): true Considering that the iPhone 15 Pro hardware (A17 Pro chip) meets the necessary performance criteria and the framework reports that Simplified Chinese is supported, we would like to consult with you on the following key questions: Current Availability & Expected Release Timeline: Is the FoundationModels API currently completely disabled for Mainland China hardware models (CH/A)? If it is currently restricted, when is it expected to become available for developers and users in Mainland China? If there is an established roadmap or target release schedule, could you please share a specific timeline so we can plan our product roadmap and release cadence accordingly? Model Strategy for Mainland China: In Mainland China, will Apple eventually enable the standard FoundationModels API seamlessly under the hood, or will a different, locally-partnered/compliant AI model be required to satisfy regional regulations? Should developers expect the existing FoundationModels API to unlock in the future, or should we design a separate, alternative AI backend specifically for the Mainland China market? Testing Solutions for Global App Deployment: Since our application is intended for global release outside Mainland China, what is the official recommended workflow for China-based developers using CH/A devices to test and debug FoundationModels features during this beta phase (e.g., using Xcode Simulator, overseas non-CH/A hardware, or a developer sandbox/allowlist)? Environment & Diagnostic Details: Developer Team ID: NVQ5CF8F2X Xcode Version: Version 27.3 beta (Build: 27C5020n) iOS Version: Version 27.3 (Build: 24C5037i) Test Device: iPhone 15 Pro (Hardware: iPhone16,1, Model: MTQA3CH/A) Diagnostic State: isAvailable = false, deviceNotEligible Error: Domain=FoundationModels.SystemLanguageModel.Error, Code=0, "The assets required for the session are unavailable." Thank you very much for your time and assistance. We look forward to hearing your insights. Sincerely, Kai

1/ Issue Summary In our application, we use HKObserverQuery together with:HKHealthStore.enableBackgroundDelivery(for:frequency: .immediate) to enable HealthKit Background Delivery, allowing the system to wake our App Extension in the background to process health data updates. Under the same app build, identical HealthKit permission configuration, and the same watchOS version, we have observed significant differences in background delivery frequency across different devices. Specifically, on certain devices (e.g. Apple Watch Series 10, watchOS 26.2.1), the background delivery frequency is significantly reduced, behaving as if it is capped at approximately once per hour. On other control devices, under the same configuration, background delivery is triggered much more frequently and consistently, at approximately every 8–16 minutes. This behavior is consistently reproducible on the affected devices. **We would like to understand whether there are any officially recommended implementation patterns, best practices, or device-/system-level considerations when using HKObserverQuery and Background Delivery, in order to achieve more consistent and predictable background update behavior across different devices running the same system version. ** 2/ Detailed Device Comparison We conducted internal comparison testing across multiple devices with the following results: Device A (Affected / Abnormal) Model: Apple Watch Series 10 (46mm) OS: watchOS 26.2.1 Serial (partial): C*HY Background Delivery Frequency: ~ once every 60 minutes (significantly lower than expected) Device B (Normal) Model: Apple Watch Series 10 (42mm) OS: watchOS 26.2.1 Serial (partial): G*4R Background Delivery Frequency: ~ every 8–16 minutes Device C (Normal) Model: Apple Watch Series 8 (41mm) OS: watchOS 26.3 Serial (partial): C*J6 Background Delivery Frequency: ~ every 8–16 minutes Device D (Normal) Model: Apple Watch Series 5 (41mm) OS: watchOS 10.6.1 Serial (partial): G*TQ Background Delivery Frequency: ~ every 8–16 minutes All devices share the following conditions: HealthKit permissions: Full read/write permissions granted Background App Refresh: Enabled System state: Low Power Mode, Do Not Disturb, and all Focus modes disabled App build: Identical app build installed on all devices HealthKit configuration: Same data types and same frequency parameter used in enableBackgroundDelivery Implementation: Identical HKObserverQuery implementation logic 3/ Abnormal Behavior Observed On the affected device(s), we observe that: HealthKit background delivery appears to be heavily coalesced or throttled The system rarely attempts to wake the App Extension Behavior is clearly inconsistent with other devices using the same configuration The behavior does not match our expectations for HealthKit Background Delivery with .immediate frequency 4/ Troubleshooting Already Performed We have already attempted the following on the affected device(s): Restarted both Apple Watch and paired iPhone Re-paired the Apple Watch Uninstalled and reinstalled the app Revoked and re-granted HealthKit permissions Confirmed that Low Power Mode, Do Not Disturb, and Focus modes are all disabled The issue remains consistently reproducible. 5/ Assistance Requested We would appreciate guidance on: Whether there are any officially recommended implementation patterns, tuning options, or best practices for using HKObserverQuery and HealthKit Background Delivery Whether there are any known device-level or system-level factors that may cause significantly different background delivery behavior on different devices running the same watchOS version How to best achieve consistent and predictable background update delivery behavior across devices for apps that rely on this mechanism 6/ Additional Information We can provide sysdiagnose logs from both affected and unaffected devices for comparison We can also provide a minimal reproducible sample project if needed

We are developing a health app that relies on HKObserverQuery and BackgroundDelivery to monitor Heart Rate data. On watchOS 10.6 and 11.6 , these data updates are typically delivered reliably every 8–12 minutes, occasionally exceeding 12 minutes, but generally not longer than 15 minutes. This frequency has been sufficient for the real-time data requirements of our app. However, after adapting our app to watchOS 26, we noticed that HKObserverQuery triggers much less frequently, with longer and very inconsistent intervals. This issue has had a major impact on our product: data collection for essential features is unreliable, resulting in a greatly diminished user experience on watchOS 26 and making the app essentially useless from the user’s perspective. Observed Behavior: HKObserverQuery and BackgroundDelivery are extremely unstable, with trigger intervals frequently exceeding 15 minutes, and sometimes even 20 minutes. When the user is sedentary, intervals become even longer; there are cases where no heart rate or active energy updates are delivered for 30 minutes, or even over 1 hour. Request for Support and Guidance: Have there been any changes to the HKObserverQuery background delivery mechanism on watchOS 26, specifically for Heart Rate and Active Energy data? If these changes are intentional system optimizations, could you provide guidance or recommended practices to ensure our app can reliably retrieve updates and maintain a smooth experience for users? Thank you for your support.

Hello, I’m building a health-related app for both watchOS and iOS, which needs to monitor certain health data (e.g., heart rate, active energy). Before updating to watchOS 26, the queries worked reliably without any issues. However, after adapting to watchOS 26, some users have reported that health data updates stop being delivered. What I’ve observed: HKObserverQuery with enableBackgroundDelivery is set up normally. On WatchOS 26, the query sometimes stops delivering updates entirely after a certain point, and once an update is missed, it may stop delivering further updates completely. Restarting the Apple Watch temporarily restores delivery, but the problem reoccurs after some time. This makes background health data monitoring unreliable for my app. Here’s a simplified version of the code we are using: guard let heartType = HKObjectType.quantityType(forIdentifier: .heartRate) else { return } let query = HKObserverQuery(sampleType: heartType, predicate: nil) { query, completionHandler, error in if let error = error { logEvent("Observer error: \(error.localizedDescription)") return } logEvent("Heart rate changed") MyNotificationManager.shared.sendNotification() // Send a local notification completionHandler() } healthStore.execute(query) healthStore.enableBackgroundDelivery(for: heartType, frequency: .hourly) { success, error in if success { logEvent("Background heart rate delivery enabled") } else { logEvent("Failed to enable background heart rate delivery: \(error?.localizedDescription ?? "Unknown error")") } } Could you please clarify: Is this a known issue with HKObserverQuery and enableBackgroundDelivery on watchOS 26? Are there any recommended workarounds or best practices to ensure continuous background delivery of health data? Thank you in advance for your help.