I've finally been spending some time getting to know the MusicKit API, which is really nicely designed and will let me get rid of a ton of less efficient code as I start implementing it. I'm used to hitting the /artists/{id}/view/latest-release API endpoint via a URLSession data task to return an artist's most recent release, if available. I see that it seems to be possible to return that information in a MusicCatalogResourceRequest, but the following code returns nil for me: var request = MusicCatalogResourceRequest<Artist>.init(matching: \.id, equalTo: "35719") request.properties = [.latestRelease]          do {   let response = try await request.response() print(response.items.first?.latestRelease)   } catch { print(error.localizedDescription) } In the code above, I've hardcoded the ID for an artist, but I've tried this in a for loop and it returns nil for every artist in my library. (By contrast, when adding .fullAlbums or .albums to the properties array, it does fetch that relationship). When I construct a MusicDataRequest against the endpoint I'm used to hitting, it correctly returns the latest release. This is the code I'm using for that: let request = MusicDataRequest(urlRequest: URLRequest(url: URL(string: "https://api.music.apple.com/v1/catalog/us/artists/\(artist)/view/latest-release")!)) do { let response = try await request.response() let decoded = try JSONDecoder().decode(AlbumReponse.self, from: response.data)             print(decoded) } catch { print("error getting latest release: \(error.localizedDescription)")         } Is this a bug, or am I doing something incorrect? I didn't file a Feedback yet in case this was an error on my end, but if it's a bug I'm happy to put one in. Thanks!

As the title asks, is it possible to support SharePlay using the applicationQueuePlayer in the Media Player framework? It seems not to be possible since there is no AVPlaybackCoordinator available like there is for AVPlayer. Is that correct? It would be nice to be able to support this in my application if possible. Thanks!

My app uses the Media Player framework to play music and has the Audio background mode. When a user pauses the music and backgrounds the app (or if the app is already in the background when they pause), the system does not kill the app as long as it has the active AVAudioSession. This means that as long as a user doesn't start playback from another audio app, mine is available in Control Center for a quick resume. I recently implemented the UIBackgroundTask API (specifically UIApplication.shared.beginBackgroundTask/endBackgroundTask) to run a 5-20 second server communication task when the app is paused while in the background. Now, iOS kills my app at the conclusion of that task, despite it still having the active audio session. It is no longer in Control Center, and needs to be launched fresh. Is there anything I can do to prevent the system from killing my app at the conclusion of the background task? I'm starting to get complaints from users that they're having to relaunch the app after every time they pause for more than a few seconds. Thanks!

Hello, I have an app that uses the MediaPlayer framework (applicationQueuePlayer specifically) and since the introduction of iOS 14.6 and Lossless audio, some users have been reporting that sometimes they cannot play a song past 15 seconds without playback either pausing or the app making a screeching noise. As far as I knew, this was supposed to be fixed in 14.7, but users running 14.7.1 are reporting it to me whether Lossless is on or off. The problem seems to be intermittent -- there for one user one day and gone the next, though sometimes it sticks around. I am pretty much never able to reproduce it for myself. My code to load and play the player is pretty simple and has not changed since well before this issue started cropping up. I run setQueue and set the queue with either a descriptor of storeIDs for Apple Music Items or an MPMediaItemCollection for library items, then call Play. Is there anything I can do about this issue? Are you guys still working on this server side? I need to continue supporting users on older OSes so I am not yet able to use the new MusicKit for Swift player. I don't know if it's fixed there or not. Thanks! (Tagging in @JoeKun)

I have been spending the last several weeks implementing NSPersistentCloudKitContainer in my app, and it is most of the way there. Unfortunately, I keep running into an issue where after several days of successful syncing between devices, each device begins to crash after about a minute of use, repeatedly. The crash report points to a SQL thread doing things with the CoreData and CloudKit frameworks — none of my code whatsoever. It is the typical “CPU:  48 seconds cpu time over 58 seconds (82% cpu average), exceeding limit of 80% cpu over 60 seconds” issue. If I run the devices hooked up to Xcode and debug, I see the thread spin up and the log shows it chugging through changed CKRecords it needs to import, just like normal. If I leave the devices hooked up to Xcode, they eventually make it through this huge job and the devices become usable again. Once one device is in this state, the problem also occurs on new devices trying to download from the cloud for the first time. I’ve attached a screenshot of the stacktrace of that thread in Instruments. I haven’t had any luck finding other people mentioning the system killing their app during a sync, so I’m kind of at a loss for what to do. It seems like the issue is occurring in a job that the NSPersistentCloudKitContainer is managing on my behalf and I haven’t been able to figure out a way to configure a timeout or anything.   Has anyone experienced this? I’m not sure what to do if the chunks that NSPersistentCloudKitContainer breaks up the import into are too large for the device to work through before the system kills the app. I’d appreciate any ideas or insights. Please let me know if any other information would be helpful. Thanks!