I've noticed if I create a CommandMenu without a keyboardShortcut of any kind then it does not crash. So, I suspect the issue is around there. Considering the type of error being related to selectors, I've tried changing my event modifiers to be the full definition (example EventModifiers.control rather than .control) and that does not seem to help either. I should have noted, this is on Montery 12.3.1 and the iPad app targets iOS 15.0

I may have solved the crash even if I do not know why the URI query failed. I'm assuming the persistent. history tracking probably isn't the issue or there's something more to it. I think my issue was where the nspredicate came from that I was modifying. To easily setup a fetch request I wrap it with a view container like this DynamicFetchView( predicate: nil, sortDescriptors: sort, fetchLimit: 10 ) { (items: FetchedResults<MyItem>) in ... } Then using the mentioned function I would do items.nsPredicate = updateNSPredicate(for: query). I assume between updating the Tag with its new items and whatever else happens to the SwiftUI view as part of the data changing, then I hit this problem. So I've added a state object to hold the predicate and pass that to the DynamicFetchView and update the state predicate instead. @State private var predicate: NSPredicate? = nil ... DynamicFetchView( predicate: predicate, sortDescriptors: sort, fetchLimit: 10 ) { (items: FetchedResults<MyItem>) in ... } ... predicate = updateNSPredicate(for: query) It would be good to know why the URI 'contains' query breaks and string 'contains' does not. I can make some educated guesses, but at the very least I do not think I need to worry about this crash for now. I've tried dozens of times with no problems.

I've played around further and I found out the real issue. Swipe and Long-press do work. However, on the first item in the row you need to be very specific and touch on, what seems like, the last couple of pixels from the bottom of the row. A lot of the UI buttons around the top above the search bar also seem to be hard to press or their touch targets are off. This includes my toolbars with the .editor role. There's no hacks, just standard toolbars and SwiftUI buttons.

I've just started seeing this as well.

I have switched back to my main branch and opened the project in Xcode 14.3.1 and each target that should have an identity section does have it, so it does look like it's been my transition to the Xcode betas that caused them to go away.

Thank you for suggesting that. It appears to behave the same way, assuming I have not made a mistake. I should state this is on a simulator of an iPhone 15 Pro running iOS 17.2 and compiled with Xcode 15.2 This is what I tested. Obviously this just a quick and dirty code snippet. _ = metadata?.iconProvider?.loadObject(ofClass: UIImage.self) { image, error in dump(error) dump(metadata?.iconProvider?.registeredTypeIdentifiers()) if let iconImage = image as? UIImage { DispatchQueue.main.async { self.icon = iconImage } } } It's the same in that it works when it is one of these types: public.png com.microsoft.ico And fails when it's the type dyn.agq80w5pbq7ww88brrfv085u I'm still unsure if I am doing the right thing to blindly grab the first type as I've been testing (see below) but I have to say it seems to work pretty well so far and if it does not create an image it should just return nothing. I'm guessing the URL check is probably unnecessary for an icon provider but if I keep that it can always go to the bottom where it'll not cause an additional check for the other cases but the performance seems reasonable. if let type = itemProvider.registeredTypeIdentifiers().first { let item = try? await itemProvider.loadItem(forTypeIdentifier: type) if item is UIImage { ... } if item is URL { ... } if item is Data { ... } } I suspect I may be able to drop the URL check or at worst put the check at the bottom where it will likely never get hit.