Yes, I have the same problem with an app version just built with Xcode 15.0.1. Hopefully it's a temporary problem that gets fixed quickly.

FYI, renewals now work correctly for me also in Xcode 15.0/iOS 17 simulator (while open), so looks like the bug with the simulator is fixed to me. I closed my feedback.

@Wizfinger Apple updated the feedback report I filed with a request to confirm the bug still exists on iOS 16.6. Since I think it may only happen on a simulator, I'm not sure if this is possible. I was going to wait until the release version of Xcode 15 to retest it. Not sure if anyone else has tested it on the betas/etc. However, if you're having issues with users on real users with renewals, I think you may have something else going on. I actually went ahead and deployed my Storekit 2 code to production a while back, even though the simulator behavior was concerning. I think it actually works OK on a real device with real store purchases, since I haven't had any users complain (I've had subscription purchases, renewals, and in-app purchases through the code).

This is probably a newbie type question, but is it possible to fix this in an Xcode 14 build? The extension does work well on a build in Xcode 15, but we're not supposed to submit Xcode 15 builds to the App Store currently, right (but maybe this is a bad assumption)? I have feedback from some users on my app who are already using iOS 17 and reporting the padding issue.

For what it's worth, my Feedback about this bug (FB11723508) which previously said "Potential fix identified - For a future OS update" has been changed back to "Open" so I'm not sure if it's being worked on at Apple at the moment.

Just wanted to add, I also have the same issue described above.

Update: Now that Xcode 14.3 and the simulators for 16.4 are out, I tried again. I still see the same issue. I updated my Feedback Assistant report to Apple and attached a sysdiagnose. I think this is only happening in simulators, but it still makes me a little uneasy.

Thank you for the solution @msanchez_iz This seems to work OK until I start trying to customize the titlebar. If I start setting navigationTitle or customize the toolbar in other ways (e.g. with .toolbar) it starts ignoring the .toolbarColorScheme Not sure if I'm using the title and toolbar settings incorrectly for this, though. Are you changing the toolbar title or content in your actual app, and is the status bar still respecting .toolbarColorScheme? E.g., if I modify the example on StackOverflow slightly to the code below (without the extension you've posted in the final solution), the .toolbarColorScheme stops working as expected for me. (E.g. without Status bar style set and in light mode, the below example won't change from a dark status bar. If I remove the .navigationTitle it will set the status bar to light as expected.) Again, not sure if I'm missing something or doing something incorrectly. I'm using Xcode 14.2/iOS 16.2 to try it out. struct ContentView: View { var body: some View { NavigationStack { TestView(title: "Top", colorScheme: .light) } } } struct TestView: View { let title: String let colorScheme: ColorScheme var body: some View { ZStack { Color.mint .ignoresSafeArea() VStack { Text("Hello") NavigationLink("Push") { TestView(title: "Pushed", colorScheme: .light) } } } .navigationTitle(title) .toolbarBackground(.mint, for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) .toolbarColorScheme(colorScheme, for: .navigationBar) } }

I just wanted to add on that I have the same issue. The functions just never get called for me in a single target WKApplication Not sure if anyone happened to figure out the issue here? I can't see anything I might be missing in the documentation.

Apple responded to my feedback and said they couldn't reproduce on the latest Xcode 14.3 and iOS 16.4 seeds and to send a sysdiagnose if there's still an issue. I think that might mean it's fixed now? I might wait for the release versions of Xcode 14.3/iOS 16.4 before testing it again and sending a sysdiagnose if it still occurs -- I do think it's quite possible that this only happens on the simulator (or is fixed in the betas).

Thanks @itsyusuf I was hoping you'd figured something out. I just filed a Feedback Assistant bug. #FB11984421 I attached Apple's own sample app code to go along with the reproduction steps. I would think this should be a critical bug to fix.

Also, one other note because I saw mention of UIViewRepresentable. I'm currently using that solution in an app, actually, because the native SwiftUI maps are so limited. I get the same warning when I strip it down to just the essentials with makeUIView creating an MKMapView so it doesn't completely resolve the issue to go that route, unless I'm missing something. However, I haven't noticed any incorrect behavior (although I definitely have to handle threading in updateUIView)

Just an update for anyone reading here -- my Feedback Assistant bug report for this issue now says "Potential fix identified - For a future OS update"

I have the same issue in an app using StoreKit 2. Transaction.updates does not emit unfinished transactions after app launch like the documentation says. I have only one observer, and my code is based on the StoreKit 2 demo code from Apple. (And I have my Store class modeled on Apple's example as a @StateObject on my main SwiftUI view, just like Apple's sample.) If I let a subscription renewal come through while the app is running, Transaction.updates does emit all of the unfinished transaction updates, but it's unrealistic to expect the app to be open in production at the time a subscription renewal occurs. (Transaction.currentEntitlements does show the correct information, but it's concerning that I potentially have so many unfinished transactions.) Does anyone have any other additional info, workarounds/etc.? @itsyusuf did you happen to figure out any fixes for this issue?

OK thanks @MartinMajewski Yeah, in the example above, there's nothing actually using a binding other than $region, but a binding is required for the coordinateRegion on the Map initializer. And it's also just a plain @State property, so nothing even that fancy. Not to confuse the issue, but there are some other areas (other than with the MapKit issue above) where I've seen this same warning that make sense to me and I've eliminated the errors in my code. Here is a YouTube video that made my understanding of it a little more clear: https://www.youtube.com/watch?v=3a7tuhVpoTQ I'm going to assume for now with the MapKit example it's a bug. I just submitted it as an issue in Feedback Assistant in case that helps.