This is a huge impediment to using MusicKit, especially when combined with the apparent lack of any way to search by title and artist name.

I should have noted that the extra details allowed me to filter the GenerativeModels source and eliminate the vast majority of the spam. I'll take a look at the log tutorial though. Thanks!

Since you've solicited info: I just encountered a problem with MusicPlayer.State, in that it doesn't work with the current Observation framework. For example, this does not work: withObservationTracking { _ = musicPlayer.state.playbackStatus } onChange: { Task { print("PlaybackManager observed player-state change, to \(await self.musicPlayer.state).") await self.playerChanged() await self.startObserving() // await because of MainActor } } I had migrated my application's observation usage to the new world order, but it looks like I have to revert files that use MusicPlayer. Also: I urge the frameworks developers to abandon the idea that people are just slapping stuff into a SwiftUI view and calling it a day. This has turned development on Apple platforms into a tedious slog of workarounds and tricks to let controller-type objects communicate with each other; and repeated disappointment when each new observation regime repeats the same mistakes (for example, only offering "willChange" and not "didChange").

Well, that's handy. The perpetrator for the two that appear most is com.apple.GenerativeModels - availability

NP, it got me to the answer! The bug report is FB16031640 I attached a project to it to repro the problem.

Thanks! That does work, with the slight addition of having to call that method on the URL returned by the file dialog. So my button to open a file in SwiftUI looks like: Button(action: { isImporting = true }, label: { Text("Open P8 file") }) .fileImporter(isPresented: $isImporting, allowedContentTypes: [.data], onCompletion: { result in switch result { case .success(let theURL): do { let didStart = theURL.startAccessingSecurityScopedResource() defer { if didStart { theURL.stopAccessingSecurityScopedResource() } } secretKey = try String(contentsOf: theURL, encoding: .utf8) generateToken() } catch { message = error.localizedDescription } case .failure(let error): print(error) } }) I filed a bug report on the documentation.

Thanks for the reply. I think I'm doing everything mentioned in that article. There doesn't seem to be anything to do immediately before presenting the File dialog: The operating system implicitly starts security-scoped access on URLs passed from open panels, save panels, or items dragged to your app’s icon in the Dock

For anyone else with a similar problem: This is apparently a known issue, although presumably the exact error message may differ. As a workaround, you can turn off view debugging. Thanks to Apple for providing this information while they investigate: Select your target and click on "Edit Scheme...". Then, under Run (Debug) > Options > View Debugging, uncheck the "Enable user interface debugging" box.

Not fixed with iOS 18.1. I was hoping it would be, because this problem sounds suspiciously similar: Fixes an issue where digital car keys may not unlock or start a vehicle with passive entry after restoring from a backup or transferring directly from another iPhone

Thanks for the reply. I have filed a report and attached a project to repro it. It's a big enough deal that I also started a paid support incident (so far I've only received confirmation). Report is FB15492822. The incident case ID is 9640471