This feel this is similar to what is happening to me. Submitted a brand new app and got a rejection based on a design issue. I immediately responded back that the app was already doing what they wanted and it got approved. Later I realized that all of my IAPs and subs were rejected in a "developer action needed" state. It gave me no indication of what action I needed to take so I assumed that they were put in that state because of my design rejection. I made minor changes to the wording so that it would let me submit them again. I resubmitted the IAP and subs. My IAPs got approved almost immediately. I did have one submission problem. For the subscription "App Store Localization" I kept getting an error when I tried to submit them. It wasn't until hours later that I was able to submit them without an error message. My subs are "in review" and my subscription "App Store Localization" are "waiting for review" for days. I don't know if one (or any) of these is happening: It's a problem with App Store Connect that Apple needs to look at It's on hold for a (USA) holiday weekend The subs are really still being reviewed. I just have a 3 month sub and a 1 year sub. Nothing fancy. Status App - approved consumable IAP - approved subscriptions - in review subscription "App Store Localization" - waiting for review

Filed FB12087182

I am also completely unable to retrieve a forecast in the simulator using Xcode 15 beta 1.

I'm starting to get support emails from users running the iOS 17 beta reporting that they can't retrieve weather forecasts with my app.

Had the same question and also couldn't find an answer. Try passing an empty string as the dialog. That seems to do the trick.

I'm bumping my old thread with more info. I did a deep dive into the hourly WeatherKit data that is returned. I've been using precipitationAmount to report the snow amout, but there's actually a property returned called snowfallAmount!! And it appears to contain values that are what I have been expecting for snow. WeatherKit.HourWeather(date: 2024-01-09 15:00:00 +0000, cloudCover: 0.98, cloudCoverLow: 0.0, cloudCoverMid: 0.0, cloudCoverHigh: 0.0, condition: Heavy Snow, symbolName: "cloud.snow", dewPoint: -0.44 °C, humidity: 0.96, isDaylight: true, precipitation: snow, precipitationChance: 0.61, precipitationAmount: 2.75 mm, snowfallAmount: 27.16 mm, pressure: 1018.33 mbar, pressureTrend: Falling, temperature: 0.16 °C, apparentTemperature: -4.72 °C, uvIndex: WeatherKit.UVIndex(value: 1, category: Low), visibility: 778.16 m, wind: WeatherKit.Wind(compassDirection: Southeast, direction: 127.0 °, speed: 17.97 km/h, gust: Optional(51.98 km/h))), BUT if you look at the HourWeather in SwiftUI the snowfall amount is missing. You see the precipitation, precipitationChance, and precipitationAmount that are before it in the raw data and the pressure, pressureTrend, etc that follow it. snowFall isn't in an extension, Xcode autocomplete doesn't know about it, doesn't compile, etc. Either this is a major omission or I'm completely misunderstanding something. I filed FB13521886

FYI to anyone who might reference this thread. SnowfallAmount has been added to HourWeather in iOS 18. I can now rip out my janky code to convert the liquid amount to snowfall amount. Thank you for addressing this.

I was able to recreate the double push part of the problem so I opened feedback. FB14270042

Some more context: The first time I encountered this endless loop was in this scenario: App launches and brings up default tab which I call my starting view. I found that when I switched to another tab but then went back to my first tab my .onAppear for the starting view would get called endlessly. I “fixed” this by switching the .onAppear to .task instead BUT .task ended up being called twice in this same scenario. Still not ideal but better than endless.

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.

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.

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

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

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

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