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

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?

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 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.

When a text field on Apple Watch is filled through the iPhone's remote keyboard, text that I PASTE into the iPhone field is displayed correctly on the iPhone but arrives EMPTY on the watch. Typing the same text character by character works fine. This happens in both secure (password) fields and regular text fields, so it doesn't look like a password-field restriction. Steps to reproduce On the watch, open a text field (I tested a password field and a regular one). Open the keyboard on the iPhone when prompted. Copy a short test string (e.g. "test12345") from another app. Paste it into the iPhone field. The iPhone shows the text. Confirm on the watch. Expected: the watch receives the pasted text. Actual: the watch field receives empty input. What I tried Typing the string by hand: arrives correctly. Pasting in a secure field: arrives empty. Pasting in a regular field: arrives empty. Environment iPhone 15 Pro Max, iOS 27.0 [confirm current version] Apple Watch Ultra 2, watchOS 27.2 (24S5091f) MacBook Pro (M1), macOS 27.2 Has anyone else seen this? Any workaround other than typing the text manually would be appreciated.

I'm blocked trying to run/debug an app on a physical Apple Watch. The iPhone connects to Xcode perfectly over USB and is fully trusted, but the paired Watch never shows up in Xcode, and because of that the Developer Mode toggle never appears on the watch itself. Environment Mac: MacOS 26.4 Xcode: 26.5 iPhone: iPhone 17, iOS 26.4 — connected to Mac via USB, trusted Apple Watch: Ultra 3, watchOS 26.3 Developer Mode: enabled on iPhone Watch is paired and working normally in the iPhone Watch app What happens In Xcode → Window → Devices and Simulators, only the iPhone ("Brian") shows under Connected, with its installed apps listed correctly. The paired Apple Watch does not appear under it or as a separate entry. On the watch, Settings → Privacy & Security has no Developer Mode item. I understand this only surfaces after Xcode successfully connects to the watch, so I believe the missing Xcode connection is the root cause. When I first connected the iPhone via cable, a Trust prompt did appear on the watch and I accepted it. What I've already tried Enabled Developer Mode on iPhone (toggled off/on, with restarts) Connected iPhone via USB and confirmed Trust on both iPhone and watch Restarted Mac, iPhone, and watch multiple times Confirmed Bluetooth and Wi-Fi are on across all three devices Kept the watch unlocked and on my wrist, close to the iPhone and Mac Despite this, the watch never appears in Xcode and the Developer Mode toggle never surfaces on watchOS. Questions Is this the known Xcode 26 / watchOS 26 tunneling/discovery regression, or is something else going on in my setup? Is there an Apple-supported way to force Xcode to re-discover a paired watch without unpairing it from the iPhone? Has any specific combination of macOS / Xcode / watchOS versions reliably resolved this for anyone? Any guidance appreciated. Happy to file a Feedback Assistant report and share the ID if useful.

While testing the watchOS 27 beta, I noticed that the standalone Walkie-Talkie app has been removed from the system. Walkie-Talkie has always been a great, lightweight way to stay connected. Much like Digital Touch, it’s one of those quick, low-friction features that makes the watch feel uniquely personal for communication throughout the day. I am really hoping its absence is just a temporary beta omission rather than a permanent retirement of the feature. I have already submitted a request via Feedback Assistant asking the engineering team to consider keeping it in the final release. If you also rely on this app for quick wrist-to-wrist updates, I highly recommend submitting your own feedback ticket to let the team know there is still an active user base for it. (FB23040695) Has anyone else ran into this or found an official note from Apple regarding its removal in the release notes? Hopefully, we will see it return before the public release this fall. Over and out!

New faces I added in the iPhone Watch app showed up in My Faces but didn't reach my Apple Watch. Restarting both devices didn't help. The iPhone's logs showed the watch-face library was stuck in an automatic "reset sync" (not the Reset Sync Data button). With 65 watch apps installed, the reset was too big, hit the limit of 1000 messages per 5 minutes and failed, so new faces queued up behind it. One face took almost three hours to reach the watch. What worked for a while was removing the 7 watch apps with the most complications (I also pressed Reset Sync Data, so I'm not sure which did it). The reset dropped from 1946 to 927 messages and went through, and the stuck faces showed up the next time I added a face. About 90 minutes later a 939-message reset failed again, just over the limit counting the ~65 color-sync messages. To see if you're affected, stream your iPhone in Console.app on a Mac, add a face, and search for "requesting reset sync". I also filed FB25000090 because two queued Photos faces lost their photos when the reset went through. If you see it too, please file with sysdiagnoses from both devices (developer.apple.com/bug-reporting/profiles-and-logs) and mention FB25000073. iPhone 18 Pro on iOS 27.2 beta (24B5089g), Apple Watch Ultra 3 on watchOS 27.2 beta (24S5091f). Same on the public 27.0 release.

Filed as FB24619522 — sysdiagnoses from both devices and the live logs are attached to the report. We ship WidgetKit complications, and on the watchOS 27 betas (24R5360a, paired with iOS 27 24A5430a) they die every time the app gets updated while they're on the active face. Within seconds they turn into empty placeholders and never come back on their own — opening the app, switching faces or reloading timelines from the app does nothing. The watch logs show the extension being killed during the install (normal), and after that watchOS simply can't launch the new copy any more: runningboardd: <OSLaunchdJob | handle=…>: start succeeded, info=spawn failed, error=111: Invalid or missing Program/ProgramArguments chronod(ChronoKit): Reload failed; 0 retries remaining: … "Unknown extension process" Only two things fix it, and both restart chronod: rebooting the watch, or switching the watch language and back (iPhone › Watch app › General › Language & Region, then give it a couple of minutes). Our second extension in the same bundle, which wasn't running during the install, came back fine — so this looks like an OS bug rather than something we can work around in code. iOS 27 widgets seem to have the same problem (this thread, and iPhone in Canada wrote it up on beta 4), and someone posted the identical log lines back in March. FB24619522 — the full story, both sysdiagnoses and the live logs are in the Feedback.

Xcode 27.0, watchOS 27.2, macOS 27.2. Re-pairing an Apple Watch Ultra 2 via Device Hub (File ▸ Pair Nearby Device…) completes successfully — remotepairingd logs setupManualPairing succeeded — but the watch never reconnects afterward: no verifyManualPairing, no _remotepairing._tcp Bonjour advertisement, and CoreDevice never creates a device record for it. devicectl shows the watch as unavailable, then it disappears from the list entirely. Compare: pairing an iPhone the same way also closes the setup channel within ~40 ms, but the iPhone reconnects ~1.3 s later via verifyManualPairing and becomes available. The watch never does. Interesting finding: if the Mac's pairing listener is kept open past the point where Device Hub's sheet would normally close it, the watch does come back — but it requests a brand-new pair-setup instead of verifying the one it just completed. It loops: setup → close → setup. Already tried without success: restarting the watch/iPhone, Developer Mode off/on, Bluetooth on/off, Wi-Fi toggles, iPhone on USB, restarting CoreDeviceService and remotepairingd, Reset Location & Privacy on the iPhone, updating watchOS (27.0 → 27.2, same behavior). Full write-up with sanitized logs, timeline and everything tried: https://github.com/kisnner26/watchos27-pairing-bug Filed as Feedback Assistant FB24924229. If anyone else hits this exact symptom (pairing succeeds, watch never reconnects — different from the PIN never appearing, or the watch never showing up at all, which are other variants reported elsewhere), please share your report ID here so Apple can link them.

Hello Apple, please bring back a feature called: “Walkie-Talkie”, To WatchOS27. That feature is convenient, it allows close family members and friends to communicate in a really fun way. Sincerely, Beny74