Here is the solution on XCode Version 14.3.1. Go to Product->Destination->Manage Run Destinations... From this page you can customise 'Show run destination' section. Just change the ones you don't want to simulate at as 'never' and change the preferable one as 'always'. For your case, under the device section find your phone (it is already selected), change Show run destination as never and go to simulators find your desirable model and change its show run destination as always.

Checked! I faced with the same issue and couldn't find any quick solution so I tried @Boonyawat method by marking "Reviewed" every locale in my String Catalog for the base language "English". It just worked! Although I still see "0 File Localised" for both my base "English" and secondary "Turkish" languages, App Store,now, correctly lists my supported languages. That was the only thing I've done to solve the issue so it's fare to say that you can also try I also double checked that Build Metadata on the Test Flight correctly shows the supported language.

The solution that worked for me was to switch to a different web browser. I usually use Safari, but I encountered the same error with it. None of the solutions I tried worked for me. So, I decided to try logging in to App Store Connect using Chrome, and it worked. I hope this helps.

For those who are curious about the answer, I use WeatherKit data on my MacOS app to display current weather information in one of my views. It’s not a standalone weather app; it’s more of an additional feature I’ve added. I’ve included the trademark and the legal link in the settings view, not in the view that displays weather data, and it’s been approved.

Thank you both for the feedback. I filed a bug report as suggested and the number is here "FB19908171". To clarify my motivation for asking whether this is intentional or a bug: I'm maintaining AppleScript-based tools that have relied on current track for years, and this change significantly impacts their functionality. Understanding Apple's intent helps me decide whether to: Implement workarounds and keep investing in this approach (if it's a bug likely to be fixed) Pivot to alternative solutions if it's a deliberate deprecation The try block workaround is helpful for graceful degradation, but it doesn't solve the core issue - there's currently no reliable way to get information about non-library tracks that are actively playing through AppleScript. The inconsistent behavior (works in "Songs" tab but not others, works for library tracks but not Apple Music streams) really does suggest this is unintentional rather than a deliberate API change. If Apple intended to restrict current track to library-only content, I'd expect consistent behavior across all playback contexts. I'll test this in upcoming betas and keep the feedback updated.