Ran into this as well. The compiler is optimizing something incorrectly for release builds. Using Predicate init directly (instead of the Macro) doesn't resolve the issue. Nor does any combo of explicit/verbose casting. Something as simple as this: func fetchModel<M>(with id: UUID, prefetching relationshipKeyPaths: [PartialKeyPath<M>] = []) throws -> M where M: PersistentModel, M.ID == UUID { var fetchDescriptor = FetchDescriptor<M>() fetchDescriptor.relationshipKeyPathsForPrefetching = relationshipKeyPaths fetchDescriptor.predicate = #Predicate { $0.id == id } fetchDescriptor.fetchLimit = 1 guard let model: M = try? modelContext.fetch(fetchDescriptor).first else { throw SwiftDataRepoError.modelNotFound(withId: id) } return model } Results in this crash: SwiftData/DataUtilities.swift:85: Fatal error: Couldn't find \Person.<computed 0x0000000100d6511c (UUID)> on Person with fields [SwiftData.Schema.PropertyMetadata(name: "id", keypath: \Person.<computed 0x0000000100d8da8c (UUID)>, defaultValue: Optional(5CAE942A-EF4E-4B89-A777-D79153C7F276), metadata: nil) .... Only thing that works is initializing FetchDescriptor with the explicit type. var fetchDescriptor = FetchDescriptor<Person>() fetchDescriptor.relationshipKeyPathsForPrefetching = relationshipKeyPaths fetchDescriptor.predicate = #Predicate { $0.id == id } fetchDescriptor.fetchLimit = 1 guard let model = try modelContext.fetch(fetchDescriptor).first else { throw SwiftDataRepoError.modelNotFound(withId: id) } return model Going to mess with some compiler settings to try and narrow this down. This might need to be reported to the SwiftLang/Foundation issue tracker, it may not be a bug with SwiftData per se.

@DTS Engineer somewhat related to this, the documentation and sample app doesn't explain clearly how OpenIntent for an IndexableEntity is supposed to work. perform() has a default implementation in this case, and there's a brief mention of universal links. So I'm guessing this is only intended to be used for entities that are also web accessible? And if not then you should just use legacy CSSearchableItem & NSUserActivity? It looks like in iOS 26, there's some automagic with macros and the compiler to wire the two together to move away from NSUserActivity, so maybe this just wasn't fully fleshed out in iOS 18? Or is there something I'm missing?

As of Xcode 26 it should now be possible to have an AppIntent in a Swift package that then is usable in an app or widget target correct? So long as AppIntentsPackage is defined correctly in all 3 targets (package with the intent, the app target, and widget extension) that's all that is needed for this to work? Or is there something else (does this require OS 26 for example)? Because I'm still getting "Failed to fetch metadata for MyIntent" when trying to invoke an intent from a widget.

Figured it out. For anyone who was following the instructions at the end of the WWDC 2025 video on App Intents: It appears AppIntentsPackage definitions are only required when you have an AppEntity conformances to define across package boundaries. AppIntents themselves are automatically discovered in any package or target, and defining AppIntentsPackage could result in duplicate metadata for AppIntents in the bundle, resulting in the OS being unable to resolve the AppIntent to use at runtime. So if all you have is AppIntents to share across the app bundle and a widget extension for example, you do not need to define AppIntentsPackage at all. This is a Xcode 26 compiler feature and is retroactive to at least iOS 18.