Just sharing my experience: I have two apps. My more popular app has been waiting for review since July 24, and I've been looking at the forums because it's frustrating waiting so long. I submitted an update for my other (less popular) app yesterday and it was reviewed in under 24 hours. I didn't notice any differences in review time after answering the social media questions, so I don't think that's related. It's all a black box to me, though. I've contacted support, but it hasn't been long since I contacted them and I haven't heard back yet. I've been tempted to request an expedited review, since that's always worked well in the past, but expedited reviews are supposed to be for critical fixes or extenuating circumstances.

Same here. Very frustrating.

Just in case anyone else runs into this and finds this post, search results are now going to the correct tab automatically. Not sure if someone magically happened to see my post and updated anything in the Mac App Store, or if it just took a while to update. Search results started going to the right tab automatically about 2 weeks after the initial release of my app.

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)