Apologies if it's a bit obvious but probably the first thing to check is that you've actually granted permission for your app to access Apple Music on your Mac. i.e. in the System Preferences app, Security & Privacy -> Privacy -> Media & Apple Music. Is your app listed there and is access enabled? Just to confirm, this call is working Ok for me on Ventura (unlike any of the newer MusicKit functions).

Am going to answer my own question here for when others hit the same issue: according to both the documentation and my direct experience, these new MusicLibrary calls are NOT supported on macOS Ventura, either natively or via Catalyst. They are only supported on iOS-derived platforms. I find it deeply concerning that new APIs are being introduced which aren’t available on Catalyst in particular. It calls into question Apple’s commitment to the platform - I’m surprised this hasn’t received more publicity.

I've just noticed the detail text for the error is: "Conformance of 'Playlist' to 'MusicLibraryRequestable' has been explicitly marked unavailable here (MusicKit.Playlist)" Is the new MusicKit functionality not yet working on Catalyst? Surely we can't have reached Beta 3 without this working?!

Hi @JoeKun. Is there any update on this issue? My app adds Apple Music tracks to playlists and is seeing a similar problem. Basically it gets an http 20x reply (indicating success) after adding tracks to a playlist but some of the tracks are not actually getting added. Seems to have started in the last couple of weeks and only impacts certain users. Am very concerned in case this is a new server api release which is being rolled-out to a few initial servers. A lot of apps depend on this endpoint and it seems completely broken at the moment for impacted users. Thanks!

Still very much broken for me. Unfortunately I think it's an intermittent problem which is letting the occasion build through and is thereby convincing people who just tried something random that they found a "fix".

Wasn't working for me but just tried it a few seconds ago and it worked. However I then tried to upload the Catalyst version of my app and it's now broken again. Seems like the service is going up & down.

It's been working fine for me for the last few months. In fact I just uploaded a new build of my catalyst app today, with the same version & build number on iOS & macOS. Incidentally I now let Xcode manage build numbers for me.

Could someone from Apple please comment on this?

This earlier thread looks to be the same as my 2nd issue. It's currently unresolved though.

Has anyone found a fix to this? I just posted a question on a couple of ASWebAuthenticationSession issues I'm seeing and just realised that one of them looks a lot like this one (apologies for the duplicate if so).

Definitely working Ok for me. This was from a few minutes ago, from TestFlight: I've uploaded lots of builds this week and haven't had a repeat of the problem.

Thanks - seems to be working for me now. I was just able to upload an iOS & macOS build which had the same build number for both (from Xcode).

This looks a bit like this problem: https://developer.apple.com/forums/thread/693838 It started yesterday.

Could someone from Apple please respond? This is really quite painful and means that the new auto-build numbering feature in Xcode 13 simply doesn't work on Catalyst apps, as far as I can see: it fails 100% of the time to generate valid build numbers. To summarise, this is how I've released an app for the last year: Increment the build number & version in my project, then check-in Archive & upload my iOS version Archive & upload my macOS version As of yesterday the process seems to be: Increment the build number & version in my project, then check-in Archive & upload my iOS version Increment the build number in my project again, then check-in again Archive & upload my macOS version Update a spreadsheet so that I can keep track of which iOS & macOS builds are equivalent I haven't started to think about what this means for labelling releases in source control or tracking issues across builds. None of this is good though. If this is intentional and there's a workaround at our end, please share it.

Just to confirm, I tried this again but this time allowed Xcode to do it's automatic build numbering thing. Same error - it seems to be completely broken. Automatic build numbering doesn't seem to be the cause, and nor does it seem to help.