I have a SwiftUI app I have enabled to run on M1 Macs (Designed for iPad). It uses the new SwiftUI lifecycle. I've just added a CommandMenu to the main WindowGroup. On the iPad these commands, whether clicked in the menu or initiated by a keyboard shortcut work as expected on the iPad. However, my iMac, the app crashes. The error says Application Specific Information: Crashing on exception: -[UIMenuController propertyList]: unrecognized selector sent to instance 0x12250b1e0 This is what the CommandMenu looks like WindowGroup { ... }.commands {         CommandMenu(LocalizedStringKey("Categories")) {             Button(action:{                 appConfiguration.currentPage = Page.books             }) {                 Label(LocalizedStringKey(BookListing.title), systemImage: BookListing.icon)             }             .keyboardShortcut("b", modifiers: [.control])             Button(action:{                 appConfiguration.currentPage = Page.tags             }) {                 Label(LocalizedStringKey(Tags.title), systemImage: Tags.icon)             }             .keyboardShortcut("t", modifiers: [.control])             Button(action:{                 appConfiguration.currentPage = Page.settings             }) {                 Label(LocalizedStringKey(Settings.title), systemImage: Settings.icon)             }             .keyboardShortcut("s", modifiers: [.control])         }     } AppConfiguration is an ObservableObject and setting currentPage is how to programmatically navigate the TavView. Is there anything I am doing wrong? Is there a bug someone knows about that I could be hitting? Here's the relevant part of the stack if that can help shed some light on what's gone wrong. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 AppKit 0x191895514 -[NSApplication _crashOnException:] + 324 1 AppKit 0x19189550c -[NSApplication _crashOnException:] + 316 2 AppKit 0x19189522c -[NSApplication reportException:] + 580 3 AppKit 0x19193f708 uncaughtErrorProc + 156 4 HIToolbox 0x1975b10bc DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1696 5 HIToolbox 0x1975b02dc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 356 6 HIToolbox 0x1975c6750 SendEventToEventTarget + 40 7 HIToolbox 0x197627310 SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 416 8 HIToolbox 0x19764c44c SendMenuCommandWithContextAndModifiers + 56 9 HIToolbox 0x19764c3dc SendMenuItemSelectedEvent + 352 10 HIToolbox 0x19764c208 FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 100 11 HIToolbox 0x19764cbc8 MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 560 12 HIToolbox 0x19764c8e8 _HandleMenuSelection2 + 416 13 AppKit 0x1916b4ce4 _NSHandleCarbonMenuEvent + 300 14 AppKit 0x1916b4ac4 _DPSEventHandledByCarbon + 68 15 AppKit 0x191516bc4 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3280 16 AppKit 0x1915085f0 -[NSApplication run] + 596 17 AppKit 0x1914d9d08 NSApplicationMain + 1132 18 AppKit 0x1917afdd0 _NSApplicationMainWithInfoDictionary + 24 19 UIKitMacHelper 0x1a423aa7c UINSApplicationMain + 1276 20 UIKitCore 0x1b68d59f8 UIApplicationMain + 164 21 SwiftUI 0x1cc162374 closure #1 in KitRendererCommon(_:) + 164 22 SwiftUI 0x1cc1622cc runApp<A>(_:) + 252 23 SwiftUI 0x1cba55560 static App.main() + 128

I think I need to find a way to better safely query the URI type as a string or more likely, fix a concurrency issue. For more detail... I'm building a SwiftUI view that allows people to link up objects (basically tag an object). With the SwiftUI view, based on the user's input the NSPredicated changes. It filters out the user's selected objects and then matches against name or url with a contains. This is where the crash is happening - in that compound predicate. The view is the Tag edit view and I am adding the objects to it. private func updateNSPredicate(for query: String) -> NSPredicate? {         if !query.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty{             return NSCompoundPredicate(andPredicateWithSubpredicates: [                 NSPredicate(format: "NOT(id IN $ids)").withSubstitutionVariables(["ids": filtered]),                 NSPredicate(format: "(name contains[cdl] $query) or (url contains[cdl] $query)").withSubstitutionVariables(["query": query]),             ])         } else {             return defaultPredicate         }     } NOTE: In my CloudKit database these types are: name = String url = URI This always works with objects that are created already, the filter with url contains $query has been used elsewhere for many months with no problems. However, sometimes when I save the Tag. It will crash. I get the following: Serious application error.  Exception was caught during Core Data change processing.  This is usually a bug within an observer of NSManagedObjectContextObjectsDidChangeNotification.  Can't use in/contains operator with collection https://wwww.example.com (not a collection) with userInfo (null) I can observe if I remove the or (url contains[cdl] $query) then this crash never happens or it seems to be so rare I can't reproduce it after numerous tries. Where as when I have the url query in, it will be guaranteed to crash on the 2nd or 3rd try. Typically the more objects I add to the relationship the more likely it will happen. Removing all objects from the tag will not cause a crash. It's only the act of creating new relationships that seems to cause it. My concern is it's something about my persistent history tracker. While I can see how to stop the crash, I know I should be able to query url. The error seems to think it's a problem with change processing too - even though that predicate shouldn't be used in the merging of changes. So, I'm guessing I'm hitting some sort of concurrency bug but I'm not getting where it goes wrong. Without posting too much I hope I can show which contexts I'm using and roughly how they're being used. I fairly closely following this example if that helps: https://www.avanderlee.com/swift/persistent-history-tracking-core-data/ // set up history tracking with main container historyTracker = PersistentHistoryTracker(persistentContainer: container, actor: storageActor,  userDefaults: AppGroupUserDefaults) // Later in the observer create a background context let bgContext = persistentContainer.newBackgroundContext() let history = try fetcher.fetch() bgContext.performAndWait { // fetch history then history.merge(into: bgContext) // main context viewContext.perform { history.merge(into: self.viewContext) } } The stack does show it on the Predicate creation side but I'm assuming it's a concurrency issue given it only happens in one scenario. 0   CoreFoundation                      0x000000018040e7c8 __exceptionPreprocess + 172 1   libobjc.A.dylib                     0x0000000180051144 objc_exception_throw + 56 2   Foundation                          0x0000000180b38cec -[NSInPredicateOperator performPrimitiveOperationUsingObject:andObject:] + 416 3   Foundation                          0x0000000180ae9f18 -[NSComparisonPredicate evaluateWithObject:substitutionVariables:] + 364 4   Foundation                          0x0000000180aec9b8 -[NSCompoundPredicateOperator evaluatePredicates:withObject:substitutionVariables:] + 208 5   Foundation                          0x0000000180aec46c -[NSCompoundPredicate evaluateWithObject:substitutionVariables:] + 212 6   Foundation                          0x0000000180aeca4c -[NSCompoundPredicateOperator evaluatePredicates:withObject:substitutionVariables:] + 356 7   Foundation                          0x0000000180aec46c -[NSCompoundPredicate evaluateWithObject:substitutionVariables:] + 212 8   CoreData                            0x000000018459b064 -[NSFetchedResultsController _preprocessUpdatedObjects:insertsInfo:deletesInfo:updatesInfo:sectionsWithDeletes:newSectionNames:treatAsRefreshes:] + 280 9   CoreData                            0x000000018459be74 __82-[NSFetchedResultsController(PrivateMethods) _core_managedObjectContextDidChange:]_block_invoke + 1528 10  CoreData                            0x00000001845402c0 developerSubmittedBlockToNSManagedObjectContextPerform + 156 11  CoreData                            0x000000018454019c -[NSManagedObjectContext performBlockAndWait:] + 212 12  CoreData                            0x000000018459b860 -[NSFetchedResultsController _core_managedObjectContextDidChange:] + 96 13  CoreFoundation                      0x0000000180344990 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 140 14  CoreFoundation                      0x00000001803448b4 ___CFXRegistrationPost_block_invoke + 84 15  CoreFoundation                      0x0000000180343dbc _CFXRegistrationPost + 404 16  CoreFoundation                      0x00000001803437c8 _CFXNotificationPost + 668 17  Foundation                          0x0000000180b88ae0 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88 18  CoreData                            0x000000018453335c -[NSManagedObjectContext _postObjectsDidChangeNotificationWithUserInfo:] + 320 19  CoreData                            0x0000000184545984 -[NSManagedObjectContext _createAndPostChangeNotification:deletions:updates:refreshes:deferrals:wasMerge:] + 1212 20  CoreData                            0x0000000184534f04 -[NSManagedObjectContext _processRecentChanges:] + 2484 21  CoreData                            0x0000000184536f58 -[NSManagedObjectContext save:] + 400

I have an iPad app I've just started testing in visionOS and it's gone pretty good so far except one issue, none of the long-press or swipe gestures in my List work. The app is SwiftUI based. so I'm using a List with the swipeActions and contextMenu modifiers. Could these be broke, unsupported or am I not understand how to initiate these in the simulator? For a long press I'd assume just holding down on the mouse button should work. This appears to work in Safari.

I have an app that has an iOS, Widget and ShareExtension targets. When viewing the project file and I look at the iOS target, it has the Identity section I can view / change the app category, Display Name, Bundle Identifier, version and build. However, the Widget and ShareExtension now has these missing. So, if I try to change the iOS version / build I get an error that they do not match. The data appears to exist in the project file so I can hand edit the file for the Widget and ShareExtension. I believe this started since using the Xcode 15 betas. Or at least I haven't noticed until now since I wanted to change the version number. This appears to be consistent across all projects I have with Widgets. Has anyone experienced this and is there a way to get it back?

I'm using a LPMetadataProvider to get metadata for URLs. If I do this if itemProvider.hasItemConformingToTypeIdentifier(UTType.image.identifier) { let item = try? await itemProvider.loadItem(forTypeIdentifier: UTType.image.identifier) // continue with code to convert data to UIImage... } That seems to fail quite often, even on larger sites like Amazon where users will expect to see an icon. I've noticed it's because sometimes the type is dyn.agq80w5pbq7ww88brrfv085u I'm assuming this is because something about the website response or the image data does not let the system determine if it is actually an image. If I just do this let type: String = "dyn.agq80w5pbq7ww88brrfv085u" if itemProvider.hasItemConformingToTypeIdentifier(type) { let item = try? await itemProvider.loadItem(forTypeIdentifier: type) // continue with code to convert data to UIImage... } Then I get the icon, so it is there and it is an image. The problem is, does this dynamic type cover everything? Should I even be doing that? Does anyone know precisely what causes this and are there recommendations on better ways to handle it? I know LPLinkView appears to do something to load these 'non-image' icons so I am assuming there are way. My assumption is that it would be safe to look at the results of itemProvider.registeredTypeIdentifiers() and if it has something use that as the type rather than coming up with a hardcoded list of types to check for.