Thanks for the reply. I'm not questioning the existence of the two invocation methods. I'm asking why you would want the (IMO) defective behavior of the isPresented version of .sheet. In that one, if the closure for content tries to pass an object from the invoking view to the sheet for display, it is out of date. For example, you're showing a list, and when the user taps an item, you want to pass that item to a sheet so the user can select something from it. But this doesn't work; the sheet doesn't get the current value of the selected-item variable. There are posts and questions galore online about this problem. Now the problem with the item:onDismiss:content version is that you have to nillify the item reference to dismiss the sheet. So how are you supposed to return data from the sheet? I ended up having to change the item from a struct to a class and junking it up with some state variables so I could pass it to the sheet and then store the selections the user made on the sheet. And of course I need a copy of the selectedItem variable because I have to nillify the one that triggers the sheet. Am I missing something here, or does the design of this thing stymie the programmer at almost every turn? What I'm doing is, I would bet, an extremely common workflow. Why does it require such cumbersome gymnastics? And this appears to be another example of the conflict between "prefer structs" and "the single source of truth." Structs are copied all over the place, which thoroughly breaks the single-source paradigm. And you can't fix it here with a binding.

Further research reveals that you have to use an alternate form of .sheet, which takes an "item": .sheet(item: $selectedContact, onDismiss: { sheetDismissed() }, content: { contact in ContactMethodView(withContact: contact) }) I had seen references to this, but without explanation of how the sheet is triggered. It turns out that it's triggered when the "item" binding is non-nil. I'm curious as to why you'd want the behavior of the other method. It seems error-prone and aggravating.

Indeed you can! Thanks!

It did.

Thanks for the reply. I did submit a bug report with associated files: FB16433363 I needed to proceed, so I ended up doing xcode-select -r After that, the caption showed /Applications/Xcode

Thanks for the reply. It's disappointing that we have to hand-roll such a fundamental control at this point.

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