I am migrating a CloudKit-synchronized multi-platform app from CoreData to SwiftData. (Xcode 27.0 beta 5). One of my Models/Entities contains a Transformable attribute, which is defined in the CoreData model editor as: and which is defined in the generated CoreData class as @NSManaged nonisolated public var authorNames: [String]? Using the built-in translation took, Xcode created a Model wich included @Attribute(.transformable(by: "NSSecureUnarchiveFromDataTransformerName")) var authorNames: [String] = [] This compiles but does not run. In the function func getModelContainer() throws -> ModelContainer { let storeURL = try FileManager.default.url( for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: true) .appendingPathComponent(dbName) let modelConfiguration = ModelConfiguration( schema: dbSchema, url: storeURL, cloudKitDatabase: .automatic) let container = try ModelContainer( for: dbSchema, migrationPlan: MigrationPlan.self, configurations: [modelConfiguration]) return container } the app throws a fatal error in the ModelContainer initializer, SwiftData/SchemaCoreData.swift:398: Fatal error: Application must register a ValueTransformer for NSSecureUnarchiveFromDataTransformerName So I added the following line of code at the top of this function: ValueTransformer.setValueTransformer( NSSecureUnarchiveFromDataTransformer(), forName: .secureUnarchiveFromDataTransformerName) which also compiles but also throws the same fatal error in the same place. Can anyone suggest how to resolve this problem? This is a CloudKit synchronized app, so I am constrained in what I can do with this attribute.

Put simply, @Attribute(originalName:) doesn't seem to work. I'm getting "Validation error missing attribute values on mandatory destination relationship". Tried with Xcode 26.6 on iOSes 18.6 and 26.5, and with Xcode 27 on iOS27. Same result. Original Schema: typealias CurrentSchemaModel = SchemaV100 typealias House = CurrentSchemaModel.House typealias Automobile = CurrentSchemaModel.Automobile enum SchemaV100: VersionedSchema { static let versionIdentifier: Schema.Version = .init(1, 0, 0) static var models: [any PersistentModel.Type] { [Automobile.self, House.self] } @Model final class Automobile { var id: UUID = UUID() var name: String = "" init(name: String) { self.name = name } } @Model final class House { var id: UUID = UUID() var name: String = "" var automobile: Automobile var createdDate: Date = Date() init(name: String, automobile: Automobile) { self.name = name self.automobile = automobile } } } Updated Schema (renamed House.automobile to House.automobileOne): typealias CurrentSchemaModel = SchemaV101 /*updated from SchemaV100 */ enum SchemaV101: VersionedSchema { static let versionIdentifier: Schema.Version = .init(1, 0, 1) static var models: [any PersistentModel.Type] { [Automobile.self, House.self] } @Model final class Automobile { var id: UUID = UUID() var name: String = "" init(name: String) { self.name = name } } @Model final class House { var id: UUID = UUID() var name: String = "" @Attribute(originalName: "automobile") var automobileOne: Automobile var createdDate: Date = Date() init(name: String, automobileOne: Automobile) { self.name = name self.automobileOne = automobileOne } } } Migration Plan: enum TestRenameMigrationPlan: SchemaMigrationPlan { static var schemas: [any VersionedSchema.Type] { let currentSchemas: [any VersionedSchema.Type] = [SchemaV100.self, SchemaV101.self] return currentSchemas } static var stages: [MigrationStage] { [migrateV100toV101] } // MARK: - V101 static let migrateV100toV101 = MigrationStage.lightweight(fromVersion: SchemaV100.self, toVersion: SchemaV101.self) } SQLDebug logging shows this: CoreData: sql: ALTER TABLE ZHOUSE RENAME TO _T_ZHOUSE CoreData: sql: CREATE TABLE ZHOUSE ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZAUTOMOBILEONE INTEGER, ZCREATEDDATE TIMESTAMP, ZNAME VARCHAR, ZID BLOB ) CoreData: sql: INSERT INTO ZHOUSE (Z_PK,Z_ENT,Z_OPT,ZAUTOMOBILEONE,ZCREATEDDATE,ZNAME,ZID) SELECT Z_PK,Z_ENT,Z_OPT,?,ZCREATEDDATE,ZNAME,ZID FROM _T_ZHOUSE CoreData: details: SQLite bind[0] = nil Seems excessive to recreate table for a simple column rename, but I digress... The curious part is the binding, SQLite bind[0] = nil, where I'd expect the originalName value (e.g. ZAUTOMOBILE) to be used. Any thoughts or explanations would be appreciated. Steve

I have two Models which are defined (simplified) as follows: @Model final class Book { var id: UUID = UUID() var title: String = "" var authors: [Author]? = [] } @Model final class Author { var id: UUID = UUID() var name: String "" @Relationship(inverse: \Book.authors) var books: [Book]? = [] } Both Book.authors and Author.books are defined as optionals to satisfy the requirements of CloudKit, although it is clear from the above that neither is ever actually nil. I am trying to write a #Predicate that finds objects of type Book with a title that matches a specified title and with an author that matches a specified author. The function I'd like to write looks something like this: func find(title: String, author: Author, with context: ModelContext) -> Book? { let same = ComparisonResult.orderedSame let predicate = #Predicate<Book> { book in book.title.caseInsensitiveCompare(title) == same && book.authors!.contains(where: { $0.id == author.id }) } let descriptor = FetchDescriptor<Book>(predicate: predicate) return try? context.fetch(descriptor).first } This function fails to compile inside the expansion of the #Predicate macro with a very long error message: Cannot convert value of type (a long 'PredicateExpresions....') (aka (another log 'PredicateExpressions....')) to closure result type 'any StandardPredicateExpression<Bool>' I don't understand. How can I write this predicate so that it will both compile and work? I know how to work around this problem, but would like to both deepen my understanding of Swift and SwiftData and to avoid the (inelegant) workaround.

Hi, Overview I am finding #Predicate to be a bit tricky when used with Swift Data It compiles fine but crashes at runtime I know the fix for the problem just wondering if such pitfalls can be avoided at compile time Exception *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'can't use NULL on left hand side' terminating due to uncaught exception of type NSException CoreData: error: SQLCore dispatchRequest: exception handling request: <NSSQLFetchRequestContext: 0x11209b000> , can't use NULL on left hand side with userInfo of (null) Questions Could anything be done to improve the safety to avoid such issues at runtime? Could I write the code better (better than the fix below) to avoid this? My thoughts Fix is possible however it wasn't obvious to me that there was a problem with my original code Would be nice to prevent them at compile time if possible. Currently got to be really careful to avoid such crashes. Code import Foundation import SwiftData @Model class Car { var name: String var modelRawValue: String? init(name: String, modelRawValue: String?) { self.name = name self.modelRawValue = modelRawValue } } enum CarModel: String, CaseIterable { case modelA case modelB } func makePredicate(filterModels: [CarModel]?) -> Predicate<Car> { let filterRawValues = filterModels?.map { $0.rawValue } let predicate = #Predicate<Car> { car in if let filterRawValues { if let carModelRawValue = car.modelRawValue { filterRawValues.contains(carModelRawValue) } else { false } } else { true } } return predicate } func fetch(context: ModelContext) throws { let predicate = makePredicate(filterModels: nil) let fetchDescriptor = FetchDescriptor(predicate: predicate) do { let cars = try context.fetch(fetchDescriptor) print(cars.count) } catch { print("Error: \(error)") throw error } } Fix func makePredicate(filterModels: [CarModel]?) -> Predicate<Car> { // Checking nil condition even before creating the predicate fixes the issue guard let filterModels else { return .true } let filterRawValues = filterModels.map { $0.rawValue } let predicate = #Predicate<Car> { car in if let carModelRawValue = car.modelRawValue { filterRawValues.contains(carModelRawValue) } else { false } } return predicate }

I have a Mac and iOS app intended to sync data in iCloud. Both apps in TestFlight, the iOS reads and writes to iCloud but the Mac fails as the App Sandbox denies mach-lookup com.apple.cloudd, so NSCloudKitMirroringDelegate` never reaches the daemon and setup fails permanently. I have a minimal app reproducing the issue on for the Mac app. I also submitted a feedback FB24450529

My SwiftData app (NSPersistentCloudKitContainer mirroring, private database only) cannot save any record to its CloudKit Production environment, for any user. Development works flawlessly for the same devices, accounts, and code. Signature, from CloudKit Console Production logs: every RecordSave to zone com.apple.coredata.cloudkit.zone fails with overallStatus USER_ERROR, error BAD_REQUEST, returnedRecordTypes "_pcs_data". Reads and zone setup succeed in the same sessions (ZoneSave, SubscriptionCreate, DatabaseChanges, ZoneChanges). Zero successful RecordSaves have ever occurred in this container's Production environment. Facts established so far: 4 of 4 users fail identically (my account + 3 TestFlight testers on unrelated iCloud accounts, iPhone and iPad, iOS 26.6/26.6.x) — so this is not one account's Advanced Data Protection key state. Schema was deployed Dev to Production via Console; the Deploy sheet now reports zero pending changes, and Export Schema from BOTH environments yields identical record type sets. _pcs_data appears in neither export — it is a server-managed system type, so there is no developer action (Console or cktool) that can add it to Production. The model declares no encrypted attributes (allowsCloudEncryption appears nowhere). Entitlements verified with codesign on the shipped TestFlight binary: icloud-container-identifiers, icloud-services=CloudKit, production environment — all correct. Client-side the failure is silent: CKAccountStatus is .available, the container initializes, no error surfaces; the mirroring delegate just stops exporting. Tried without effect: reboots, reinstalls, force-quits, per-app iCloud toggles; storage has ample headroom. This matches the signature in thread 838743 (FB23731287, FB24150787), where multiple developers report the same behavior, unresolved. Filed as FB24378074, which now carries: a CloudKit-profile sysdiagnose captured during a timestamped reproduction, the matching server-side requestId/operationId for that exact save (9265D1CA-86BF-4CEB-A432-43F3F39C891E / A2A2B0F98B389DF8), schema exports from both environments, and a full fault-elimination audit. Question for DTS: what makes a Production environment reject _pcs_data record saves that Development accepts, and what is the supported path to repair this container's Production PCS handling? A live TestFlight beta (a family app; device-to-device sync fully down for all users) is waiting on this. Happy to run further diagnostics on request — a minimal repro project against a fresh container is prepared. Case-ID: 21696635

I have an existing CoreData + CloudKit app which I would like to migrate to SwiftData + CloudKit. In the existing CoreData implementation, I have many optional fields (most of which have default values). I want to migrated them to SwiftData non-optional fields with default values. Can someone please confirm that I can do this without causing issues for my existing (CoreData + CloudKit) customers? I.e., I know I can do the migration on the local copy of the database, but I am worried about the CloudKit interaction. Specifically, I'm concerned about properties such as var title: String? which is implemented in CloudKit as CD_title CD_title_ckAsset Can I safely implement this in SwiftData as var title: String = "" without causing a problem with the CloudKit implementation?

Most documentation on the web indicates that SwiftData Model instances are not Sendable. However, the current Xcode (Version 27.0 beta 5 (27A5237l)) indicates that @Model is Sendable. Is this a new feature in 2027 or is it an error in the documentation? @attached(member, conformances: Observable, PersistentModel, Sendable, names: named($backingData), named(persistentBackingData), named(schemaMetadata), named(init), named($observationRegistrar), named(_SwiftDataNoType), named(access), named(withMutation)) @attached(memberAttribute) @attached(extension, conformances: Observable, PersistentModel, Sendable) macro Model() I noticed this in the Quick Help as I was about to quit and go to bed. I'll check on this thread again after I wake up. If no answers I'll try writing a test case.

The traditional way to initialize a SwiftData app looks like some variation of the following: @main struct TrainingCornerApp: App { let dbSchema: Schema = ... init() { } var body: some Scene { WindowGroup { MainAppScreen() .modelContainer(modelContainer) } } } private var modelContainer: ModelContainer { let container: ModelContainer let modelConfiguration = ModelConfiguration(schema: dbSchema, isStoredInMemoryOnly: false, cloudKitDatabase: .automatic) do { container = try ModelContainer(for: dbSchema, migrationPlan: MigrationPlan.self, configurations: [modelConfiguration]) } catch { fatalError("Failed to create model container: \(error.localizedDescription)") } return container } } That is, if creating the modelContainer fails, the app aborts with a fatalError. What I want to do is have the application present an alert message for the user before terminating. (Let the user know the app can't run and suggest how to get help -- that sort of thing.) However, I've been having a hard time getting this to work, and it seems that the problems are related to trying to generate the alert at such an early stage in app startup. Does anyone have ideas/suggestions on how I might do this?

I have an Apple app that uses SwiftData and icloud to sync the App's data across users' devices. Everything is working well. However, I am facing the following issue: SwiftData does not support public sharing of the object graph with other users via iCloud. How can I overcome this limitation without stopping using SwiftData? Thanks in advance!

Hi everyone, I'm Alexsander. My friends call me Lexie. I have been working as software developer since 6 years ago, I have a lot of experience with Java and I started working with Angular since the last year. I am new in the Apple ecosystem and I have a question about best practices in full native Swift apps. There is any source (blogs, youtube channels, books, et al.) where I can understand the best practices? Like, I've heard about MVVM to scalable apps but I don't know exactly how to apply it. I think it's because usually I do not have my front-end components in the same project of my backend. I've been watching some videos from Apple Developer youtube channel and they are absolutely amazing, but they only keep teaching people to use the "raw" resources, not matching with the best practices. For example, I saw using swift data we do not need to write any SQL Query, unlike Java Ecossystem where even we use a ORM we usually write our queries natively, whether creating a table or fetching data.

I have a SwiftUI + SwiftData app where scrolling became very slow, and I've traced it to something about @Query I didn't expect. The app was running save for each lazy list item appearing in viewport (a separate bug, but it did highlight the problem), which made the whole list re-render on each save. After tracing why this happens I have discovered that it is because another model watched in the list parent is invalidated after every save, and the problem was that this another model has @Query in a separate view (sidebar), removing that @Query fixed the problem. Here is a minimal reproduction of this https://github.com/aytigra/QueryRefaultRepro I wonder if it is a bug or an expected behavior?

I would very much like to store some additional data in my SwiftData document package, outside of SwiftData. Metadata about the document that doesn't lend itself well to the underlying RDBMS nature of SwiftData. Is that possible?

My scenario I have an app which stores data using SwiftData / CloudKit automatic sync It works as expected on iOS, sync happens even when the app is closed. On Mac, when mac app is closed the data from the CloudKit is not pulled into the DB. It would be nice if the widget on the Mac is updated even when the Mac app is closed. Like from a sync from an iPhone. My problem: I don't do anything for sync other than just initializing the ModelContainer and everything is taken care of. The local store has its own system level tables to maintain the sync states. So I am a bit hesitant to do a separate sync in the background process (LoginItem / LaunchAgent / LaunchDaemon. I need to read a lot on this because I am just beginning to explore this part Questions Is it feasible / advisable to have one instance of the ModelContainer created in the background process and access it in the main app for the Mac? Reason for asking is because ModelContainer is the one that does all the sync magically. Or is this too much of an overhead and users can open the app to keep the widget updated?

I have a production app that originally used Core Data + CloudKit and was later migrated to SwiftData. The SwiftData migration preserved the existing SQLite store by explicitly pointing ModelConfiguration at the original database: let configuration = ModelConfiguration(url: storeURL) let container = try ModelContainer(for: schema, configurations: configuration) Because of this, my app does not use the higher-level ModelConfiguration(groupContainer:cloudKitDatabase:) initializer. I would now like to migrate the store into an App Group so it can be shared with widgets. During the WWDC26 SwiftData Group Lab (around 18:53), the guidance was: Moving to an App Group container is more involved: it's a different directory and entitlements can't be aligned to the old location, so you'll get a new container and must copy the existing data over into the group container, then start from there. However, I couldn't find documentation describing how Apple recommends performing that copy for a SwiftData application that already uses an explicit SQLite URL. Why the Core Data APIs don't seem applicable The obvious approach would be to use Core Data APIs such as: replacePersistentStore migratePersistentStore However, these APIs require a Core Data stack and a managed object model (.momd). After migrating completely to SwiftData, I no longer have a .momd in my project, so creating an NSPersistentContainer solely to move an existing SQLite store doesn't appear to be possible. Is there a supported way to use these APIs with a SwiftData store, or are they no longer intended for this scenario? Experiment Since the migration happens before creating the ModelContainer, I experimented with simply moving the entire persistence package using FileManager before SwiftData is initialized. Specifically I move: Store.sqlite Store.sqlite-wal Store.sqlite-shm .Store_SUPPORT Store_ckAssets from the application's Application Support directory into the App Group container, and then initialize SwiftData using: let configuration = ModelConfiguration(url: appGroupStoreURL) let container = try ModelContainer(for: schema, configurations: configuration) After doing this: all existing data is present; new data can be created successfully; if I run an older build that still points to Application Support, SwiftData simply creates a brand-new empty store there, which suggests the original store was indeed moved successfully. So from a local persistence perspective, this appears to work. Remaining concern Although this approach appears to preserve the SQLite store unchanged, I don't know whether it is actually safe for CloudKit. Specifically: Does moving the complete persistence package with FileManager preserve all CloudKit metadata needed for continued synchronization? Is there any risk that CloudKit will treat the moved store as a different store and re-upload or duplicate records? Are there additional files or directories that must also be moved besides: Store.sqlite Store.sqlite-wal Store.sqlite-shm .Store_SUPPORT Store_ckAssets Is there an Apple-recommended migration path for this scenario that avoids introducing a temporary Core Data model purely to move the store? In other words: What is the recommended migration path for an existing production SwiftData application using an explicit SQLite URL to move into an App Group while continuing to use CloudKit? One additional question The SwiftData documentation provides two different ways to configure persistent storage: ModelConfiguration( groupContainer: ..., cloudKitDatabase: ... ) and ModelConfiguration( url: ..., cloudKitDatabase: ... ) My understanding is that when using the groupContainer initializer, SwiftData may automatically handle moving the persistent store into the App Group when the application is updated. However, when using the url initializer, the application is explicitly responsible for choosing the store location. Is that understanding correct? If so: Is there any supported automatic migration mechanism when using ModelConfiguration(url:), or is manual migration expected? If manual migration is expected, is moving the complete persistence package (.sqlite, -wal, -shm, .Store_SUPPORT, Store_ckAssets) before creating the ModelContainer the recommended approach? Or is there another Apple-recommended migration path for this scenario? My related posts/questions https://developer.apple.com/forums/thread/769835 https://developer.apple.com/forums/thread/769676

Hello, I am trying to set up Widgets in my app. I want to fetch my data in the SwiftData container that is shared between my app and my WidgetExtension with App Group. let modelContext = ModelContext(modelContainer) let predicate = #Predicate<Test>{ return $0.attribute == true } return try modelContext.fetch(FetchDescriptor (predicate: predicate, sortBy: [SortDescriptor(\Test.name)])) When this code is run in my WidgetExtension, returned objects attributes values are replaced with "" string. In the logs, Swift Data writes Query returned unrequested identifiers that have been dropped: <private> Any idea what I might be doing wrong to share my SwiftData between my App and my Widget? App Groups capability has been added to both apps and extension with the same identifier. Thank you

I believe I may have found a SwiftData persistence bug, but I'd like to verify that I'm not overlooking a documented limitation before filing Feedback. This minimal example appears to lose precision when persisting a Decimal: import Foundation import SwiftData @Model class Item { var value: Decimal init(_ value: Decimal) { self.value = value } } let original = Decimal(string: "123456789012345.6")! let container = try ModelContainer( for: Item.self, configurations: .init(isStoredInMemoryOnly: true) ) let context = ModelContext(container) context.insert(Item(original)) try context.save() let fetched = try ModelContext(container) .fetch(FetchDescriptor<Item>()) .first! print(original) print(fetched.value) Output: 123456789012345.6 123456789012346 A few observations from additional testing: Decimal(string:) preserves the value before persistence. Decimal ↔ NSDecimalNumber bridging preserves the value in separate tests. The value remains exact after model initialization, insertion, and save() on the registered object. The first Swift-visible precision loss appears after fetching from a new ModelContext. As a control, I repeated the test using Core Data with an NSInMemoryStoreType store and an NSDecimalAttributeType attribute. That round-tripped the tested values exactly. Inspecting the SQLite store generated by SwiftData showed the affected value stored as a REAL. At this point it appears the precision loss occurs somewhere in the SwiftData/Core Data persistence pipeline rather than in Decimal itself. Can anyone reproduce this, or is there a documented limitation on Decimal persistence in SwiftData that I have missed? If this is expected behavior, what is the recommended way to persist exact decimal values for financial applications?

I believe I may have found a SwiftData persistence bug, but I'd like to verify that I'm not overlooking a documented limitation before filing Feedback. This minimal example appears to lose precision when persisting a Decimal: import Foundation import SwiftData @Model class Item { var value: Decimal init(_ value: Decimal) { self.value = value } } let original = Decimal(string: "123456789012345.6")! let container = try ModelContainer( for: Item.self, configurations: .init(isStoredInMemoryOnly: true) ) let context = ModelContext(container) context.insert(Item(original)) try context.save() let fetched = try ModelContext(container) .fetch(FetchDescriptor<Item>()) .first! print(original) print(fetched.value) Output: 123456789012345.6 123456789012346 A few observations from additional testing: Decimal(string:) preserves the value before persistence. Decimal ↔ NSDecimalNumber bridging preserves the value in separate tests. The value remains exact after model initialization, insertion, and save() on the registered object. The first Swift-visible precision loss appears after fetching from a new ModelContext. As a control, I repeated the test using Core Data with an NSInMemoryStoreType store and an NSDecimalAttributeType attribute. That round-tripped the tested values exactly. Inspecting the SQLite store generated by SwiftData showed the affected value stored as a REAL. At this point it appears the precision loss occurs somewhere in the SwiftData/Core Data persistence pipeline rather than in Decimal itself. Can anyone reproduce this, or is there a documented limitation on Decimal persistence in SwiftData that I have missed? If this is expected behavior, what is the recommended way to persist exact decimal values for financial applications?

Hi, Overview I have an app that is available on iOS, macOS, visionOS. I should be able to differentiate between device 1 and device 2 I only care about my app Purpose: For core data / swift data history tracking I would like which device wrote the data Question How do I get a unique id that will differentiate my app running on device 1 vs device2? How do I do it for iOS / macOS and visionOS? Or is my approach wrong?

Hi, I'm trying out new SwiftData in a small Xcode project. It seems that the property observers didSet and willSet don't work anymore for swift data anymore. In code like this, the didSet does nothing and seems to never be called. @Model public final class importConfig: Identifiable, ObservableObject{ @Attribute(.unique) public var id: UUID /// Name of the configuration var configName: String /// Numbers App document to open var numbersFilePath: URL? /// Indicate wether current <numbersFilePath> Numbers App document has been loaded and analyzed var isLoaded: Bool = false /// Current selected sheet var selectedSheetID: UUID? { didSet { selectedSheetID = nil print("test") } } } Am I doing something wrong or is it the expected behavior ? If it is the expected behavior, how can I add "business" rules when setting/unsetting value to model properties ? I tried to add rules directly with .onchange() in my views, but this way I have to repeat the same rules/code. Is there any alternative to do so ? Thank you