As of the latest builds of both iOS 16.6 and iOS 17.0, playing albums from a users library using ApplicationMusicPlayer plays the songs on that album out of order. This is a dealbreaker for my app, and I’ve had to revert back to the Media Player framework for reliable behavior. If I fetch an album from a MusicLibraryRequest and load it into the queue using the API introduced in 16.4, init(album:startingAt:)., it starts at track 1 but then plays the rest of the tracks in random order. This happens whether skipping tracks or letting them play through. The shuffleMode of the player is .off. The issue does not occur with albums fetched from the Apple Music catalog and loaded using that same API, nor does it occur for MPMediaItemCollections loaded into an applicationQueuePlayer via a queue descriptor. I've submitted this issue as FB12495051 and provided a sysdiagnose. Please let me know if I can provide any other information.

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!

As the summer continues, I have been diving deeper and deeper into MusicKit, largely with great results. A few issues have arisen that I've outlined here, feedbacks already filed and numbers included here. All of this happens on the lasted developer beta and latest Xcode beta. Thanks! FB10967343 - Setting the queue with library and non-library items at the same time doesn't work correctly In my app, I am working on a feature that lets a user shuffle songs from a collection of albums that may or may not be in their library. However, I’ve discovered an issue where the queue does not seem to work correctly when mixing these types. I’ve attempted to load ApplicationMusicPlayer by creating a Queue and to load applicationQueuePlayer using a MPMusicPlayerPlayParametersQueueDescriptor, but the same issue occurs each time. The queue is able to play songs from the same source, but if it’s been playing a library song and tries to move to a non-library song, the queue stops.  The first thing I do is pick random songs from each album, using a MusicLibraryRequest or a MusicCatalogResourceRequest as appropriate, then taking a randomElement() from the ensuing MusicItemCollection for the album.  I append each track to an array, which I then cast to MusicItemCollection so I’ve now got a MusicItemCollection consisting of the tracks I want. If I’m in MusicKit land, I simply set the queue as follows:  player.queue = ApplicationMusicPlayer.Queue(for: tracks) It takes a bit more doing in MediaPlayer, but in theory this should also work, right?    do {         let paramObjects = tracks.compactMap {             $0.playParameters         }         let params = try paramObjects.map({try JSONEncoder().encode($0)}) let dicts = try params.compactMap {               try JSONSerialization.jsonObject(with: $0, options: []) as? [String:Any]           }           let finalParams = dicts.compactMap {                 MPMusicPlayerPlayParameters(dictionary: $0)             } let descriptor = MPMusicPlayerPlayParametersQueueDescriptor(playParametersQueue: finalParams) mediaPlayer.setQueue(with: descriptor) } catch { print(error) } In either case, the following issue occurs: say that I end up with a queue made up of one library song, then one non-library song. The player will play just the first song, then it acts as if the queue has ended. Say that it has two non-library songs, then one library song. Just the two non-library songs play. Indeed, printing queue.entries shows just the number of items that were from the same source type. FB10967076 - Publishing changes from background thread error when inserting queue items When using the .insert method on ApplicationMusicPlayer.Queue on the last iOS 16 and Xcode betas, it returns a “Publishing changes from background thread” error even though the function I’m doing in is marked as a @MainActor and the stacktace indicates it was on the main thread. FB10967277 - song.with([.albums], preferredSource: .library) generates thousands of lines of EntityQueries in the console I’ve noticed that when using the preferredSource: .library when requesting additional properties on a library item creates ~6,000 of “EntityQuery” entries in the console, all in the span of a second. This doesn’t seem to be leading to any major performance issues, but it sure seems like something isn't right. let request = MusicLibraryRequest<Song>.init() do { let response = try await request.response() guard let song = response.items.first else { return } let songWithAlbums = try await song.with([.albums], preferredSource: .library) } catch { print(error) } generates the following output (except... 6,000 of them) 2022-07-31 13:02:07.729003-0400 MusicKitFutzing[9405:2192606] [EntityQuery] Finished fetching results in 0s 2022-07-31 13:02:07.729047-0400 MusicKitFutzing[9405:2192605] [EntityQuery] Finished executing query in 0.00100017s 2022-07-31 13:02:07.729202-0400 MusicKitFutzing[9405:2192611] [EntityQuery] Finished executing query in 0s 2022-07-31 13:02:07.729240-0400 MusicKitFutzing[9405:2192605] [EntityQuery] Finished fetching results in 0s

I'd really like to be able to show List row swipe actions with text and an image, like in Mail.app: In my app, using the .swipeActions modifier on a list row, I have been unable to display both text and an image. It just displays the image. Here is my code: .swipeActions(edge: .leading, allowsFullSwipe: true) { Button { Task { await albumProvider.treatGridAsQueue(album: album) } } label: { Label("Play", systemImage: "play.fill") } Button { AlbumContextHandler.shared.handleTag(albumObject: album, session: nil, presentedSheet: $albumProvider.sheetToPresent) } label: { Label("Tag", systemImage: "tag.fill") { } } I have also tried various initializers on Button, including init(_:systemImage:action:), but none of them have worked. The strange thing is that very occasionally just the top row of a List will display the title and label the first time the swipe actions are displayed. Showing them a second time will just show the icons, as in my screenshot. I've also played around with .buttonStyles but haven't found those to make a difference. Any ideas?

I'm experiencing this issue on Sonoma beta 7 and Xcode 15 beta 8: FB13094612 -- MusicLibraryRequests are way slower on macOS than iOS The following code has massive speed differences on macOS than iOS, with macOS taking 3-7 seconds for each request and iOS taking 0.1 seconds or less. let start = Date() var artistAlbumRequest = MusicLibraryRequest<Album>.init() artistAlbumRequest.filter(matching: \.artistName, equalTo: "Ratboys") print("Searching artist Ratboys") let artistAlbums = try! await artistAlbumRequest.response() let name = artistAlbums.items.first!.title let id = artistAlbums.items.first!.id let end = Date() print("It took \(end.timeIntervalSince1970 - start.timeIntervalSince1970) to complete the artist request. \(artistAlbums.items.count) returned") print(artistAlbums.items) let start2 = Date() print("Searching by title: \(name)") var albumNameRequest = MusicLibraryRequest<Album>.init() albumNameRequest.filter(matching: \.title, equalTo: name) let nameAlbum = try! await albumNameRequest.response() let end2 = Date() print("It took \(end2.timeIntervalSince1970 - start2.timeIntervalSince1970) to complete this request") print(nameAlbum.items) print("Searching by ID") let start3 = Date() var albumIDRequest = MusicLibraryRequest<Album>.init() albumIDRequest.filter(matching: \.id, equalTo: id) let idalbum = try! await albumIDRequest.response() let end3 = Date() print("It took \(end3.timeIntervalSince1970 - start3.timeIntervalSince1970) to complete this request") print(idalbum.items) Awaiting the three requests takes 0.085, 0.019, and 0.102 seconds respectively on iOS. However, they take 7.10, 0.1, and 3.3 seconds on macOS. The second one only returns so quickly because of a bug where matching on title returns no results (see FB13094588) This makes it very difficult to provide a good experience when starting music playback, because it takes several seconds between the user selecting an album and it starting.