I got feedback in a WWDC25 accessibility lab that a link was being read by VoiceOver as both a link and a button. I was surprised to discover that this seems to be the the default behavior. I'm also wondering if this is intentional or a bug.

No response to this one so I filed FB16418331.

I'm wondering the same thing myself. I have two ForEach inside of a ViewThatFits and the code is working great when I build it locally. However, when I made a TestFlight build it was an instant crash at launch on the very same device. The crash report says that it is SizeFittingState.applyChildren(selectLast:to:) that had the problem.

FYI, the amounts reported for the snowfall event in the USA this week were much more reasonable and close to what actually happened. The issue might have been addressed.

Here's an example: precipitation: , precipitationChance: 0.0, precipitationAmount: 0.0 mm, snowfallAmount: 3.1868364810943604 mm I can't post the full WeatherKit output for the hour because it's getting flagged for sensitive language!?

Bumping this thread again because there is still an issue with trying to report snowfall for an hour. Before we were only getting back the liquid precipitation for an hour even though the day would report the snowfall amount. Now with iOS 18 we have snowfall for the hour but sometimes when the day is far away (8 days from what I've noticed) there is another issue. In November I opened FB15655811 because I was sometimes seeing an issue for an hour where WeatherKit was saying the precipitation was .none and that there was 0% chance and 0 liquid precipitation. But the snowfallAmount would be a small amount such as 0.01mm. I got this reply: There is 0% chance of any amount of precipitation, therefore a 0% chance that 0.01mm will fall. None is correct. I immediately responded with this but never heard anything back: Thank you for responding, but the precipitation being .none is not why I opened this feedback. It’s because of the snowfall amount. Precipitation can be .rain, .snow, etc. A precipitation of .none indicates there is no precipitation (including snow). A precipitation chance of 0.0 indicates there is no precipitation (including snow). Yet WeatherKit returned a non-zero snowfall amount in this scenario. For such a tiny snowfall amount it this discrepancy seems like it could be overlooked. But now I can show it happening for snow amounts such as 3.2mm (0.13"). I also updated the feedback.

I finally have an understanding of what is happening here. Credit where credit is due because ChatGPT put me on the right path to fix this. It said to check in .task if any of my Object's properties were being changed, EVEN WITH THE SAME VALUE. Previously I had some computed properties that were being called too much so I compute them in a few places manually, including .task/.onAppear. I tried adding seatbelts around those assignments to do nothing if the values weren't changing. After doing that the loop is gone. I'm not quite understanding why this code was fine in iOS 17 but goes off the rails in iOS 18. Best guesses: Assigning a Published property the same value in iOS 17 does NOT trigger a View update but with iOS 18 it does? The order/sequence/etc of .task/.onAppear changed and it made this shortcoming of my app apparent. This whole summer I thought my problem was related to the "double push" to the NavigationStack that was happening if your NavigationPath was in an Observable or ObservedObject. (FB14270042) When I moved my NavigationPath to its own class and printChanges STILL reported that it thought my original object was changing constantly I realized something else was happening.

I've made multiple design changes that I hoped would solve this problem but I still have it. My app actually no longer has a tabs. I also moved the array used for navigation from my ObservableObject to its own dedicated Observable. The problem still happens relatively the same. If I navigate to my Settings View (which used to be a separate tab) and then navigate into another View the infinite loops starts and won't stop. With the iPad simulator (and my iPad) I can still do a little with the app, although it is very slow. With the iPhone simulator the CPU of the simulator goes to over 100% and locks up. I did get this tip: "A workaround that I’ve seen for some examples is to make the view being pushed Equatable, (comforming properly to the protocol) and then do .equatable() in the destination." Unfortunately that does not seem to fix the problem in my experiments. printChanges will show that it thinks that my ObservableObject is continuing to change: StartingView: @self, _weatherData changed. I'm becoming gravely concerned considering how close to Sept 9 we are. It's greatly affecting my ability to test my app and I don't feel like I could release it in this state.

I think I have a way to address this. I changed the accessibilityLabel to be "Favorite Button" and added accessibilityValue with the current value. After that VoiceOver is no longer always saying the toggle is off. Button { showFavActions() } label: { Image(systemName: SFSymbolShortcut.star.rawValue) .symbolVariant(weatherData.currentlyFavIndex == nil ? .none : .fill) } .buttonStyle(.plain) .accessibilityLabel(Text("Favorite Button")) .accessibilityHint(Text(weatherData.currentlyFavIndex == nil ? "Add to favorites." : "Remove from favorites.")) .accessibilityInputLabels(["Favorite"]) .accessibilityAddTraits(.isToggle) // iOS 17 .accessibilityValue(weatherData.currentlyFavIndex == nil ? "Not a favorite location." : "Favorite location.")

No change with Version 16.0 beta 6 (16A5230g).

No change with Version 16.0 beta 6 (16A5230g).

No change with Version 16.0 beta 5 (16A5221g).

No change with Version 16.0 beta 5 (16A5221g).

My celebration was short lived because I found another situation that triggers the same endless loop behavior. I have a @Published property that controls what sheet is launched. Populating it causes this same loop. And this time removing @Published makes the sheet logic stop working. So I don't have a workaround any more.

I figured out how to make the endless loop stop. So I now have workarounds to both scenarios. I am able to recreate the "double push" after navigation behavior in a sample project. I am able to stop it by removing @Published from my property that holds a navigation path in my @ObservableObject. Also, adding @ObservationIgnored to a similar property in an @Observable apparently works also. I am NOT able to recreate the endless calling of .onAppear/.task in a sample project. I am able to stop it in my app by removing @Published from my property that holds the selected tab in my @ObservableObject. This is code that is functioning without an issue with iOS 17. I only encountered these problems when building for iOS 18.