Overview

We are developing devices that communicate with iOS using Bluetooth LE. Since there is a limit to the number of bonding information that can be stored on the device side, the device deletes the bonding information when the limit is reached. Then, there is an operational situation where the bonding information is deleted on the device side and remains on the iOS side. When this situation occurs, an Encryption Failure occurs at the time of reconnection, and the connection is immediately disconnected from iOS. Since there is no API to delete the remaining bonding information on the iOS side, it is not convenient for the user to delete the bonding information on the iOS setting screen. I would like to improve the usability for re-pairing. With the bonding information of the device remaining on the iOS side, is it possible for iOS to prompt "re-pairing" by taking the following action from the device? (It is possible to change the device side) ・Change the Bluetooth parameter setting value of the device side ・Change the response value to iOS Also, is it possible for iOS to "re-pair" with CoreBluetooth API when the bonding information of the device remains in iOS side? Also, in case of HOGP, when the bonding information of the device remains in iOS side, iOS always tries to connect and fails repeatedly when the device sends advertisement. When this situation occurs, is it possible to set up iOS not to connect with CoreBluetooth API or iOS setting?

They reject my desktop application submission by requesting information. Okay. So what do they want to know? It looks like they are asking me about its in-app purchases with an odd, English sentence. This application doesn't have in-app purchases. It doesn't even use StoreKit. No, the Xcode project doesn't have the in-app purchase capability, either. They often see things that don't exist. They did it in 2011. They still do it. I don't know why they keep wasting my time with this silly reason. I don't know how they sleep at night, not knowing that they have casually clicked on the Reject button. Some people spend weeks, months, if not years, developing software. And they reject it without cause. It's so unscientific of one of the world's largest software companies to punish little people like me.

I am developing a macOS app that acts as a BLE peripheral using CBPeripheralManager. On one MacBook M2, an established BLE connection to a central drops approximately every 14 seconds indefinitely. The disconnect is reported as a supervision timeout. Immediately before the timeout, the controller reports excellent RF conditions, but the peripheral stops receiving packets and all transmitted packets become unacknowledged. I can reproduce this with a minimal ~150-line sample project that publishes one service with a single notify characteristic and does nothing else. I use LightBlue on an iPhone as the central. Hardware Failing: MacBook Air 15" M2 macOS 26.6 and macOS 26.6.2 BLE peripheral implemented with CBPeripheralManager Bluetooth controller: BCM_4387, firmware 23.5.636.5347, PCIe Working: MacBook Pro 16" M1 macOS 26.6 identical application/build On the MacBook M1, the identical sample holds the connection indefinitely. I tested with the same iPhone and LightBlue central, as well as another iPhone. The affected MacBook M2 Mac also worked correctly for approximately one month before the problem appeared suddenly after a normal restart. There was no application or OS update immediately before the failure. Updating the affected MacBook from macOS 26.6 to 26.6.2 did not change the behavior. Reproduction: Run the minimal CBPeripheralManager sample on the M2. Publish one service with one notify characteristic. Connect from LightBlue on an iPhone. Subscribe to the characteristic. Leave the connection idle. The connection repeatedly drops after approximately 14 seconds. Running the identical sample on the MacBook M1 with the same macOS version and the same central works indefinitely. On the failing Mac, bluetoothd reports: lsto: 72 (720 ms supervision timeout) RSSI approximately -46 dBm SNR 60+ receiver initially synchronized during the final ~30 connection events before each timeout: zero packets received every transmitted packet is unacknowledged So this does not appear to be a marginal-RF situation. The peripheral appears to stop receiving the central's connection-event packets, after which its own transmissions are no longer acknowledged and the controller eventually declares a supervision timeout. I have already tried: resetting Bluetooth settings restarting the Mac restarting bluetoothd restarting rapportd disabling Handoff (was already disabled) disabling AirPlay (was already disabled) Safe Mode Bluetooth/system diagnostics None changed the behavior. There are no other applications involved in the reproduction; the minimal sample alone reproduces the problem on MacBook M2, works on MacBook M1 properly. Could anything in CBPeripheralManager usage account for this behavior, such as connection parameters, peripheral latency, or supervision timeout configuration? I have not found a public CBPeripheralManager API that allows the peripheral to configure connection interval, peripheral latency, or supervision timeout. The Generic Access service also appears to be reserved by the system. Given that the identical peripheral application works indefinitely on another MacBook M1 running the same macOS version, could this indicate a Bluetooth controller/firmware or macOS Bluetooth stack issue affecting only some Mac hardware/configurations or system states? I can provide the minimal reproduction project and relevant bluetoothd/Bluetooth controller logs. The sample does not reproduce the issue on the MacBook M1, so the reproduction appears to be dependent on the affected MacBook M2 rather than the application alone.

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security. Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use. Running them as a privileged process, does allow for file changes to be saved though. Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour. APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data. I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps. Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both? Thanks.

So using the developer website in Safari....produces this. How? How is this even possible? I know.... they used Chrome to test and develop with... ;) I am on the latest Safari. Sad.

Sign in with Apple has failed for every user of our app for four weeks. It fails inside Apple's own authorization sheet, before any credential reaches our code. App ID: com.chorestoreapp.app (SJRRC8Q327) Team ID: T4KD7949GL App Apple ID: 6797335710 — TestFlight builds 7 and 8, version 1.0.1 Symptom: The authorization sheet appears and behaves normally. When the fingerprint read is complete, it immediately fails with "Sign Up Not Completed". No credential is returned. When I cancel, it returns ERR_REQUEST_CANCELED, consistent with the sheet being dismissed by the user after being unable to sign in. Sign in with Apple works on the affected device and Apple ID. Downloading an unrelated App Store app and creating a new account with Sign in with Apple succeeded immediately, on the same iPad, with the same Apple ID, minutes before and after a ChoreStore failure. Before that test, Settings → [name] → Sign in with Apple was empty, so the account had never completed the flow — it is demonstrably capable of it now, for other apps. Reproduced with: two Apple IDs, two physical devices, both "Share My Email" and "Hide My Email", Wi-Fi and cellular, and two builds on freshly regenerated credentials. Verified on our side: The signed binary contains com.apple.developer.applesignin = ["Default"] The embedded provisioning profile includes the same entitlement App ID capability, read back from the App Store Connect API: APPLE_ID_AUTH with [{"key":"APPLE_ID_AUTH_APP_CONSENT","options":[{"key":"PRIMARY_APP_CONSENT"}]}] Provisioning profile IOS_APP_STORE, state ACTIVE, expires 2027-08-20 Distribution certificate valid to 2027-08-20 Exactly one bundle ID in the account; no grouped App ID The client call is the standard one, with no nonce or custom parameters: signInAsync({ requestedScopes: [FULL_NAME, EMAIL] }) The distribution certificate and App ID survived an Individual → Organization conversion unchanged (re-verified after the conversion) Why I'm posting rather than filing a code-level request. The request form requires a focused sample Xcode project. A sample cannot demonstrate this: anyone who opens it must sign it with their own team, which changes the App ID — the one variable that is failing. The fault appears to be server-side provisioning for this specific App ID, which no sample can carry. Question: Given the client configuration verifies correct and Sign in with Apple works on the same device and Apple ID for other apps, what would cause the authorization sheet itself to fail for a single App ID, and how can that be investigated or reset? Happy to provide a sysdiagnose, timestamps of specific failed attempts, a screen recording showing the working and failing cases minutes apart, or a TestFlight build.

Has anyone else hit this? We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5 every guided generation request began logging tokenizer errors and long structured requests slowed from seconds to minutes. Beta 6 and beta 7 both still have it. Filed as FB24310823 on August 11 with a full sysdiagnose and log captures, and we have appended evidence from each beta since. The signature is easy to check. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On an affected machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer What we measured on beta 7 today: 9,008 of those pairs in about five and a half minutes of scanning. The errors start about one second into the first request after a fresh app launch, so it needs no warmup. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the quality of the structured content they return is degraded. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

Hi everyone. I'd like to have your opinion on a new update that I have made for my xDesk app. particularly this new update enhance the sharing, creation of custom data sheet and can also record and transcribe what is being said during registration, can scan documents and... more. Really, I'd like to have your opinion. if you are interested the public TestFlight link is: https://testflight.apple.com/join/KathTdzq

Hi, I work with CG movies using sRGB as the working color space, and I’m trying to better understand how macOS handles color in movie files. For CG movies created in sRGB, what color tagging would Apple recommend to preserve the intended appearance in QuickTime Player? For example, would 1-13-1 be considered appropriate in this case? Thanks!

Apple sent me an email asking for info and I didn't reply so they locked my Apple Developer Account. I replied and provided all of the info they requested. I waited a month and called them. A week later they asked for more info and I provided it. It's now been another month since I've heard from them. My account exists, it tells me that the team does not exist. How do I get back to my account?

I am an account holder for my Team ID. I have paid Apple Developer Program too! Unfortunately, I see "Join the Apple Developer Program" and getting "Your Apple Account is already associated with the Account Holder of a membership." message. Also, I am getting "Unable to find a team with the given Team ID to which you belong. Please contact Apple Developer Program Support. https://developer.apple.com/support" error when I go to Certificates, IDs & Profiles. Help!!! Give me fix!!

Feedback Assistant: FB24556583 Please inspect Sign in with Apple server-side registration for Team LQR9X2NWFT / App ID com.kanca.kanca. This is not a client-code or JWT issue. It is blocking App Store review (Guideline 2.1(a)). NATIVE Bundle ID: com.kanca.kanca App Store id: 6804206744 ASAuthorizationController / Flutter sign_in_with_apple. System sheet opens (Hide My Email), Face ID succeeds, then Apple's sheet shows Sign Up Not Completed. No identity token reaches the app. The app does not appear under Settings > Sign in with Apple. Reproduced for days. App Review reproduced it on iPhone 17 Pro Max iOS 26.6 and iPad Air 11-inch M3 iPadOS 26.6. App ID has Sign in with Apple enabled as a primary App ID. Capability re-saved; no change. Same Apple ID completes Sign in with Apple in other teams' apps on the same device. WEB Services ID: com.kanca.kanca.web GET https://appleid.apple.com/auth/authorize?client_id=com.kanca.kanca.web returns invalid_client before any login form (also via curl; no JWT involved). Dummy POST to /auth/token with a valid ES256 client_secret (iss=LQR9X2NWFT, sub=com.kanca.kanca.web, kid=KKYD9GMJS6) and a fake code returns invalid_grant, so the key/JWT/client_id are accepted at the token endpoint. Authorize still reports client not found. Please repair SIWA registration for this team/App ID. Happy to attach a sysdiagnose if needed.

Hello everyone, I've seen quite a few recent threads from developers stuck in long review queues, so greetings to all of you in the same boat. Our iOS app has remained in "Waiting for Review" since its initial submission, with no movement, feedback, or messages in App Store Connect. Timeline: Submitted: Aug 20, 2026 Submission ID: 8ae4090b-e099-4eb1-8868-fc34af838cb2 App ID: 6783428217 Current status: still "Waiting for Review" (9+ days) Steps already taken: Verified all agreements are accepted and there are no pending compliance items or messages on the submission Opened a support case on Aug 27 (Case ID: 20000148931150) — no response yet Filed an expedited review request, as our planned Aug 30 launch date is at risk We haven't received any rejection or request for additional information. Could the App Review team please check whether this submission is stuck in the queue, and advise if any action is needed on our side? Has anyone made it through a similar delay recently? What ended up unblocking it for you? the support case, an expedited request (if you had a planned release date?), or posting here? I'll keep this thread updated with every step we take and every response we get, so others hitting this have a reference.

I’m the owner of sofiaproduction.ru, a legitimate videography portfolio website. Safari on iPhone continues to display a red “Fraudulent Website Warning”. The warning is reproducible on multiple iPhones and networks. The website has no login, payments, downloads, deceptive redirects, or forms requesting personal or financial information. A technical audit found no malware, phishing content, credential collection, external scripts, or TLS/DNS problems. Google Safe Browsing currently classifies the domain as clean. I have already submitted multiple requests through Apple Website Review and filed Feedback Assistant report FB24432044 with a sysdiagnose captured immediately after reproducing the warning. Apple Support confirmed that phone support cannot handle Safari website-classification issues. A separate Security Research report was closed as out of scope without being routed to the responsible team. The warning remains. Could an Apple engineer please confirm the correct escalation path or help route FB24432044 to the team responsible for Safari Fraudulent Website Warning / Safe Browsing classification? I can provide any additional technical evidence required.

I have requested an entitlement for my DriverKit based driver, but the status is still in "Submitted" phase. I have also tried contacting Apple Support by phone/mail but to no avail [Case ID: 20000143721904]. Below are the details of my request. Is there any way to know the turnaround time or to expedite the process as this entitlement is necessary for the distribution of our app? Also, what is the preferrable way to follow up in such cases? Entitlement: com.apple.developer.driverkit.transport.pci - DriverKit PCI (PrimaryMatch) Team: 8S33FS7Q5Q Request Id - NZYWRD96U3 Requested At - August 13, 2026 Type - Team Status - Submitted Thank you, Abishek.

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

We have an app which uses a DriverKit-based driver to communicate with an external device. In multiple iPadOS versions, users have been facing this issue where the option/toggle to enable/disable the Driver is not appearing in the App Settings. As a result, users have to uninstall/install the app to get the option again. Ideally, the option should always appear in the App Settings so that users can freely toggle it according to their needs. Due to this, the external devices connected to the iPad will not be detected. I have not seen this happen during development or in any of the iPad(s) that I have tested the app on. Has anyone seen this happen with their apps and if so, what is the issue/workaround? Is this a known bug only in some specific versions of iPadOS? Also, I have raised a feedback for the same here but there has been no reply. Thanks, Abishek.

The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x<locationID><vendorID><productID>, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }

I have a watchOS app with a connected iOS app using Swift and SwiftUI. The watchOS app should read heart rate date in the background using HKOberserQuery and enableBackgroundDelivery(), send the data to the iPhone app via WCSession. The iPhone app then sends the data to a Firebase project. The issue I am facing now it that the app with the HKObserverQuery works fine when the app is in the foreground, but when the app runs in the background, the observer query gets triggered for the first time (after one hour), but then always get terminated from the watchdog timeout with the following error message: CSLHandleBackgroundHealthKitQueryAction scene-create watchdog transgression: app<app.nanacare.nanacare.nanaCareHealthSync.watchkitapp((null))>:14451 exhausted real (wall clock) time allowance of 15.00 seconds I am using Xcode 16.3 on MacOS 15.4 The App is running on iOS 18.4 and watchOS 11.4 What is the reason for this this issue? I only do a simple SampleQuery to fetch the latest heart rate data inside the HKObserverQuery and then call the completionHandler. The query itself takes less than one second. Or is there a better approach to read continuously heart rate data from healthKit in the background on watchOS? I don't have an active workout session, and I don't need all heart rate data. Once every 15 minutes or so would be enough.

I've basically run the entire Apple website and couldn't find this information.