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?