I’m blocked debugging a watchOS app on a physical Apple Watch. The iPhone connects to Xcode normally (wired), but the Watch either fails to connect with a tunnel timeout or disappears entirely from Xcode after I unpaired it inside Devices & Simulators. Environment Mac: macOS 26.x (Apple Silicon Mac) Xcode: 26.2 iPhone: iOS 26.1 Apple Watch Ultra: watchOS 26.2 (build 23S303) Connection: iPhone connected to Mac via USB (trusted). Watch paired to iPhone and working normally in the Watch app. Issue A (when Watch is visible in Xcode) In Xcode → Window → Devices and Simulators, the Watch shows up but is not usable and fails to connect. Error: “Previous preparation error: A connection to this device could not be established.” “Timed out while attempting to establish tunnel using negotiated network parameters.” In some attempts the Watch shows “Capacity: Unknown” / limited details, and then fails during preparation. Issue B (after unpairing Watch in Xcode only) I unpaired/removed the Watch in Xcode (Devices & Simulators). I did not unpair the Watch from the iPhone. Now: iPhone appears in Xcode and works normally for builds. Watch is still paired to the iPhone and works normally. Watch no longer appears anywhere in Xcode Devices & Simulators (no paired watch section, no watch run destination). What I’ve tried Reboots of Mac, iPhone, Watch (multiple times) Watch unlocked, awake; iPhone unlocked and close to Watch Verified Watch is paired and connected in iPhone Watch app Developer Mode enabled on iPhone and Watch Wi-Fi and Bluetooth ON (Mac/iPhone/Watch), tried toggling both Tried on home Wi-Fi and also with iPhone hotspot (same result) Resetting trust prompts / reconnecting iPhone via USB, re-trusting Mac Apple Watch: “Clear Trusted Computers” Xcode: removing/re-adding devices; clearing derived data; restarting Xcode Watch Developer networking test: Responsiveness = Medium (430 RPM) Questions 1. Is this a known issue/regression with Xcode 26.2 + watchOS 26.2 tunneling (CoreDevice / devicectl)? 2. Is there an Apple-supported way to force Xcode to re-discover a paired Watch after it was removed from Xcode Devices & Simulators (without unpairing the Watch from the iPhone)? 3. Any recommended logs or diagnostic steps I should collect (Console logs, sysdiagnose, specific Xcode/CoreDevice logs) to include in a Feedback report? If helpful, I can provide the full error text from Xcode’s Devices window and any logs you recommend. Thank you in advance,

I used to develop iPhone apps about a decade ago and am now back at it with an iPhone and companion Apple Watch app. Why does it suck so bad? I a must be doing something wrong, but what I am doing is out of the box. The majority of the time when I go to build on the watch I get: Previous preparation error: A connection to this device could not be established.; Timed out while attempting to establish tunnel using negotiated network parameters. Which I then first try to force quit the app on the watch and if that does not work, reboot the watch (which is pretty ridiculous). I tried Gemini and it gave me the following explanation: This is arguably the single most frustrating error in the entire watchOS development ecosystem. As an expert, I can tell you that you are not doing anything wrong; you are fighting a fragile architecture. Here is the technical breakdown of why this happens and a workflow to mitigate it without constant reboots. The Technical "Why" This error message reveals that the issue lies in the CoreDevice (and formerly usbmuxd) infrastructure, specifically in the secure transport layer. The "Tunnel" Failure: Xcode attempts to establish a secure, encrypted tunnel (DTXConnection) to the Apple Watch to push the debugger and the app binary. Unlike the iPhone, which can sustain a high-bandwidth connection easily, the Watch aggressively manages its radios (Bluetooth vs. WiFi vs. AWDL) to save battery. The "Handshake" Timeout: If the Watch is on Bluetooth (Low Energy) when Xcode initiates the tunnel, the bandwidth is insufficient. The system tries to escalate the connection to WiFi (or Apple Wireless Direct Link). If this negotiation takes even a few milliseconds too long—due to 2.4GHz interference, router mDNS configuration, or the Watch CPU being throttled—the handshake times out. The "Previous Preparation Error": This is the insidious part. Once the handshake fails once, Xcode’s device service caches that failure state for the device UUID. It marks the device as "unreachable" to prevent the IDE from hanging indefinitely on subsequent tries. Why you see it constantly: You aren't actually triggering a new connection attempt; you are hitting the cached "failed" state immediately. Unfortunately, the solutions it gives me are: The "Wired Proxy" Method (Most Reliable) This is the gold standard for watchOS debugging. Do not rely on "Connect via Network" for the Watch directly if you can avoid it. Disable WiFi on your Mac (temporarily) or ensure the Mac and iPhone are on the exact same SSID. Plug your iPhone into the Mac via USB. Ensure the Watch is paired to that iPhone. Result: Xcode will tunnel the instructions through the USB connection to the Phone, and the Phone acts as a high-bandwidth proxy to the Watch. This eliminates the "Mac-to-Watch" WiFi negotiation failure point. Do you hit this regularly? What do you do to make for a smooth development and deployment process? Or is it really this fragile? Thanks for any help! Bryan

I'm developing an iOS app that needs to continuously inform a server whether the user's paired Apple Watch is currently reachable for interactive messaging. If this reachability is lost unexpectedly, the server should be alerted within seconds. This is a safety-critical feature where reliability is essential. The goal (abstractly): The iPhone app needs real-time or near-real-time awareness of whether the paired Apple Watch is reachable. The specific mechanism doesn't matter - I'm open to any approach that achieves this reliably. Context - what already works: The iPhone app successfully maintains continuous server connectivity using an NEAppPushProvider network extension. In practice, this runs reliably in the background and sends periodic heartbeats to the server regardless of main app state. This pattern works well for the phone component. I need to extend this to include the watch's connectivity status in those server updates. Note: WCSession APIs are only available in the main app process, not the Network Extension, so any watch connectivity information must be bridged via the main iOS app (e.g. shared UserDefaults and Darwin notifications). What I've tried: 1. Companion watchOS app sending heartbeats to iPhone via WCSession This was my primary approach: a watchOS app sends messages to the iPhone at short intervals using WCSession.sendMessage(). The iPhone forwards this to the server. If heartbeats stop, the server raises an alert. (I tested various intervals from 2-15 seconds; the specific interval doesn't matter because the fundamental problem is that the watch app is suspended regardless.) Problem: The watch app is suspended almost immediately when: The user presses the Digital Crown The user switches to another app The watch screen dims and shows the clock face (even without explicit backgrounding) Once suspended, Timer.scheduledTimer() stops firing and no heartbeats are sent. 2. WCSession.isReachable monitoring on iPhone I hoped the iPhone could monitor WCSession.isReachable to detect when the watch becomes unreachable. Problem: isReachable indicates whether the counterpart app is reachable for interactive messaging, not the underlying physical connection. It returns false for many reasons - watch app suspended, backgrounded, or various system conditions - making it unreliable as a proxy for actual watch connectivity. The iPhone cannot distinguish "watch app not ready for messaging" from "watch physically disconnected". 3. WKExtendedRuntimeSession on watchOS Problem: Only available for specific scenarios (workout, mindfulness, etc.). My use case is general activity, not fitness tracking. Misusing workout sessions would likely be rejected by App Review. 4. WKApplicationRefreshBackgroundTask on watchOS Problem: These tasks are system-scheduled with timing that varies from minutes to hours depending on system conditions. Far too slow and unpredictable for second-level detection. 5. BLE advertising from watchOS app Problem: BLE advertising stops when the watchOS app is suspended. Same fundamental limitation as the timer approach. 6. Server directly pinging the watch (ICMP or similar) Problem: While Apple Watch can have an IP address via Wi-Fi or cellular (on LTE models), inbound connections to the watch aren't feasible - the watch is behind NAT with no public address, and watchOS doesn't support inbound server sockets (especially in background). This approach isn't practical regardless of connection type. 7. CoreBluetooth scanning from iPhone Problem: Apple Watch doesn't advertise as a discoverable BLE peripheral to third-party apps. The system-level pairing isn't exposed. Why this works on Android/WearOS: On WearOS, a Foreground Service continues running in the background regardless of UI state or screen status (subject to standard OS background limits, but in practice it works reliably). The service sends heartbeats via MessageClient consistently. This "always-on background execution" pattern has no equivalent on watchOS. Questions: Is there any mechanism for an iPhone app to have continuous or regularly-updated knowledge of whether a paired Apple Watch is connected and reachable for interactive messaging - ideally without requiring a watchOS companion app to be in the foreground? Are there any system-level APIs or entitlements (perhaps requiring special approval) that expose watch pairing/connectivity events to iOS apps? Is there any watchOS background execution mechanism I've missed that could keep code running reliably when the app isn't in the foreground? Has anyone solved a similar "detect wearable connectivity loss in real-time" problem on the Apple platform? I understand Apple designed watchOS with aggressive power management for good reasons. If continuous connectivity monitoring truly isn't possible, I'd appreciate confirmation so I can set appropriate user expectations. But given this is a safety-critical use case, I'm hoping there's an approach I've overlooked.

Description: I’m encountering an issue where the Apple Watch’s watchOS version is lower than the deployment target specified in my Xcode project. For example, my Watch device is running watchOS 10.6, but my app’s deployment target is set to watchOS 9.6 or 10.6, and Xcode shows an error stating: Error: “watchOS version doesn’t match the app’s deployment target.” Could someone clarify how to properly handle this version mismatch? Environment: Xcode 26 iPhone: iOS 18 Apple Watch: watchOS 10.6 Any guidance or best practices would be appreciated.

We are seeing an issue where sending data using the asynchronous method HKWorkoutSession.sendToRemoteWorkoutSession(data: Data) will never return in some cases (no success nor failure). This issue is happening for roughly 5% of Workouts started and will stay broken for the whole workout. The other 95% of the workouts, the connection works flawlessly. This happens on both watchOS 10 and 11, and with phones running iOS 17 or 18. The issue is quite random and not reproducible. Our app has thousands of workouts a day that use the workout session workout data send, with constant messages being send every few seconds. In some of those 5% cases the "sendToRemoteWorkoutSession" will throw way later, like 30+ minutes later, if the watch app is awake long enough to capture a log of a failure. Our code uses the same flow as in the sample project: https://developer.apple.com/documentation/healthkit/workouts_and_activity_rings/building_a_multidevice_workout_app Here is some sample code, which is pretty simple. Setup code: let workoutSession = try HKWorkoutSession(healthStore: healthStore, configuration: configuration) workoutSession.delegate = self activeWorkoutSession?.startMirroringToCompanionDevice { success, error in print("Mirroring started on companion device: \(success), error: \(error)") } workoutSession?.prepare() then later we send data using the workout session: do { print("Will send data") try await workoutSession.sendToRemoteWorkoutSession(data: data) print("Successfully sent data") // This nor the error may be called after waiting extensive amounts of time } catch { print("Failed to send data, error: \(error)") // This nor the success may be called after waiting extensive amounts of time } So far, the only fix is to restart the phone and watch at the same time, which is not a great user experience. Is anyone else seeing this issue? or know how to fix this issue?

Hi everyone, I’m a student developer currently building a watchOS app that uses HealthKit and HKWorkoutSession to estimate core body temperature from real-time heart rate data. The app runs well in the simulator, but testing on a physical Apple Watch has been extremely difficult. Each time I try to run the app from Xcode (Version 16.3), the build gets stuck on: “Copying shared cache symbols from MyWatchName (0% completed)” Sometimes it just stops stating connection failure. However, more often no errors are shown, but the sync never finishes. I’ve tried the following without success: Restarting the watch, iPhone, and Xcode Switching networks (Wi-Fi and hotspot) USB wired pairing Resetting developer settings and trust prompts Deleting derived data Rebuilding the project This is especially limiting for a real-time health tracking app where I need to monitor HKLiveWorkoutBuilder data while the screen sleeps — which can’t be tested effectively in the simulator.

I have an independent watchOS app, and I am a partner of the related iOS app. This means the IOS app can give me its bundle ID. So, here is the question: If I want my watchOS app be listed under the iOS app store page. Do I only need my bundle ID to be associated with the iOS project ? Is it necessary for the watchOS project and the iOS project to be in the same project?

I added an Apple Watch app target for an iOS app. If I install it directly through Xcode it runs, however it seems to be able to communicate with iphone through Watch Connectivity framework and once I close the app it seems to uninstall itself from the watch. When I installed the iphone app frist, the app does not show up on the available apps on the iphone Watch application, what could be the issue ? The iphone app was created using react native through expo. Testing Devices Iphone 13 pro max IOS 26.0.1 --- Apple Watch Series 4 WatchOS 10.6

Hi all. Does anyone know if there's a way to get a list of watch faces for a paired Apple Watch or to set the current face? Or is this just not allowed? I've taken a look at the WatchOS, WatchKit, and WatchConnectivity documentation and no luck there.

I have both apple devices, AirPods Pro 3 is up to date and Ultra 3 is on watch os 26.1 latest public beta. Each morning when I would go on my mindfulness app and start a meditation or listen to Apple Music on my watch and AirPods Pro 3, it will play for a few seconds then disconnects. My bluetooth settings on my watch says my AirPods is connected to my watch. I also have removed the tick about connecting automatically to iPhone on the AirPods setting in my iPhone. To fix this I invariably turn off my Apple Watch Ultra 3 and turn it on again. Then the connection becomes stable. I am not sure why I have to do this each morning. It is frustrating. I am not sure why this fix does not last long? Is there something wrong with my AirPods? Has anyone encountered this before?

Beta two keeps hanging during the download process and says connect to wifi (which I am) or after hours it may download the beta 1.4gb file only to have to freeze in next processing step. I have tried all the resets, reinstalling both the watch and the phone running OS26.1 Beta 2 etc. The impact is the watch and the current software implementation is only getting a couple hours of battery usages before going dead

How to launch companion Watch App without relying on Health Kit? I need my companion watch to launch automatically in some specific cases. What I'm doing to achieve that is to call "startWatchApp" in HKHealthStore(). This worked flawlessly for well over a year but AppReview is now giving me a hard time about using HealthKit without actually using health related data. Is there a way to do the same without using HealthKit? Seems silly that this is bundled only with the HealthKit... If I don't find another solution I will probably be forced to start reading heart rate data and reporting it to the user just so that AppReview will stop saying that I have no reason to use HealthKit... But ideally I'd love to learn about a way to open the companion Watch app without HealthKit and do things the right way...

I'm trying to update data displayed in my Watch Complications (WidgetKit). I have an iOS app that sends data to the Apple Watch using WCSession.default.transferUserInfo. However, the data only updates on the complications or widgets after I open the watchOS app manually. Ideally, I'd like the Watch widget/complication to reflect the updated data as soon as it's sent from the iPhone, without requiring the user to open the Watch app.

Hi everyone, I'm building a health-focused iOS and watchOS app that uses WatchConnectivity to sync real-time heart rate and core body temperature data from iPhone to Apple Watch. While the HealthKit integration works correctly on the iPhone side, I'm facing persistent issues with WatchConnectivity — the data either doesn't arrive on the Watch, or session(_:didReceiveMessage:) never gets triggered. Here's the setup: On iPhone: Using WCSession.default.sendMessage(_:replyHandler:errorHandler:) to send real-time values every few seconds. On Apple Watch: Implemented WCSessionDelegate, and session(_:didReceiveMessage:) is supposed to update the UI. Both apps have WCSession.isSupported() checks, activate the session, and assign delegates correctly. The session state shows isPaired = true and isWatchAppInstalled = true. Bluetooth and Wi-Fi are on, both devices are unlocked and nearby. Despite all this, the Watch never receives messages in real-time. Sometimes, data comes through in bulk much later or not at all. I've double-checked Info.plist configurations and made sure background modes include "Uses Bluetooth LE accessories" and "Background fetch" where appropriate. I would really appreciate guidance on: Best practices for reliable, low-latency message delivery with WatchConnectivity. Debugging steps or sample code to validate message transmission and reception. Any pitfalls related to UI updates from the delegate method. Happy to share further details. Thanks in advance!

I have an Apple Watch 4. (GPS). It's on version 10.6. I'm trying to deploy a basic app onto it (IOS 18) (WatchOS 9.6). I've set the targets in General for Watch App, Watch AppTest, Watch AppUITest. I still get an Apple Watches watchOS doesn't match App Watch app.app watch02 9.6 deployment target. Upgrade users Apple Watch watchOS version or lower app app.apps deployment target. What can I do to fix this?

I am experiencing an issue with my watchOS app. My application updates a shared file, accessible by both the main app and the WidgetKit extension, during a WatchConnectivity background task. Following this update, I call reloadAllTimelines(). This functionality worked as expected on watchOS 10, even without Developer Mode enabled. However, after updating my device to watchOS 11.5, this API appears to be broken. My reasons for believing this API is broken are threefold: The functionality worked reliably on watchOS 10. On watchOS 11.5, enabling "WidgetKit Developer Mode" (found under Settings > Developer) resolves the issue, and my complications update correctly. When I enter watch face edit mode, the snapshot/preview displayed (which utilizes the same underlying logic as the timeline API) shows the correct data. This indicates that the data has been successfully received from the phone, and the widget is indeed reading the updated shared file. Despite this, the actual widget view during its resting phase never updates. It's worth noting that TimelineReloadPolicy functions as expected, but I cannot rely on this for my use case. My widget requires immediate updates upon receiving new data. Apple, please investigate this behavior.

In general my workout app is reachable from the iPhone when running a workout, even if in the background. However if the watch app restarts (due to crash or being closed via the dock) via handleActiveWorkoutRecovery then it is only reachable when in the foreground, even though a workout is running. Is this expected / desired behaviour? Is the app given a tighter sandbox (having it's "background privileges" reduced) because of the earlier crash? This behaviour occasionally happens without a crash (or being closed via the dock) - all of a sudden it is no longer reachable via the iPhone. It feels like the app is being "sandboxed" like in #1 but there is no crash or any other kind of log indicating any issue. Generally the only remedy is to stop the workout and restart the app. My question is - is this expected? Is there some condition that causes the watchOS to sandbox the app? Or is this a Watch Connectivity bug?

Hello all, I have run into a weird situation in my watchOS app with a companion iOS app. Issue: Watch fails to receive sendMessage string sent from phone while watch is in foreground. This is not consistent and seems to happen randomly under certain conditions. Order of operations: User Opens phone app & watch app -> user presses "sendMessage" button, func is called -> watch does not receive message while in foreground Condition explanation: To my knowledge, without a HealthKit workout session active, the apple watch is not available to receive messages (using any internal library transmission type) from its iOS companion app while the watch screen is not in the foreground (i.e. inactive). However, my issue is that sometimes, while the watch IS in the foreground, it does not receive the companion app's message. Additionally, this is not resolved by force quitting both iOS and watchOS apps. The only way I have gotten this issue to go away is by restarting both the phone and the watch. Again, it is not a consistent behavior and seemingly happens randomly. This behavior has been observed across multiple different beta testers on different hardware. This is only apparent when transmitting from Phone -> Watch. I have not experienced any transmission issues when transmitting Watch -> Phone. My team and I have speculated that it could be an issue with WCSession.isReachable returning true before we transmit the message but changing to false before the hardware actually transmits. However, this wouldn't explain why the watch would not be available while in the foreground. This is just a preliminary thought. My goal in posting on here is to see if anyone else has experienced this, or if it's a known bug. All message protocols have been coded to follow Apple's WCSession documentation as closely as possible. Hardware specs: Watch Model: A2093 (series 5) WatchOS ver: 10.6.1 Phone: MU693LL/A (15 pro max) iOS ver: 18.3.2 XCode ver: 16.0

I am able to get location in for ground and back ground but Now I need to get location when user killed app.

We developed a camera remote control app for Apple Watch, but during the development process, we found that Apple Watch is prone to sleep on its own without screen interaction (usually automatically sleeping between 5s and 15s when there is no interaction, but our Apple Watch app actually receives the camera preview video frame data we transmit all the time, and there is no data interaction), and then triggers the sessionReachableDidChange function, and the session.isRechable is false. We hope that the camera remote control app for our Apple Watch can remain on when in the foreground, making it convenient to control our camera app on our phone. We found that DJI's Apple Watch app does not automatically sleep and does not sleep for more than 2 minutes. We have tried many methods, such as heartbeat packets, and I have added WKSupportsAlwaysOnDsplay to the Apple Watch info.plist file, but have not found an effective solution. I hope you can provide assistance, thank you.