At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for watchOS (part 1). 1. I'm really excited about the new design system on all platforms. Liquid Glass is super cool. What do developers need to keep in mind when building for watchOS 26? To adopt the new design system, start with updating your app for watchOS 10 – If you have done so, your app will be mostly ready for watchOS 26. For more information, see Design and build apps for WatchOS 10. You can then look into Liquid Glass specific APIs to fine tune your app. This topic is covered in Adopting Liquid Glass. If you have SwiftUI views using any custom style, make sure they are still legible and fit with the new design system. 2. Something that really stood out to me were updates to the Smart Stack, with the system prioritizing Widgets when they're most relevant. Tell me more about these new opportunities for apps. Workout apps that record workouts using HealthKit may be automatically suggested on the watch face and appear in the Smart Stack without adding a widget. Relevant widgets are a great way to present information related to a date, location, point-of-interest type, sleep schedule, or fitness condition in the Smart Stack when it is relevant. Relevant widgets don't need to display a empty state view when they are not relevant. They are only shown in the Smart Stack when relevant. The watchOS 26 Design ToolKit in the Apple Design Resources includes a set of templates that you can use to layout your widgets. 3. Is the Wrist Flick gesture available to developers in the same way as Double Tap is? The system uses Wrist Flick to dismiss notifications and incoming calls, silence timers and alarms, or return to the watch face. There is no separate API for the Wrist Flick gesture. Apps that are using XCUIAutomation to make sure their user interface behaves as intended can use the XCUIDeviceHandGesture.flick to automate tests that verify that their app responds appropriately to the Wrist Flick gesture. For apps using automated testing, the XCUIDeviceHandGesture.doubleTap can be also be used to automate testing of the app with the Double Tap gesture. See XCUIDevice.perform(handGesture:) 4. Can HRV measurements be triggered on demand via API in watchOS? Guidelines or processes for enabling energy-intensive biometric sampling on development devices for IRB-approved research? You don’t have direct control on the sampling rate in watchOS. You can use HealthKit (HKQuantityTypeIdentifierHeartRateVariabilitySDNN, to be specific) to query the HRV data, once the system has sampled and persisted the data to HealthKit. If that doesn’t help, we suggest that you file a feedback report with your concrete use case for us to investigate. Specific to IRB-approved research using Apple Watch or its companion iPhone, you might want to look at this FAQ and SensorKit to see if they can be of any help. 5. What is the best advice for someone who is new to making a watchOS app that’s been on iOS and iPadOS? You can start with exploring the system experience features on watchOS, such as notifications, controls, and widgets, and getting familiar with the system spaces, like Smart Stack, watch face, and control center. Knowing the watchOS app design principles and practices is important as well. Design and build apps for WatchOS 10 is a great resource for this topic. SwiftUI is an amazing across-platform framework, and you will use it to create your watchOS app. If you're already using it, great! Keep in mind some watch-only constraints. Comparing to iPhone or iPad, Apple Watch has a limited battery and smaller screen size, which significantly impacts how people use your app and how your app works. 6. Was there any extension this year to the 7 day limit on querying Apple Health data on the watch? There is no change on the limit this year. You can get this official limit at runtime using earliestPermittedSampleDate. There are some exceptions, and so don't be surprised if you see some data types are retained longer. The companion iPhone holds the full set of the health data. If you need to access the health data that has been purged from the Apple Watch, consider doing it with your iOS app, and then passing the result to your watchOS app.

At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for watchOS (part 2). 7. For widget (complication) update budgets, is there an overall budget or are scheduled update separate from APNS updates? For context I have a complication that is updated on a fixed schedule (every 20 min), but there can be times of the day that are more "interesting" where pushes make sense. Like timeline updates, the system budgets WidgetKit push notifications and delivers them opportunistically. You can use WidgetKit push notification updates as an addition to timeline updates. For more information, see Updating widgets with WidgetKit push notifications. 8. It seems like the new Control Center widgets can be sourced from either the iPhone or directly on the Watch. Can we control whether a control appears in the watch list, or will it always be a combination of all controls from both sources? iPhone controls will be automatically available on the companion Apple Watch, even if they don’t have an associated watchOS app. When an iPhone control is tapped on the Apple Watch, the action is performed on the iPhone. Controls whose actions foreground the iOS app will not appear on Apple Watch. If a watchOS app has controls, no controls will appear on Apple Watch from the companion iOS app. 9. From UI/UX perspective, what are the current practices for Designing watchOS apps that feels native. The WWDC23 session Design and build apps for WatchOS 10 covers the details of watchOS design principles and how to apply them in your app using SwiftUI. A lot of SwiftUI APIs, such as NavigationSplitView, vertical tab view, list view, and etc, already implement the look and feel native to watchOS. 10. When adopting the new design system on watchOS, it seems like the main place we will use the glass effect is for our buttons in toolbar? Standard buttons in system apps seem to continue to use a flat appearance and full width. We leave the choice to you – You can use the new GlassButtonStyle API or .buttonStyle(.glass) to apply the liquid glass material to buttons. Learn when to use the Liquid Glass styles in Get to know the new design system. 11. Is there any way to gracefully migrate extensions when their bundleIDs have to change? e.g., converting a multi-target watch app to single-target, which drops the .watchkitextension from both the app and WidgetKit ext bundleIDs Updating a watchOS app to single-target is covered in TechNote TN3157: Updating your watchOS project for SwiftUI and WidgetKit. Xcode provides a tool that can do the update automatically, and the technote describes the details about how to use it and how to clean up the project after the automatic update. If there's something that technote doesn't address, please reach out to us on the Developer Forums. 12. What is the status of WatchConnectivity? Is that still the preferred way for iOS + watchOS communications? The Watch Connectivity framework is still supported, and is appropriate for the communication between an watchOS app and its companion iOS app. The systems also provide other APIs for the apps to exchange data. For example, watchOS supports Apple Push Notification service (APNs). If data for your widget changes on your server, your widget can receive a WidgetKit push notification, and update accordingly. That’s the preferred mechanism for widget updates.

Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that. There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test: – Installed through VPP on supervised devices running watchOS 26.1. – Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2. This strongly appears to be a VPP signing issue because we even did the following experiment: Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2. Verify that both apps launch successfully. Use an MDM command to install from VPP over the existing installations Verify that the watch app fails to launch (the iOS app is unaffected) My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.

Our App Store watch app is being terminated by dyld before any app code runs, only on watchOS 26.2 (23S303) and 26.3 (23S620). Only the arm64 slice is affected (Series 9/10, Ultra 2), and almost always on background launches. Termination Reason: DYLD 9 Assertion failed: (0), function getNameSelRefVMAddr, file ObjCVisitor.cpp, line 1319. objc_visitor::Method::getNameSelRefVMAddr (ObjCVisitor.cpp:1319) dyld4::optimizeObjCSelectors (PrebuiltObjC.cpp:530) dyld4::PrebuiltObjC::make (PrebuiltObjC.cpp:1372) dyld4::PrebuiltLoaderSet::makeLaunchSet (PrebuiltLoader.cpp:2309) dyld4::prepare (dyldMain.cpp:960)Our previous app version crashes in the same function with SIGSEGV instead (same frame offsets on the same dyld build). The fault address lies just past a mapped-file region. What we checked: The crashing binary UUID matches our archive. Every ObjC method list in every image is a standard relative list (0x80000000). None has the selector-offset flag (0x40000000), which is what that assertion branch expects according to the open-source dyld. dyld_info -objc parses all images cleanly. Build settings and linker flags are defaults (Xcode 27.1). So it looks like dyld is reading the wrong data while building the launch closure, rather than our binary being malformed. This seems related to https://developer.apple.com/forums/thread/810471: same OS range, same "dyld before main(), ObjC metadata" symptom. That report involves VPP installs, while ours is App Store distribution. Full crash logs, binaries and analysis are in FB25270892. Has anyone else seen this? Is it fixed in watchOS 26.4 or later, and is there any workaround on the app side?

I’m evaluating a native watchOS smart-alarm app and would like to clarify whether public APIs support its core requirement before building a prototype. The app would wake the user during a 20–30-minute window before their selected alarm time, using Apple Watch’s own sleep-stage classifications available through HealthKit’s sleepAnalysis category: Core, Deep, REM, and Awake. I have reviewed HKCategoryValueSleepAnalysis, HKAnchoredObjectQuery, HKObserverQuery, background delivery, and WKExtendedRuntimeSession’s Smart Alarm mode. However, I haven’t found documentation establishing when Apple-generated sleep-stage samples become available during an ongoing sleep session. Could you clarify: Are Apple-generated sleep-stage samples written to the Watch’s local HealthKit store during sleep, or only after the sleep session ends or subsequent processing? If available during sleep, is there any documented update cadence or latency that would make them suitable for a smart alarm? Should the latest sample be treated only as a retrospective classification rather than the current sleep stage? Can an app query these samples during a Smart Alarm extended runtime session while the Watch is worn and unlocked, with its display off and Sleep Focus enabled? Are there relevant execution or data-access restrictions? If this use case is unsupported, is there any public API that exposes Apple’s current sleep-stage estimate? If not, which Feedback Assistant category is appropriate for requesting this capability? The intended approach queries HealthKit directly on Apple Watch, without depending on Watch-to-iPhone synchronization, and retains a fixed latest wake-up time as a fallback. This is an API feasibility question, not a reproduced bug. I haven’t yet built or tested a prototype. Thank you.

In the WWDC 2019 session "Extended Runtime for WatchOS apps" the video talks about an entitlement being required to use the HR sensor judiciously in the background. It provides a link to request the entitlement which no longer works: http://developer.apple.com/contect/request/health-monitoring The session video is also quite hard to find these days. Does anyone know why this is the case? Is the API and entitlement still available? Is there a supported way to run, even periodically, in the background on the Watch app (ignoring the background observer route which is known to be unreliable) and access existing HR sensor data

iOS 27 adds a second stage to HealthKit read authorization. After picking data types, the user chooses "Past 30 Days and Future Data" or "All Recorded Data and Future Data", with Allow disabled until one is selected. Every user of every health app now makes this call, in the first seconds of onboarding, with no real context about what the app needs. I don't think the scale of this has landed yet. A meaningful share of users will pick 30 days. multi-year health trends, month to month comparisons, all-time records: with 30 days these features don't get worse, they stop existing. And it breaks silently. The user sees empty charts and a app that doesn't do what the screenshots promised. They won't connect that to a sheet they tapped through on day one — they'll connect it to the app. That's the reckoning: a wave of one-star reviews and support mail for a decision the developer never saw and can't inspect. Because we can't inspect it .authorizationStatus(for:) deliberately hides read authorization and getRequestStatusForAuthorization only says whether prompting would show UI, so a 30-day grant and a genuinely new Apple Watch user look identical from the query layer. A callback when Health permissions change for a type — even without disclosing the new state — would go a long way here. And we can't route users to the fix. UIApplication.openSettingsURLString opens the app's own Settings page, which has no Health section. The real control sits at Settings › Privacy & Security › Health › — four levels deep, unreachable from any public API. My suggestion is a URL constant scoped to the calling app, the way openNotificationSettingsURLString (iOS 15.4+) and openDefaultApplicationsSettingsURLString (iOS 18.3+) already work. But that's just my idea; if there's a better mitigation, or something already planned, I'd like to hear it. Worth saying the privacy gain looks thin either way: the app keeps all future data indefinitely, so a 30-day grant becomes a full-history grant in thirty days for anyone who keeps the app. The window limits what's readable today, not what accumulates. iOS 27 release is approaching... I think this will cause problems 😞 Filed as FB24398048 and FB24398031

After updating to watchOS 27, some users of my app can no longer launch the watch app. The watch shows: "[App] Needs to Be Updated — The developer of this app needs to update it to work with watchOS 27." The shipping version is not the problem. My current App Store release contains both arm64_32 and arm64 slices in the watch app and its extension, and launches correctly on watchOS 27 when freshly installed. Affected users already have the current version on iPhone. Archives going back to December 2022 also contain arm64. The fix, in both cases so far, is for the user to remove and reinstall the watch app: Watch.app → My Watch → [app] → toggle "Show App on Apple Watch" off, wait for the icon to disappear, then back on. After that it launches normally on the same device and OS version. My working theory is that the installed copy is thinned at install time. A watch that installed the app under an earlier watchOS received an arm64_32-only copy, which persisted through later app updates and OS updates. watchOS 27's 64-bit requirement then rejects it. A reinstall on 27 pulls the arm64 slice. One affected user has had the app installed on an Ultra 2 since December 2023, which fits. I have not been able to verify the contents of the installed copy on a user device, so this is inference rather than confirmed. Two things I'd like to know: Is anyone else seeing this? If so, what was the install history of the affected devices? Is there any supported way to force a watch app to be re-downloaded, or to detect from the iPhone app that the watch copy is in this state? Right now users have no indication that a reinstall fixes it, and the message points at the developer. Feedback filed as FB24834097

Filed as FB24834050. Still reproducible on watchOS 27.0.1 (24R365). Posting here in case an Apple engineer can help route it, and to see whether other developers are seeing the same behavior through HealthKit. Minimal reproduction (under 3 minutes, no distance involved) Apple Watch Series 10 (GPS) running watchOS 27.0.1 (24R365), paired to an iPhone 15 running iOS 27. Start an Other workout. Move your arms continuously for about 2 minutes (I use air punches). No treadmill, GPS, or distance calculation involved. End the workout and review the heart rate samples. Result: One heart rate sample at approximately 0:05, then no additional samples for the rest of the workout. Expected: Continuous heart rate sampling every few seconds, which is how the same watch behaved on watchOS 26. This reproduces 100% of the time across every workout type I've tried since updating to watchOS 27.0. It did not occur on watchOS 26 using the same watch, same wrist, and same fit. Key diagnostic: the sensor is working, the workout session path is not. The Heart Rate app reads immediately and continues updating every few seconds, even while a workout is running. Background heart rate sampling outside workout sessions works normally. Active energy for my daily 65-minute session is accurate when no workout is started (405 calories on 9/22/26, consistent with watchOS 26). Recording that same session as an Indoor Walk workout results in roughly half the active calories (typically 185-200 versus high-300s/low-400s before the update). Starting a workout appears to suppress a working measurement path and replace it with one that is failing. Downstream impact A 1:06:13 session has been credited as 9, 35, and 55 exercise minutes on different days. Since exercise-minute credit for walking is heart-rate driven, the lack of heart rate samples appears to directly affect exercise credit. Separate issue in the same build (not the subject of this post) Indoor distance is consistently about 50% low. A 1:06:13 walk at a constant 4.1 mph should be 4.52 miles, but the watch reports roughly 2-3 miles even though step counts are correct. The watchOS 27 User Guide describes a redesigned pedometer model using new machine-learning algorithms for treadmill distance. Series 12 and Ultra 4 owners are reporting the same shortfall with matching step counts, including on clean installs, so this does not appear to be hardware-specific. The heart rate dropout reproduces in the Other workout type, which performs no distance calculation, so the two issues appear to be independent regressions. Already ruled out Health details are correct Wrist Detection enabled Power Saving Mode off on both watch and iPhone Heart Rate and Fitness Tracking permissions enabled Motion Calibration & Distance enabled Watch fit and position unchanged Both devices restarted Fitness Calibration Data reset Full unpair/re-pair Multiple workout types tested Pause/resume mid-workout (heart rate briefly shows "Searching" and then drops out again) FB24834050 includes two sysdiagnoses from watchOS 27.0 and currently shows "Recent Similar Reports: More than 10." Status remains Open with no response. Ask Can anyone from Apple confirm whether this is a known/tracked issue? Also, would a sysdiagnose captured using the watchOS logging profile from the Apple bug-reporting site be useful? I'm happy to install the profile, reproduce the issue in under three minutes, and attach fresh logs. I'm also interested in hearing from developers using HKWorkoutSession. Are you seeing the same heart-rate sample gaps on watchOS 27 in your own apps? That would help determine whether this is specific to the Workout app or a regression in the workout session layer underneath it. Thanks!

I'm hitting a toolchain inconsistency between Xcode 26.3's asset compiler (actool) and App Store Connect's upload validator, and I have build logs proving both sides. The builder side (actool in Xcode 26.3): When compiling the asset catalog for our watchOS target, actool reports "unassigned children" for the watchOS longLook icon role - specifically [watch][44x44][longLook][42mm][2x] - and does NOT compile it into Assets.car. The 42mm longLook icon simply cannot be produced by the toolchain. The checker side (App Store Connect): Uploading the resulting archive is REJECTED by the App Store Connect validator with a "Missing Icon" error for a 44x44 at 2x image (Long Look 42mm). So the builder cannot produce the exact icon the checker demands. This is an Apple toolchain inconsistency - either: actool should compile the longLook 42mm role into Assets.car, or the App Store Connect validator should not demand an icon the toolchain cannot emit. Environment: Xcode 26.3 watchOS app target with an App Icon asset catalog containing the longLook role configured for 42mm 2x Question: Is this a known issue, and is there a workaround to produce an upload that passes validation? I can provide build logs for both sides on request.

I'm trying to debug a problem that's affecting customers who have upgraded to WatchOS 10, and I'm unable to get any console output from the watch when I debug the watch app in Xcode, or from the console app connecting from my Mac. The other weird thing is that my watch shows up twice in the device list in the console app. Is this a known issue?

Hi! We have an app that highly depends on CoreBluetooth including scanning for peripherals with an advertised serviceUUID. Our app sets the CBCentralManagerScanOptionAllowDuplicatesKey flag to true while scanning. Receiving continuous discovery events about nearby devices is key to measure the RSSI before connecting. Updating some of our test devices to watchOS 27 we noticed that our app is broken. To analyze further we created a simple app to compare behavior between watchOS 26 and 27, and the difference is clear. On the 27 device it behaves like the flag is ignored and we only receive a couple of callbacks to centralManager(_:didDiscover:advertisementData:rssi:) then it stops. We could not find any documentation declaring this as a new restriction or something regarding that has changed. Is this a bug, or is there a way to get the old behavior on the new OS? The example app used for testing is available here: https://github.com/levente-gulyas-skidata/WatchBLEExperiments (Change the serviceUUID for testing if needed) Thank you, Levi

I am unable to build to my Series 12 which is on watchOS 27.2 beta 2, I have macOS 27.2 beta 2 and Xcode 27.2 beta 2 but when I open up Device Hub, and click on my watch, it says Tunnel State("Connecting" then "Disconnected") and won't ever connect. the app im building is watchOS only and so iPhone is incompatible and I've tried restarting every device but nothing works.

Hi everyone, I’m building a sports performance app for Apple Watch that uses the onboard IMU to analyze swings and impacts in sports like tennis and golf. The goal is to estimate club/racket head speed, ball speed, and shot quality in real time from wrist motion data. With Core Motion, I can currently get deviceMotion updates at ~100 Hz. While this is fine for general movement tracking, the actual ball impact happens much faster — 5–10 ms in tennis and ~0.5 ms in golf. Many of the high-frequency vibration/impact components are missed at 100 Hz, making it hard to directly measure or more accurately estimate certain performance metrics. Questions for Apple / community: 1. Is there a way to access raw accelerometer and gyroscope data at higher sampling rates (e.g., 500–1000 Hz) on Apple Watch? 2. If not, is this due to hardware limitations or an API/software constraint? 3. Are there any research, partner, or beta programs that allow deeper sensor access for sports-science use cases? Even modest increases in IMU sampling could unlock more accurate ball-speed estimates, impact force analysis, and strike-quality detection without needing external sensors — making Apple Watch a best-in-class wearable for precision sports analytics. Happy to share more about the current approach, sample data, and potential use cases if helpful. Thanks, Max

Hi all, I'm building a watchOS VoIP app that places and receives calls through CallKit, with call audio staying on the watch (not routed to the paired iPhone). Calls connect and audio works. But three parts of the system in-call UI that the native Phone app shows never appear for my app, and I'd like to confirm whether this is expected or a misconfiguration on my side. Environment watchOS 26.0, Apple Watch 11 (reproduced on a physical device) Xcode 27.1 Companion watchOS app, calls driven by CXProvider / CXCallController What's missing during an active call No DTMF keypad. The user can't open a keypad from the system call screen, so in-call DTMF (e.g. navigating an IVR) is impossible. No audio-route picker. No control to switch output route (e.g. speaker vs. the default route). No entry in Recents. Completed calls don't appear in the watch's call history. The system call UI is full-screen and in front, so I also can't present my own keypad or route control on top of it. What I've already tried (all public API) // Reported call callUpdate.supportsDTMF = true // Provider configuration config.includesCallsInRecents = true config.supportedHandleTypes = [.phoneNumber] config.maximumCallGroups = 1 // Audio session: route changes programmatically, but adds no user-facing picker try session.setCategory(.playAndRecord, mode: .voiceChat) try session.overrideOutputAudioPort(.speaker) // Never invoked — no keypad exists to generate the action func provider(_ provider: CXProvider, perform action: CXPlayDTMFCallAction) { ... } None of these make the keypad, the route picker, or a Recents entry appear. The behavior is identical regardless of these values, which makes me suspect these controls are exposed only for the native telephony/relay call path, not for third-party CXProvider calls on the watch. Questions Are the in-call DTMF keypad, audio-route picker, and Recents entry available to third-party CXProvider calls on standalone watchOS at all, or are they reserved for the system (relayed cellular / FaceTime) call UI? If not, is there a supported way to present my own keypad or route control during an active CallKit call, given the system call UI is in front? Thanks!

I have a watchOS app communicating with a BLE peripheral during an active HKWorkoutSession. The workout provides sufficient runtime: once connected, the Watch can receive a notifying GATT characteristic approximately once per minute for hours, including while the display is off. In normal conditions the connection is very stable. The difficult case is outdoor use with marginal RF conditions. The peripheral and application protocol otherwise work reliably, but outdoors there are fewer reflected RF paths and normal body movement can intermittently obstruct the Watch-to-peripheral path. In those situations the link occasionally terminates with CBError.connectionTimeout. Reconnection is particularly important because this peripheral advertises for reconnection only approximately once per minute. We also know approximately which second of each minute the peripheral becomes active, so missing a single advertising opportunity can cause a relatively long data gap. I’m trying to better understand the supported CoreBluetooth/watchOS behavior in this situation. Maintaining a marginal existing connection Once the BLE connection is established, are there any public CoreBluetooth mechanisms or recommended practices for making that connection more robust against CBError.connectionTimeout? In particular, can application-level GATT activity have any influence on connection scheduling or link robustness, or is this entirely handled by the Bluetooth stack below CoreBluetooth? CBConnectPeripheralOptionEnableAutoReconnect with sparse advertising When CBConnectPeripheralOptionEnableAutoReconnect is enabled and the connection is lost, how does watchOS handle a peripheral that advertises only very infrequently? Does CoreBluetooth simply keep the reconnect pending and wait for subsequent advertisements indefinitely, subject to system policy? Known peripheral activity timing If the app knows approximately when the peripheral becomes active and advertises each minute, is there any supported way to make use of that timing during reconnection? Or should the app simply leave AutoReconnect pending and let CoreBluetooth handle reception? WWDC22 reduced reconnection range WWDC22 session 10135 says: “If your device is on the edge of Bluetooth range and repeatedly disconnects while in Background BLE connection, the reconnection range will be reduced. This means only devices close to the Apple Watch will reconnect.” The session also says these limits are counted over a rolling 24-hour window and are reset when the user interacts with the app. I would particularly appreciate clarification of how this works in practice: What conditions cause a disconnect to count toward this policy? Does this policy apply while an app has an active HKWorkoutSession and continues executing in the background? Is the state maintained per peripheral, per app, or more globally? What exactly constitutes the user interaction that resets it? Does bringing an already-running workout app back to the foreground reset it, or does the app need to be relaunched? Is there any public API or diagnostic indication that reduced reconnection range is currently active? Is there any supported way to explicitly clear/reset that state? Connection parameters Does watchOS expose any supported mechanism for a CoreBluetooth central to influence parameters relevant to connection robustness, such as connection interval, supervision timeout, PHY, transmit power, or similar link parameters? Diagnosing CBError.connectionTimeout When CoreBluetooth reports CBError.connectionTimeout, is there any supported diagnostic method to determine whether the Watch stopped receiving the peripheral, the peripheral stopped receiving the Watch, or whether this should simply be treated as a link-layer timeout without attribution to either side? For context, this is not primarily a background-runtime problem. The active workout keeps the app running and the normal persistent BLE connection can operate flawlessly for many hours. I’m specifically trying to understand the best supported strategy for preserving and recovering the BLE link when RF conditions temporarily become marginal, especially with a peripheral that advertises very sparsely after a disconnect. DTS asked me to post this question here for review.

I am developing a watch-only bedside clock for an Apple Watch running watchOS 27.0.1. The user needs to remove the watch in hot weather and still see the time without having a charger available. The requirements are: wrist detection remains enabled; the watch is off wrist and unplugged; the app is opened manually on the watch; the clock remains visible without periodic touches or any Mac/developer connection. Covering the screen should turn it off. The UI contains only the time, date, and battery level. It does not need protected data, HealthKit access, or programmatic unlocking. Independent physical testing still ends in the app transitioning to the background and the display turning off. Always On configuration and background runtime are not sufficient in the tested off-wrist state. Experimental idle-display requests either have no visible effect or extend the visible period to approximately 60 seconds. Updating the native scene's requested idle duration every 20 seconds does not renew the observed display deadline, despite the local readback showing the requested values. Is there a supported public API or system-owned presentation surface that can keep a nonsensitive clock visible in this situation while preserving wrist detection and authentication? If this requires an approved entitlement or a platform capability, is one available to third-party developers for this use case? Please distinguish keeping the process alive, retaining the frontmost app, and keeping the physical display visible after removal from the wrist. I have not claimed additional entitlements or changed the watch's authentication settings. I would appreciate clarification of the supported platform boundary before undertaking further device experiments.

Hi there, I'm planning to develop a simple underwater compass app for Apple Watch Ultra 2, intended for recreational scuba diving down to 40 meters. The app itself does not need depth or pressure measurements beyond 6 meters. Its primary function is compass navigation using heading data. During a dive, however, I would like the app to: remain frontmost and visible throughout the dive; use Water Lock; use an underwater-depth WKExtendedRuntimeSession; continue receiving compass heading updates; allow interaction through physical controls such as the Digital Crown and Action Button; remain operational below 6 meters, potentially down to 40 meters. I understand that the Shallow Depth and Pressure capability limits CMWaterSubmersionManager depth/pressure data to approximately 6 meters, while access to depth/pressure data down to 40 meters requires the full Submerged Depth and Pressure entitlement. My question is: If my app does not require depth/pressure measurements beyond 6 meters, is the full Submerged Depth and Pressure entitlement still required simply to keep the underwater extended runtime session, UI, compass heading updates, and physical-control interaction working below 6 meters? In other words, does the 6-meter entitlement limit apply only to depth/pressure data, or does it also limit the ability of an underwater compass app to remain operational during a scuba dive below 6 meters? Target hardware: Apple Watch Ultra 2. Thanks in advance!

I have an iPhone 14 running iOS 16.1 and my series 5 watch running watchOS 9.1. I was able to turn on Developer Mode on the phone by going to Settings--> Privacy & Security --> Developer Mode. On the watch however (I'm doing this directly on the watch and not on the watch app on the phone) once I'm in Privacy & Security, there is no option to select Developer Mode. How do I get my watch in Developer Mode in order to get a successful build in xCode?

Apple Watch Ultra 2, watchOS 27.0, Xcode 27. I use CLLocationManager.startUpdatingHeading(), headingFilter=1 and CLHeading.magneticHeading directly, with no offset or GPS course. During surfing, my app and Apple Compass both showed an apparent error of about 180 degrees. The iPhone was not nearby or connected. Later, outside water, readings returned to normal. An analog compass on the opposite arm differed by about 30 degrees initially, then agreed. All saved Int(headingAccuracy) values were 89; it still displays 89 while the heading is correct. Raw fractional values were not saved. Is this an expected or sentinel value on watchOS? What calibration and diagnostics are recommended for the intermittent reversal? The app also uses an underwater-depth extended runtime session; its errors have not been linked to the heading issue.

Hi everyone, I am developing an iOS companion app with an integrated watchOS component (a golf swing tracking tool using CoreMotion). I have run into an issue where the watchOS app gets stuck indefinitely in the "Installing..." state and never finishes installing on the physical Apple Watch. Environment (All on latest public releases): Xcode Version: Latest release (Xcode 18.x) macOS Version: Latest release (macOS Sequoia / latest version) iOS Version: Latest release (iOS 20.x) watchOS Version: Latest release (watchOS 13.x on Apple Watch Ultra 2) Deployment Target: Matched to latest minimum deployments Signing: "Automatically manage signing" enabled with an active Apple Developer Program account Steps to Reproduce: Connect the iPhone to the Mac via a physical cable. Select the iOS target in Xcode and successfully run/install the companion app onto the iPhone. Launch the stock Watch app on the paired iPhone. Scroll down to the "Available Apps" section, locate the development app, and tap "Install". The circular progress indicator starts spinning with the status "Installing...", but it remains in this state indefinitely (waited over 2 hours) without ever completing, timing out, or surfacing an error alert on either the iPhone or the Apple Watch. Troubleshooting Already Verified: Bundle ID Hierarchy: iOS App: com.company.appname Watch App: com.company.appname.watchkitapp Both targets share the exact same Development Team, signing certificate, and provisioning profiles. Developer Mode: Explicitly enabled and rebooted on the Apple Watch (Settings -> Privacy & Security -> Developer Mode). Also verified as enabled on the host iPhone. Connectivity & Cache: Cleared Xcode DerivedData (rm -rf ~/Library/Developer/Xcode/DerivedData). Performed hard reboots on both the iPhone and the Apple Watch to terminate any hung background sync daemons (installd / CoreDevice). Ensured both devices and the Mac are on the same Wi-Fi network with Bluetooth turned on. Questions: Under the current CoreDevice architecture, is installing local debug builds via the iPhone's stock Watch app still supported, or does it silently fail because the physical Apple Watch's UDID is not directly provisioned during an iOS-only build? Which subsystem in macOS Console.app (e.g., com.apple.dt.CoreDevice, com.apple.StreamingExtractor, or installd) is best for tracking the exact error/timeout code when the watch installation hangs? What is the currently recommended workflow to deploy and debug a paired watchOS target directly onto physical hardware? Any insights from the team or community would be greatly appreciated!

When playing TTS on a watchOS 27 device while AirPods or a Bluetooth headset are connected to both the Apple Watch and the iPhone: Playback begins by calling the setActive function of AVAudioSession. A successful response is received, but... ...AVAudioSession.currentRoute.outputs lists only the built-in speaker, with no entry for the Bluetooth headset or earphones. After a brief delay, an AVAudioSession.routeChangeNotification is received, and playback then switches to the AirPods. If TTS is stopped and playback is attempted again: Playback frequently fails. In this state, AVAudioSession.currentRoute.outputs still shows no Bluetooth headset or earphones. However, checking the Bluetooth settings on the Apple Watch confirms that the AirPods or Bluetooth headset are properly connected. If the app is restarted—or if you exit and re-enter the TTS playback screen—the first attempt succeeds (albeit with a delay), but subsequent attempts after stopping fail. Sometimes, playback fails right from the start. Even in this case, the AirPods remain properly connected. The issue is resolved if the AirPods are disconnected from the iPhone and connected solely to the Apple Watch. When connected only to the watch, AVAudioSession.currentRoute.outputs correctly includes the Bluetooth headset or earphones from the start, and playback issues do not occur when repeatedly stopping and restarting. Playback worked fine with simultaneous Bluetooth connections up to watchOS 26, but a strange issue has started occurring since watchOS 27. We suspect this is a bug or error introduced in watchOS 27; could you please fix it? The same issue persists even after the recent update to version 27.0.1. Alternatively, please let us know if there is a way to resolve this within the app itself. It seems impossible to fix this in the current code because there is no way to programmatically trigger a popup on the Apple Watch that forces the selection of a currently connected Bluetooth headset or AirPods. Also, it does not appear to be an issue with the TTS API.