“SwiftData inheritance relationship”

I first started using the SwiftUI pushWindow API in visionOS 26.2, and I've reported several bugs I discovered, listed below. Under certain circumstances, pushed window relationships may break, and this behavior affects all other apps, not just the app that caused the problem, until the next device reboot. In other cases, the system may crash and restart. (FB21287011) When a window presented with pushWindow is dismissed, its parent window reappears in the wrong location (FB21294645) Pinning a pushed window to a wall breaks pushWindow for all other apps on the system (FB21594646) pushWindow interacts poorly with the window bar close app option (FB21652261) If a window locked to a wall calls pushWindow, the original window becomes unlocked (FB21652271) If a window locked in place calls pushWindow and the pushed window is closed, the system freezes (FB21828413) pushWindow, UIApplication.open, and a dismissed immersive space result in multiple failures that require a device reboot (FB21840747) visionOS r

I've encountered an issue where we need multiple domain associations with separate Apple Pay implementations. Briefly, we have a /.well-known/apple-developer-merchantid-domain-association already setup with Stripe, and now we need another, different version of the file to get setup with FreedomPay. FreedomPay insists this file represents a three-way relationship between all parties and I have no reason to disbelieve them. I'm wondering if anyone has encountered this or if there is a standard procedure. I'm currently trying to find documentation on the exact way Apple Pay verification interacts with this file to see if we can produce it dynamically.

I'm building a SwiftUI app with SwiftData and want to centralize both query logic and related actions in a manager class. For example, let's say I have a reading app where I need to track the currently reading book across multiple views. What I want to achieve: @Observable class ReadingManager { let modelContext: ModelContext // Ideally, I'd love to do this: @Query(filter: #Predicate { $0.isCurrentlyReading }) var currentBooks: [Book] // ❌ But @Query doesn't work here var currentBook: Book? { currentBooks.first } func startReading(_ book: Book) { // Stop current book if any if let current = currentBook { current.isCurrentlyReading = false } book.isCurrentlyReading = true try? modelContext.save() } func stopReading() { currentBook?.isCurrentlyReading = false try? modelContext.save() } } // Then use it cleanly in any view: struct BookRow: View { @Environment(ReadingManager.self) var manager let book: Book var body: some View { Text(book.title) Button(Start Reading) { manager.startReading(book) } if man

I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enable

I have two different VersionedSchema accessed via two different and distinct in-memory ModelContainers. However, both schemas have a model named Item. LocalSchema.Item and RemoteSchema.Item have slightly different properties. If I create and save RemoteSchema.Item in one context then I cannot create and save LocalSchema.Item in a different context due to missing origin property. enum LocalSchema: VersionedSchema { static var versionIdentifier: Schema.Version = .init(1, 0, 0) static var models: [any PersistentModel.Type] = [ Item.self ] @Model class Item { @Attribute(.unique) var title: String var created: Date var modified: Date init(title: String, created: Date, modified: Date) { self.title = title self.created = created self.modified = modified } } } enum RemoteSchema: VersionedSchema { static var versionIdentifier: Schema.Version = .init(1, 0, 0) static var models: [any PersistentModel.Type] = [ Item.self ] @Model class Item { var title: String var created: Date var modified: Date var origin: String init(t

I've spent a few months writing an app that uses SwiftData with inheritance. Everything worked well until I tried adding CloudKit support. To do so, I had to make all relationships optional, which exposed what appears to be a bug. Note that this isn't a CloudKit issue -- it happens even when CloudKit is disabled -- but it's due to the requirement for optional relationships. In the code below, I get the following error on the second call to modelContext.save() when the button is clicked: Could not cast value of type 'SwiftData.PersistentIdentifier' (0x1ef510b68) to 'SimplePersistenceIdentifierTest.Computer' (0x1025884e0). I was surprised to find zero hit when Googling Could not cast value of type 'SwiftData.PersistentIdentifier'. Some things to note: Calling teacher.computers?.append(computer) instead of computer.teacher = teacher results in the same error. It only happens when Teacher inherits Person. It only happens if modelContext.save() is called both times. It

All of my notarization submissions have been stuck at In Progress for up to 10 days. I have 6 submissions spanning from March 4 to March 11, 2026, and none of them have completed or returned any errors. Affected submissions: dbf20b57-0073-444a-b09a-ac6747b7398e (submitted Mar 4) — In Progress d5886683-be64-455c-805d-cd8b12bbcd35 (submitted Mar 4) — In Progress 10bfa709-da17-49cf-9c89-63f93b5fb756 (submitted Mar 4) — In Progress e8d0866e-43f8-4a18-8129-64e6c5d3895a (submitted Mar 9) — In Progress f9526f25-5650-4c45-98ae-d778c58a2ffa (submitted Mar 9) — In Progress 82ec211f-9179-41fd-afe0-937c9b2c2750 (submitted Mar 11) — In Progress Running `notarytool log` returns Submission log is not yet available. Team ID: CB4U5M6U9H It is an Electron-based app built with electron-builder. Steps taken to ensure compliance: Signed with a valid Developer ID Application certificate Hardened runtime enabled (hardenedRuntime: true) Proper entitlements configured (com.apple.security.cs.allow-jit, com.apple.security.cs.allow-unsi