Post not yet marked as solved
Hello @haarj,
I'm sorry to hear that. Please file a new ticket on Feedback Assistant and make sure to attach a sysdiagnose taken shortly after reproducing this issue. Please also make sure to mention the time when this issue occurred.
Please refer to this document for more information on how to capture a sysdiagnose.
Thank you very much in advance for your help.
Best regards,
Post not yet marked as solved
Hello @Czajniks,
I don't know yet.
Would you mind filing a new ticket on Feedback Assistant to track the issue you're encountering? Please make sure to include a sysdiagnose and an approximate timestamp of when your app exercised this code path that lead to changing the ApplicationMusicPlayer.state.playbackRate.
Thank you very much in advance.
Best regards,
Hello @Kimfucious,
Sorry for the very late update, but just to close the loop on this, we did address this issue in a subsequent beta version of iOS 16.0, before the final version was offered to regular customers.
Thanks again for reporting this issue!
Best regards,
Post not yet marked as solved
Hello @nickfromsf, @florom, @umbertoide, @xalio,
Thank you all for bringing attention to this issue.
Indeed, we accidentally regressed the functionality of the currentPlaybackRate property for playback of Apple Music content in earlier beta builds of iOS 16.1.
As @xalio pointed out, we fixed that up in the latest beta build of iOS 16.1, which is beta 4 for iPhone (build number 20B5064c).
I hope this helps.
Best regards,
Post not yet marked as solved
Hello @dimsumthinking,
I'm happy to report that we have made some small improvements in MusicKit's support for the simulator environment.
Provided that you upgrade your Mac to macOS Ventura, you should be able to use a subset of the functionality of MusicKit in the simulator.
Specifically, requests that do not require user authentication behind the scenes work, such as:
requesting catalog search results with MusicCatalogSearchRequest;
requesting catalog search suggestions with MusicCatalogSearchSuggestionsRequest;
requesting catalog charts with MusicCatalogChartsRequest;
requesting specific catalog resources with MusicCatalogResourceRequest.
However, other requests such as those to load personal recommendations or recently played items are still unavailable in the simulator, as those do require user authentication.
I hope this helps.
Best regards,
Hello @Bolsinga,
We are not able to talk about future plans on developer forums. We only talk about what is already available in shipping or beta versions of our Apple platform operating systems.
Please check out this other thread with more context about new features of MusicKit announced at WWDC22 and how that relates to the matter of compatibility with macOS.
Best regards,
Post not yet marked as solved
Hello @MKDeveloper,
If your bundle ID doesn't appear on that list, it's probably because it's a brand new app, and you haven't created it yet.
Please visit the Certificates, Identifiers, and Profiles section of the developer website, and press the blue button with a "+" sign.
I hope this helps.
Best regards,
Post not yet marked as solved
Hello @damartin1,
Actually, MusicKit on iOS 16 Beta includes new structured requests to fetch recently played items. With these, you no longer need to use MusicDataRequest.
Instead, you could achieve the same thing I previously showed by simply using MusicRecentlyPlayedContainerRequest:
let request = MusicRecentlyPlayedContainerRequest()
let response = try await request.response()
print("Recently played items: \(response.items)")
If you just want recently played tracks, you can specify that in the generic parameter for MusicRecentlyPlayedRequest:
let request = MusicRecentlyPlayedRequest<Track>()
let response = try await request.response()
for track in response.items {
print("Recently played track titled '\(track.title)' from '\(track.artistName)'.")
}
As for the "imageURL", I recommend you just pass the artwork of a Track directly to ArtworkImage, which is a SwiftUI View that can render the Artwork very easily. Compared to the idea of getting a URL and loading the image data manually, using ArtworkImage is a more streamlined and future proof way of rendering music artwork.
I hope this helps.
Best regards,
Post not yet marked as solved
Hi @talkingsmall,
The one thing I can't find a solution for is being able to get a link to share the catalog version of the library album or song resource. The URL property seems to always return nil.
Funny you should say that; we've been discussing this exact scenario this week for our internal clients.
Perhaps that could still be populated with the link to the resource using the catalog ID (if available for a given resource)?
I believe that is the desired solution from an API standpoint.
I'd actually strongly discourage you from using MusicDataRequest with a custom crafted URL based on the id of the Album. As much as we are trying to finalize our heuristics for how to pick the correct id for each type during the beta period for iOS 16, I must also say that we reserve the right to change this heuristic in the future.
Instead, I would simply request that you file a ticket on Feedback Assistant asking for the url property to be set to a non-nil value for items coming from the music library.
Thank you very much in advance.
Best regards,
Post not yet marked as solved
Hello @talkingsmall,
Thanks for looking at these new APIs so promptly, and for filing all those detailed tickets on Feedback Assistant.
The first two look like things we need to investigate further before we can make any kind of comment on them.
The last one about exposing the catalog id is one which, to be honest, I'm not convinced we want to do. We don't want to expose data just for the sake of it, just because we can. When we expose data, we have some idea of what we think it's going to be useful for.
Furthermore, the matter of identifiers with MusicKit is a fairly tricky one, and one we think deeply about. I'm sure there's always room for improvement, but we've seen several instances where developers get confused about the type of id they're supposed to pass to various APIs, and that leads us to believe that we can usually expose our APIs in a way that removes the possibility of anyone making a mistake about the identifiers they pass to MusicKit. We typically do that by leveraging Swift's strongly typed system at compile time, by requiring whole music items in various APIs.
As an example, that's why we strongly encourage the use of methods of MusicLibraryRequest like filter(matching:contains:) for relationships.
More generally, there are many things we've seen developers do with the catalog id values that can be achieved in different ways with MusicKit; sometimes, these alternatives are more expressive and idiomatic in Swift, and they can lead to more flexibility for the framework to have more data that might enable it to perform the work faster in some scenarios.
Therefore, we definitely need to know more about why you even want to get the catalog id.
Thank you very much for your continued feedback!
Best regards,
Hello @talkingsmall and @snuff4,
We made a number of important improvements to the list of available properties for items retrieved from the music library. You can find those in iOS 16 Beta 3, which just we just released today.
For example, the Song type now includes the following attributes:
lastPlayedDate;
libraryAddedDate;
playCount.
I hope you'll find this useful.
Best regards,
Post not yet marked as solved
Hello @talkingsmall,
We made a number of important improvements to the list of available properties you can filter with and sort by using MusicLibraryRequest. You can find those in iOS 16 Beta 3, which just we just released today.
For example, the list of available library filters for Song now includes:
albumTitle;
artistName;
composerName;
title.
Additionally, the list of properties you can sort library songs by now includes new interesting properties like:
lastPlayedDate;
libraryAddedDate;
playCount.
Not only can you now sort results by those properties, but they're also available as properties of the relevant music item structures (for example, Song now exposes playCount).
Moreover, we made another change that allows you to pass the value for MPMediaItemPropertyAlbumPersistentID to filter methods from MusicLibraryRequest with the \.id key-path.
I hope you will find the capabilities of MusicLibraryRequest to be more well rounded in this latest Beta, and that you'll be able to adopt it in your app for all your music library needs.
Best regards,
Hello @dongelen,
Thank you for your question about MusicKit's Artwork.
The best supported way to render an Artwork from MusicKit is actually to simply pass it to an ArtworkImage, which is a SwiftUI View. I highly encourage to give that a try.
That said, if you need to preload images as you described, what you're trying to do is also intended to work. Indeed, regardless of the non-standard musickit:// URL scheme, MusicKit is engineered to allow URLSession to load the artwork's image data seamlessly.
It looks like you found an edge case where that doesn't currently work as designed. In order to investigate this further, we would need you to file a ticket on Feedback Assistant, including a sysdiagnose captured right after reproducing this issue.
It would also help us to diagnose this issue if you included an NSLog statement right before loading the data, like this:
let urlRequest = URLRequest (url: url)
NSLog("dongelen's app: about to load MusicKit artwork data for URL \(url)")
let data = try await URLSession.shared.data(for: urlRequest)
Thank you very much in advance.
Best regards,
Post not yet marked as solved
Hello @FJaffri,
Playing Apple Music content using AVFoundation is not supported.
The recommended APIs for playing Apple Music content are ApplicationMusicPlayer and SystemMusicPlayer in MusicKit.
However, it would help us to have specific information about your use-case so we can try to think about the best approach to enable the functionality you want to build in a way that is compatible with our contractual obligations for DRM content.
Capturing this information in a ticket on Feedback Assistant is the best way forward for this enhancement request.
Thank you very much in advance.
Best regards,
Post not yet marked as solved
Got it, thanks @Kimfucious.
@david-apple's advice is definitely correct, although I understand you cannot use it right now because of the issue described in that other thread.
When that issue is resolved, you should definitely use with(_:preferredSource:) with .library.
Please stay tuned.
And thanks for the kind words. Your feedback certainly helps. Thanks for catching these issues and reporting them promptly while we still have a bit of time to iron them out in the beta period for iOS 16.
Cheers,
