I'm very excited about the new MusicLibrary API, but after a couple of days of playing around with it, I have to say that I find the implementation of filtering MusicLibraryRequests a little confusing. MPMediaQuery has a fairly extensive list of predicates that can be applied, including string and persistentID comparisons for artist, album artist genre, and more. It also lets you filter on an item’s title. MusicLibraryRequests let you filter on the item’s ID, or on its MusicKit Artist and Genre relationships. To me, this seems like it adds an extra step.  With an MPMediaQuery, if I wanted to fetch every album by a given artist, I’d apply an MPMediaPropertyPredicate looking at MPMediaItemPropertyAlbumArtist and compare the string. It was also easy to change the MPMediaPredicateComparison to .contains to match more widely. If I wanted to surface albums by “Aesop Rock” or “Aesop Rock & Blockhead,” I could use that. In the MusicLibraryRequest implementation, it looks like I need to perform a MusicLibraryRequest<Artist> first in order to get the Artist objects. There’s no filter for the name property, so if I don’t have their IDs, I’ve got to use filter(text:). From there, I can take the results of that request and apply them to my MusicLibraryRequest<Album> using the filter(matching:memberOf) function.  I could use filter(text:) on the MusicLibraryRequest<Album>, but that filters across multiple properties (title and artistName?) and is less precise than defining the actual property I want to match against. I think my ideal version of the MusicLibraryRequest API would offer something like filter(matching:equalTo:) or filter(matching:contains:) that worked off of KeyPaths rather than relationships. That seems more intuitive to me. I’m not saying we need every property from every filterable MPMediaItemProperty key, but I’d love to be able to do it on title, artistName, and other common metadata. That might look something like: filter(matching: \.title, contains: “Abbey Road”) filter(matching: \.artistName, equalTo: “Between The Buried And Me”) I noticed that filter(text:) is case insensitive, which is awesome, and something I’ve wanted for a long time in MPMediaPropertyPredicate. As a bonus, it would be great if a KeyPath based filter API supported a case sensitivity flag. This is less of a problem when dealing with Apple Music catalog content, but users’ libraries are a harsh environment, and you might have an artist “Between The Buried And Me” and one called “Between the Buried and Me.” It would be great to get albums from both with something like: filter(matching: \.artistName, equalTo: “Between The Buried And Me”, caseSensitive: false)  I've submitted the above as FB10185685. I also submitted another feedback this morning regarding filter(text:) and repeating text as FB10184823. My last wishlist item for this API (for the time being!) is exposing the MPMediaItemPropertyAlbumPersistentID as an available filter attribute. I know, I know… hear me out. If you take a look at the other thread I made today, you’ll see that due to missing metadata in MusicKit, I still have some use cases where I need to be able to reference an MPMediaItem and might need to fetch its containing MPMediaItemCollection to get at other tracks on the album. It would be nice to seamlessly be able to fetch the MPMediaItemCollection or the library Album using a shared identifier, especially when it comes to being able to play the album in MusicKit’s player rather than Media Player’s.  I've submitted that list bit as FB10185789 Thanks for bearing with my walls of text today. Keep up the great work!

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!

I have been excitedly testing out MusicKit's new features to interact with a user's music library over the last couple of days. Albums and Songs are a much nicer paradigm than MPMediaItemCollection and MPMediaItem, but I'm afraid that there are some library-focused metadata options present on MPMediatem that are seemingly not currently exposed on Songs fetched from a MusicLibraryRequest that force me back into the world of MPMediaItems. A big component of my app is being able to sort and filter your library across properties like play count and date added. Am I right that these properties are not available when interacting with library Songs in MusicKit? dateAdded - The date the item was added to the library lastPlayTime - The date on which the item was last played playCount - The number of times the item has been played For as long as those properties are not available, I will need to dip back into MPMediaItems in order to continue offering important pieces of functionality in my app.  Those three are my highest priority for this area of MusicKit at this time, and are my biggest blockers on jumping into the new world as opposed to staying the old. I've submitted the above as FB10185523 While I'm at it, I also have a wishlist of some additional properties, only one of which is currently exposed on MPMediaItem. The rest of which correspond to metadata a user can set in Music.app on the desktop but have not historically been publicly exposed on MPMediaItem: isCloudItem - This is currently exposed on MPMediaItem and tells you whether an item is locally downloaded on the device. I understand that the includeOnlyDownloadedContent option can be set on a MusicLibraryRequest to return locally downloaded devices, but it would also be nice to have on a per-song basis to be able to display an indicator to the user.  startTime and stopTime - These properties correspond to the custom “start” and “stop” times a user can define for a song on the Options tab of Music.app on the desktop. These have not historically been exposed publicly. It would be nice to have access to these in order to be able to display an accurate play time if a user has customized it. sortAlbumTitle, sortAlbumArtist, sortArtist - These properties correspond to the “sort as” options a user can define for a song on the Sorting tab of Music.app on the desktop. These have not historically been exposed publicly. It would be nice to have access to these in order to display library items to a user in the order they’ve defined and expect, rather than ignore their preference.  I've submitted the above as FB10185575 Thanks!

Thanks to the MusicKit team for addressing FB12301908 and FB12301718, but I'm afraid I've discovered even more issues that make MusicLibraryRequest<Album> difficult/impossible to use on macOS. Each of these issues is occurring on Sonoma seed 7 and Xcode 15 beta 8. FB13094022 - MusicLibraryRequest crashes when no filters are applied with error about MPModelGenre The following code crashes the app when run against my library (consisting of Apple Music catalog and self-added music) on macOS or Mac Catalyst: var libraryRequest = MusicLibraryRequest<Album>.init() let albums = try! await libraryRequest.response() The error is as follows: <NSXPCConnection: 0x6000023bc460> connection to service with pid 4331 named com.apple.amp.library.framework: Exception caught during invocation of reply block to message 'performLibraryRequest:withReply:'. Exception: No identifiers for model class: MPModelGenre from source: (null) ( 0 CoreFoundation 0x000000018ebb08c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018e6a9eb4 objc_exception_throw + 60 2 Foundation 0x000000018fcf718c -[NSCalendarDate initWithCoder:] + 0 3 MediaPlayer 0x00000001be7f3e20 -[MPBaseEntityTranslator _objectForPropertySet:source:context:] + 392 4 MediaPlayer 0x00000001be7f41f8 -[MPBaseEntityTranslator _objectForRelationshipKey:propertySet:source:context:] + 296 5 MediaPlayer 0x00000001be7f4088 __63-[MPBaseEntityTranslator _objectForPropertySet:source:context:]_block_invoke_2 + 76 6 CoreFoundation 0x000000018eafe6f4 __NSDICTIONARY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 7 CoreFoundation 0x000000018eafe5bc -[__NSDictionaryI enumerateKeysAndObjectsWithOptions:usingBlock:] + 268 8 MediaPlayer 0x00000001be7f3fdc __63-[MPBaseEntityTranslator _objectForPropertySet:source:context:]_block_invoke + 436 9 MediaPlayer 0x00000001be82c5c4 -[MPModelObject initWithIdentifiers:block:] + 184 10 MediaPlayer 0x00000001be7f3d80 -[MPBaseEntityTranslator _objectForPropertySet:source:context:] + 232 11 MediaPlayer 0x00000001be7f30e0 -[MPBaseEntityTranslator objectForPropertySet:source:context:] + 32 12 MediaPlayer 0x00000001be8becbc __47-[MPModeliTunesLibraryRequestOperation execute]_block_invoke + 1032 13 iTunesLibrary 0x00000001c2de3584 iTunesLibrary + 83332 14 CoreFoundation 0x000000018eb1c144 __invoking___ + 148 15 CoreFoundation 0x000000018eb1bfbc -[NSInvocation invoke] + 428 16 Foundation 0x000000018fc06698 __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ + 16 17 Foundation 0x000000018fc04d18 -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 520 18 Foundation 0x000000018fc04674 __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_3 + 188 19 libxpc.dylib 0x000000018e788034 _xpc_connection_reply_callout + 116 20 libxpc.dylib 0x000000018e787f2c _xpc_connection_call_reply_async + 80 21 libdispatch.dylib 0x000000010534ebcc _dispatch_client_callout3 + 20 22 libdispatch.dylib 0x0000000105373e0c _dispatch_mach_msg_async_reply_invoke + 400 23 libdispatch.dylib 0x0000000105357ae8 _dispatch_lane_serial_drain + 368 24 libdispatch.dylib 0x0000000105358e00 _dispatch_lane_invoke + 468 25 libdispatch.dylib 0x000000010536877c _dispatch_root_queue_drain_deferred_wlh + 652 26 libdispatch.dylib 0x0000000105367a54 _dispatch_workloop_worker_thread + 444 27 libsystem_pthread.dylib 0x00000001050abd9c _pthread_wqthread + 288 28 libsystem_pthread.dylib 0x00000001050b3ab4 start_wqthread + 8 ) FB13094588 - MusicLibraryRequest filtered by .title, equalTo returns blank The following code returns no results on macOS and MacCatalyst but successfully returns albums on iOS: var albumNameRequest = MusicLibraryRequest<Album>.init() albumNameRequest.filter(matching: \.title, equalTo: "The Window") let nameAlbums = try! await albumNameRequest.response() It returns no results whether I'm providing a string myself, or using the .title property of an Album I've already fetched

I've submitted this as FB13628591 but I figure a forum post never hurts ;) I’ve discovered an issue with keyboard presentation when using .searchable in SwiftUI in iOS 17.4 beta 3, shown in this video (https://imgur.com/1hmM5u0) running this sample code. struct Animal: Identifiable { var id: String { return name } let name: String } struct ContentView: View { let animals: [Animal] = [.init(name: "Dog"), .init(name: "Cat"), .init(name: "Turtle")] @State var presentedAnimal: Animal? = nil @State var searchText: String = "" var body: some View { NavigationStack { List { ForEach(animals) { item in Button(item.name) { self.presentedAnimal = item } } } .sheet(item: $presentedAnimal) { item in Text(item.name) } .searchable(text: $searchText) } } } As of iOS 17.4, the behavior of the above code is that if you tap one of the list buttons to present a sheet while the keyboard is still presented, the keyboard will dismiss then represent once the sheet is presented. In the video, I tap the “Cat” button while the search keyboard is still presented. This is confusing, because the keyboard actually belongs to the presenting .searchable view, not the presented sheet. In all previous versions, the keyboard would dismiss and stay that way. That is the correct behavior. I’ve noticed this erroneously presented keyboard does not respond to calls to resignFirstResponder: let resign = #selector(UIResponder.resignFirstResponder) UIApplication.shared.sendAction(resign, to: nil, from: nil, for: nil)

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'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!

I’m unable to use the .searchScopes modifier to add a segmented Picker to my search bar as of developer beta 6. It will not display whether I’m using a NavigationStack, NavigationSplitView, or NavigationView. Has anyone had any luck using this modifier? This simple code will demonstrate the problem. struct ContentView: View {     @State var searchText: String = ""     @State var searchScope: String = "Scope 1"         let data = Array(0..<20)     var body: some View {         NavigationStack {             List {                 ForEach(data, id:\.self) { item in                    Text("\(item)")                 }             }             .searchable(text: $searchText)             .searchScopes($searchScope, scopes: {                     Text("Scope 1")                     Text("Scope 2")             })         }     } } I've submitted this as FB11298015

I'm running into a couple of breaking issues with AppIntents for which I just submitted feedbacks. I figured I'd post them on the forum too for good measure. FB12701143 - @IntentParameterDependency causing crashes in all AppIntents with Entity Queries on iOS 16 I have a pre-existing AppIntent with its own EntityQuery that works just fine on iOS 16. I've built a totally separate intent only available in iOS 17 that makes use of a new entity and a new query using @IntentParameterDependency, but now the original intent crashes after building and running the app on an iOS 16 device with the latest Xcode beta. The line it crashes on is the initializer of the iOS 17-only EntityQuery, even though 1) it shouldn't be able to see it and 2) that EntityQuery isn't involved in the crashing intent. This breaks significant functionality in my AppIntents, and I'm hoping this is a bug rather than a framework limitation. The feedback includes a sample project, crash log, and sysdiagnose. FB12701491 - iOS 17-only CustomIntentMigratedAppIntent stops SiriKit intent equivalent from working on iOS 16 I have a SiriKit intent in my app that I was not able to convert to an AppIntent until iOS 17 because it makes use of an @IntentParameterDependency. However, even though the new AppIntent version is marked as only available in iOS 17 and above, once I conform it to CustomIntentMigratedAppIntent and provide the old intent’s class name, it stops working on iOS 16 devices with an error that the shortcut is unavailable on that device. The CustomIntentMigratedAppIntent should respect the iOS 17 availability annotation and leave the SiriKit intent alone since its migrated replacement isn’t available on iOS 16. The feedback includes a sample project illustrating the issue.

Now that's a mouthful! As of iOS 17 seed 5 and continuing into seed 6, an issue was introduced where default Navigation Bar and Tab Bar behavior breaks when a View is made up of a ScrollView with another ScrollView as the safeAreaInset. This View renders correctly using the code below, with the Navigation Bar and Tab Bar taking on a material effect when there is content behind it (screenshot 1). However, uncommenting out the ScrollView(.horizontal) so it's active causes the Nav Bar and Tab Bars to be fully transparent (screenshot 2): TabView { NavigationStack { ScrollView(.vertical) { LazyVStack { ForEach(0...100, id: \.self) { _ in Color(uiColor: UIColor.red) } } } .safeAreaInset(edge: .top, content: { //ScrollView(.horizontal) { HStack { Color.red Color.pink Color.yellow } // } .frame(maxWidth: .infinity) .frame(height: 44) }) .navigationTitle("Tab 1") .navigationBarTitleDisplayMode(.inline) }.tabItem { Label("One", systemImage: "bolt") } I have tried various combinations of the new scrollLayoutTarget() and related modifiers, but I haven’t been able to find a way to have the nav and tab bars maintain their functionality if the Horizontal ScrollView is enabled. This behavior seems like it’s supposed to be supported, because it’s one of the examples featured n this year’s WWDC session “Beyond scroll views” (at 12:34). It is also worth noting that this issue occurs whether the View is wrapped in a TabView or not. Without the TabView the problem presents the same in the Navigation Bar. I have submitted this issue as FB12983586

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!

Hello, I just submitted FB9939377 about this issue, but figured I'd still post on the forums as well. I have been working on bringing song and album rating functionality to my app, using MusicDataRequest from MusicKit for Swift. When I like or dislike a song, or delete the existing rating, those changes are reflected immediately in the Music app across all of my devices. However, when I try to rate or delete an existing rating for an album, the API request is successful, but the changes are not reflected in Music.app on any of my devices. Querying the /v1/me/ratings/albums/[id] endpoint correctly shows the change that was made, but it does not seem to sync the change to any devices, which continue to show whatever the rating state was before the change I made in my app. I ran 3 tests on albums with the following IDs: 1485040020 - Disliked -> Loved Disliked in Music.app /v1/me/ratings/albums/1485040020 shows the value of the rating attribute as “-1” Changed to “Loved” in my app /v1/me/ratings/albums/1485040020 confirms the value of the rating attribute has changed from “-1” to “1” Music.app on the iPod I used to make the change in my app, as well as another iPhone 11 signed into that Apple ID show the original “Disliked” rating for the album. 1485042017 - Loved -> No Rating Liked in Music.app /v1/me/ratings/albums/1485042017 shows the value of the rating attribute as “1” Deleted the rating from my app /v1/me/ratings/albums/1485042017 now 404s, indicating there is no rating for this album. Music.app on the iPod I used to make the change in my app, as well as another iPhone 11 signed into that Apple ID show the original “Loved” rating for the album. 1485037658 - No Rating -> Loved Confirmed /v1/me/ratings/albums/1485037658 returns a 404, as there is no rating for this album “Loved” the album in my app /v1/me/ratings/albums/1485037658 now returns a value of “1” Music.app on the iPod I used to make the change in my app, as well as another iPhone 11 signed into that Apple ID show me the option to either “Love” or “Suggest Less Like This,” indicating there is no existing rating for the album. There are sysdiagnoses attached to the feedback. Please let me know here or in the Feedback if there is any more information I can provide. Thanks! (P.S., I'm requiring iOS 15 for the next version of my app, so I've finally been digging into MusicKit. What a well-designed and useful API! It's been so quick and easy to replace most of my existing URLSession data task code with MusicKit, and MusicDataRequest is such a thoughtful inclusion to be able to interface with the elements of the API not natively in MusicKit, with the added benefit of not needing to deal with tokens anymore. Thanks to the team for all of their continued hard work on it.)

Hey there Apple Music team! I'm excited to dig into the sessions coming up this week, and what I've seen so far from the developer documentation diffs looks great: audio quality, artist images, and a way to interface with a user's music library in MusicKit. Love it! The thing at the very top of my WWDC wishlist this year was macOS/Mac Catalyst support for the ApplicationMusicPlayer class. I just got finished installing Ventura and Xcode 14, and sadly it looks like the support story is the same as on Big Sur. No API availability on macOS, and an available Mac Catalyst API that ultimately results in the same error from a feedback I submitted on Big Sur: FB9851840 The connection to service named com.apple.Music.MPMusicPlayerApplicationControllerInternal was invalidated: failed at lookup with error 3 - No such process. Is that the end of the story on Ventura, or is there a chance support might be added in a later beta? Is there any additional detail at all that can be shared? I field several requests a week asking if/when my app is coming to the Mac, and I would really love to be able to make that happen. If there is anything at all I can do to test and help overcome the engineering challenges alluded to in the past, I am ready, willing, and able! In any case, thanks for the great work, and I'm looking forward to spending time with the new stuff this summer.

ApplicationMusicPlayer is available on the Mac! 🎉🎉🎉 Enormous thanks to @JoeKun and the team. I've already gotten my app up and running through Catalyst, and I've successfully played music! I also got some timeouts, but that was happening on my phone a lot that day too, so maybe my local CDN was just having a bad day. I wanted to ask this question in a lab this week, but the timing didn't work out: Do you expect the experience to be the same using ApplicationMusicPlayer on a Catalyst vs a macOS target? I'm hoping to reuse much of my iPad app and go the Catalyst route, but I wanted to double check that the new support wasn't just for macOS.

I've been continuing to port my app to the Mac using Catalyst, and have discovered a couple of big issues with MusicLibraryRequest which make it not particularly usable. I've submitted FBs already, but figured a forum post wouldn't hurt :) filter(matching:) functions unavailable on macOS/Catalyst - FB12301718 The first thing I noticed when building for a macOS or Catalyst target is that a couple of functions are simply not available: I'm hoping this is a bug, as these methods are crucial to being able to interact with the library. request.filter(matching: .id, equalTo:) always returns empty on Mac Catalyst - FB12301908 I have not been able to successfully retrieve an Album using a MusicLibraryRequest. The result is always empty. In the feedback, I attached a sample project that makes an unfiltered MusicLibraryRequest, then takes the first album and tries to make a new MusicLibraryRequest filtered to that album's ID. Fetching albums by ID using this method works just fine on iOS 17. Thanks again for all your work on bringing these capabilities to the Mac!