I'd still like to know if it's possible to change the cursor on a MarkerAnnotation, but I was wrong in what I was saying about anchorOffset on a normal Annotation. It was my mistake on the DOMPoint numbers and my interpretation of them with my custom Annotation. That's the way I ended up accomplishing what I was trying to do.

Not sure if this is helpful, but I've also been a little concerned with the performance of MapKit JS also. I just filed a report via Feedback Assistant as Frameworks Engineer suggests above. I'm also posting this in the forums, just in case the additional feedback is helpful, and to possibly encourage anyone else who has issues with the performance to file reports via Feedback Assistant. (As an aside, I really like MapKit JS in a lot of ways, so I don't want to sound too negative!)

I know it's been a little while since this question was asked, so it's possible that you're already set. Just in case not, despite Google's documentation, it seems like it may take weeks for your app to show up in the AdMob settings page when you search. It took a little over two weeks for one I set up, and I know someone else for whom it took three weeks. After you add the App in AdMob settings, it takes a little longer for ads to show up after that.

I'd really like to know the answer to this, as well. I'm really fuzzy on a few things around ATT, and I'm certainly not an expert, but some thoughts and other questions below (and I may well be wrong about some things or missing something): For the IDFA itself, you can show non-personalized ads (the forums won't let me paste Google URLs, but you can search for how to pass consent/lack of consent to the request) and set the SKAdNetworkIdentifier (again, you should be able to search for this), and AdMob seems to work fine without accessing the IDFA and without the IDFA ATT prompt in iOS 14.5 betas. What I'm a little less clear on is whether there needs to be any sort of ATT for the tracking AdMob does without using the IDFA. The Google documentation for AdMob and iOS 14 indicates that the App Store privacy disclosure should have Location, Identifiers, Usage Data, and Diagnostics as data used to track you. It also says that data is used for tracking even without sending the IDFA. There is a setting for User Metrics in AdMob that seems to indicate that some of this data can be set to not used (but is still sent?). Does turning off User Metrics mean that the ATT doesn't need to be shown? Does it mean that the disclosure doesn't need to include anything other than identifiers? Google's documentation doesn't seem entirely helpful here, and I'm a little confused after reading some of Apple's (I also know there's at least one popular app with a couple hundred thousand reviews on the App Store that is using AdMob and only disclosing Identifiers in data being used to track you. So maybe with these settings off it's all good?) E.g., this page makes it seem like there should probably be an ATT even without using the IDFA: https://developer.apple.com/app-store/user-privacy-and-data-use/ This goes to some of the questions out there about whether Apple is really eliminated third party "analytics" also. There doesn't appear to be anything preventing the app from working without the ATT and no IDFA usage in iOS 14.5, so is this policy going to be enforced on App Review? Really not sure, and I may be misinterpreting something.

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.

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?

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"

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)

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.

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).

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.

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) } }

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.

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

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.