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

https://developer.apple.com/documentation/widgetkit/keeping-a-widget-up-to-date lists a number of exception including "The widget’s containing app has an active audio or navigation session." https://developer.apple.com/videos/play/wwdc2021/10048/ mentions: "However, there are a few situational exceptions that will make these reloads occur both immediately and budget-free. These are when your container app is foreground to the user or when your app is participating in a user session, like Navigation or Now Playing audio." Does an active workout session in a watchOS app count as "your app is participating in a user session", so calls to WidgetCenter.shared.reloadTimelines(ofKind:) are budget-free?

.navigationDestination(isPresented) hangs after reboot (when called within 2 minutes of reboot) in watchOS when destination view contains @Environment(.dismiss). Feedback: FB21077151 Second button hangs after reboot. Hangs in watchOS 26.0 and 26.4 on a physical device. struct ContentView: View { @State var presentView1 : Bool = false @State var presentView2 : Bool = false var body: some View { NavigationStack { VStack { Button("Show View 1") { presentView1.toggle() } Button("Show View 2") { presentView2.toggle() } } .navigationDestination(isPresented: $presentView1, destination: {TestView1()}) .navigationDestination(isPresented: $presentView2, destination: {TestView2()}) } } } struct TestView1: View { var body: some View { Text("View 1") } } struct TestView2: View { @Environment(\.dismiss) var dismiss var body: some View { Text("View 2") } }

I changed my AppleID password. Now for any app distributed via TestFlight the call to AppTransaction.shared throws "Unable to Complete Request". This only happens for this one ID, and only when distributed via TestFlight. I have tried different apps and devices, all with the same result.

Adding .chartScrollableAxes(.horizontal) to a chart prevents chartYAxisLabel from being positioned top right, over Y axis. We want the label at top right, over the Y-axis, but with chartScrollableAxes it is always top right relative to the initial chartXVisibleDomain, which puts it in the middle of the chart if chartXVisibleDomain < full x domain. import SwiftUI import Charts struct ContentView: View { @State private var numbers = (0..<100) .map { _ in Double.random(in: 0...100) } @State var visibleDomain : Int = 50 var body: some View { Chart(Array(zip(numbers.indices, numbers)), id: \.1) { index, number in LineMark( x: .value("Index", index), y: .value("Number", number) ) } .chartScrollableAxes(.horizontal) .chartXVisibleDomain(length: visibleDomain) .chartScrollPosition(initialX: 70) .chartYAxisLabel(position: .topTrailing, alignment: .center) { /* We want the label at top right, over the Y-axis, but with chartScrollableAxes it is always top right relative to the initial chartXVisibleDomain, which puts it in the middle of the chart if chartXVisibleDomain < full x domain */ Text("units") .foregroundStyle(.red) .fontWeight(.bold) } .padding() } } #Preview { ContentView() }

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?