Hi, I am trying to use MusicDataRequest from MusicKit to get the user's library artists (https://api.music.apple.com/v1/me/library/artists). This works well, until I am trying to use pagination with it. The data returned by this endpoint contains a "next" property, which reads /v1/me/library/artists?offset=25. Replacing the URL as such resulting in https://api.music.apple.com/v1/me/library/artists?offset=25 no longer works, as the request returns an error: MusicDataRequest.Error( status: 400, code: 40008, title: "Invalid Path Value", detailText: "Unknown library resource type 'artists?offset=25'", ... ) It seems like the request cannot handle query parameters and considers them as part of the request's path. Is there any way to use query parameters with MusicDataRequest? Thanks for any response.

Hi, I am trying to understand how the wildcarding works with CLBeaconIdentityConstraint. The documentation states the following: Constraints always specify a UUID value, but the major and minor values are optional. However, CLBeaconIdentityConstraint comes with the following initializers: init(uuid: UUID) init(uuid: UUID, major: CLBeaconMajorValue) init(uuid: UUID, major: CLBeaconMajorValue, minor: CLBeaconMinorValue) This tells me that you cannot specify a wildcard for both major and minor independently, but rather only for minor or for both major and minor. I do work with beacons that have a weird major mixed in with other data. The idea I want to achieve is to wildcard major, while still being able to supply a minor value. I don't always need this option, but sometimes I don't need/want to know the major but filter out some minor values. Since this class is coming from Objective-C, it works with NSNumber internally (and in Swift they are optional getters), however through the initialisers specified above, I cannot nil the major value. Even in Objective-C the initializers are not exposing the NSNumber object. Is there any approach that does not involve runtime ObjC "hacks" to nil the major NSNumber backing object? Does it make sense to try and nil the major while keeping the minor? Will Core Location still supply beacons just fine? Thanks

Hi, I am trying to use MusicKit for playing a song or an album. I am using the following code for it: Tested on iPhone 11 Pro, iOS 15.0.1 @MainActor private func play<I: PlayableMusicItem>(_ item: I) async throws { let systemPlayer = SystemMusicPlayer.shared if !systemPlayer.isPreparedToPlay { try await systemPlayer.prepareToPlay() } let queue = systemPlayer.queue try await queue.insert(item, position: .afterCurrentEntry) try await systemPlayer.play() } Before I was using the "oldschool" way using the MusicPlayer framework as follows: @MainActor private func playOldschool(identifier: String) { let systemPlayer = MPMusicPlayerController.systemMusicPlayer if !systemPlayer.isPreparedToPlay { systemPlayer.prepareToPlay() } systemPlayer.setQueue(with: [identifier]) systemPlayer.play() } Both have been tested under the same conditions (permissions, same MusicSubscription), however the one using MusicKit does not seem to work well as try await systemPlayer.prepareToPlay() fails. If I remove the prepareForPlay code, it fails on play() with the same message and error as prepareForPlay. The logs show this: [SDKPlayback] prepareToPlay failed [no target descriptor] Error Domain=MPMusicPlayerControllerErrorDomain Code=1 "(null)" I could not find anything for that error domain and code 1, however prepareToPlay fails even in playOldschool, if I use the async variant of the function. At the moment I am staying with playOldschool, because that actually plays music. I wonder if I should file a radar for this or if there is any additional requirement for MusicKit that I haven't fulfilled causing it to fail. Any help is appreciated!

Hi, I am trying to implement the new view modifier to show a subscription view for AppleMusic. In the #wwdc-10294 (Meet MusicKit for Swift) talk, the use case is very clear and it makes sense. We have an album and if the user wants to play it without an active subscription, we show toggle the binding that makes the view appear. However, using a single boolean removes flexibility so I am trying to figure out the following: I have two buttons: "Play" and "Add", which will either play the album as in the talk or add it to the user library using the Apple MusicAPI. In both cases if there is no subscription, I'd like to show the offer. This means I will have two different MusicSubscriptionOffer.Options configuration, one where the messageIdentifier is .playMusic and the other one .addMusic. This also means that I need to use two viewModifiers .musicSubscriptionOffer resulting in two different bindings (otherwise I assume both view controllers will show when the binding changes?). Worst case is if I show a list of songs and want to have options for .playMusic and .addMusic for each song, then I need a dynamic amount of bindings for the view modifier. Would I need to handle this like list bindings? Ideally I'd like an API that allows me to pass in an enum and provide options based on the enum cases like other SwiftUI API (like .sheet). This would allow for dynamic options and only requiring one single .musicSubscriptionOffer. Is there any solid solution for this at the moment? Any insights would be helpful, thanks!