“SwiftData inheritance relationship”

So, looking at things from our side, I'm not sure. I found one bug on this (r.166518515) about accessing a custom directory (/Library//), but the analysis of the engineering team is that it isn't a bug in macOS 26.2... because it shouldn't work in macOS 26.0 EITHER. More specifically, it should only be accessing one of these documented directories: 2. Writing of files: pursuant to normal UNIX file permissions, filters and backends can read/write files to the cache directory specified by the CUPS_CACHEDIR environment variable, to the state directory specified by the CUPS_STATEDIR environment variable, to the temporary directory specified by the TMPDIR environment variable, and under the /private/var/db, /private/var/folders, /private/var/lib, /private/var/mysql, /private/var/run, /private/var/spool (except /private/var/spool/cups), /Library/Application Support, /Library/Caches, /Library/Logs, /Library/Preferences, /Library/WebServer, and /Users/Shared directories. FYI, that does suggest a possible workaround

A similar issue was discussed in this thread. Your case has another layer of complexity - inheritance. Would you mind to have a check if your issue still happens without using inheritance? Also, would you mind to share the OS and SDK version you tested with? Thanks. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Assuming that your second app is under the same team, you can create an app group container for the two apps to share, and then have your first app move its data store to the container, your second app should then be able to access the store. To create an app group container, see Configuring app groups. To locate a SwiftData store to an app group container, see Share the same store file and the associate sample project. Best, —— Ziqiao Chen  Worldwide Developer Relations.

When you use SwiftData + CloudKit, under the hood, the SwiftData framework converts SwiftData models to Core Data managed objects, and use NSPersistentCloudKitContainer to synchronize the objects with CloudKit. NSPersistentCloudKitContainer mirrors each Core Data managed object to (at least) a CloudKit record (CKRecord), as described in Reading CloudKit Records for Core Data. To manage the internal state of the synchronization, it adds a few tables to the store, and the ANSCKRECORDMETADATA table is one of them, which is used to store the metadata of the CloudKit records. The metadata includes the system fields and encoded data of every CloudKit record, so yes, you can see that the size of table gets quite large. The ANSCKRECORDMETADATA table is an internal data structure that NSPersistentCloudKitContainer creates and consumes. You can review the documentation mentioned above to make sure that your models are translated to CloudKit schema correctly, but other than that, I don't see a

I have had the same issue with SwiftData and CloudKit after iOS 26 release. My setup is super minimal and using the default configuration so no clue what could have gone wrong on my side.

Here's the test code where I was attempting to find the relationship between records. // ContentView.swift // TestContactsProject // import SwiftUI import Contacts import OSLog extension Logger { private static var subsystem = Bundle.main.bundleIdentifier ?? com.myelin.TestContactsProject static let logic = Logger(subsystem: subsystem, category: logic) static let analitics = Logger(subsystem: subsystem, category: analitics) } struct ContentView: View { var body: some View { Text(Hello, World!) .padding() .onAppear { Task.init { await fetchAllContacts() //await fetchSpecificContacts() } } } func fetchSpecificContacts(keyStrings: [String]) { // Run this in the background async // Get access to the Contacts Store let store = CNContactStore() // Keys to fetch let keys = [CNContactGivenNameKey, CNContactFamilyNameKey, CNContactPhoneNumbersKey, CNContactIdentifierKey, CNContactRelationsKey] as [CNKeyDescriptor] // Search criteria let predicate = CNContact.predicateForContacts(withIdentifiers: keyStrings) d