If Cloudkit is enabled, SwiftData @Query operation hangs when the View scenePhase becomes active. Seems like the more @Query calls you have, the more it hangs. This has been first documented some time ago, but in typical Apple style, it has not been addressed or even commented on. https://developer.apple.com/forums/thread/761434

Trying to support undo & redo in an app that utilizes Swift Data and as with anything other than provided simplistic Apple demo examples the experience is not great. The problem: Im trying to build functionality that allows users to add items to an item group, where item and item group have a many-to-many relationship e.g. item group can hold many items and items can appear in multiple groups. When trying to do so with relatively simple setup of either adding or removing item group from items relationship array, I am pretty consistently met with a hard crash after performing undo & redo. Sometimes it works the first few undo & redos but 95% of the time would crash on the first one. Could not cast value of type 'Swift.Optional<Any>' (0x20a676be0) to 'Swift.Array<App.CodableStructModel>' (0x207a2bc08). Where CodableStructModel is a Codable Value type inside Item. Adding and removing this relationship should be undoable & redoable as typical for Mac interaction and is "supported" by SwiftData by default, meaning that the developer has to actively either wholly opt out of undo support in their modelContainer setup or do it on a per action scale with the only thing I know of: modelContext.processPendingChanges() modelContext.undoManager?.disableUndoRegistration() ..... modelContext.processPendingChanges() modelContext.undoManager?.enableUndoRegistration() General rant on SwiftData: Random crashes, inconsistencies, random cryptic errors thrown by the debugger and general lack of production level stability. Each update breaks something new and there is very little guidance and communication from the Swift Data team on how to adapt and more importantly consideration for developers that have adopted Swift Data. If SwiftData is not ready for production, it would go a long way to clearly communicate that and mark it as Beta product.

I have implemented CKSyncEngine synchronization, and it works well. I can update data on one device and see the changes propagate to another device quickly. However, the initial sync when a user downloads the app on a new device is a significant issue for both me and my users. One problem is that the sync engine fetches deletion events from the server. On a new device, the local database is empty, so these deletions are essentially no-ops. This would not be a big problem if there were only a few records or if it was fast. I measured the initial sync and found that there are 150 modified records and 62,168 deletions. Counting these alone takes over five minutes, even without processing them. The deletions do nothing because the local database has nothing to delete, yet they still add a significant delay. I understand that the sync engine ensures consistency across all devices, but five minutes of waiting with the app open just to insert a small number of records is excessive. The problem would be worse if there were tens of thousands of new records to insert, since downloading and saving the data would take even longer. This leads to a poor user experience. Users open the app and see data being populated for several minutes, or they are stuck on a screen that says the data is being synchronized with iCloud. I am wondering if there is a way to make the sync engine ignore deletion events when the state serialization is nil. Alternatively, is there a recommended method for handling initial synchronization more efficiently? One idea I considered is storing all the data as a backup in iCloud Documents, along with the state serialization at that point in time. When a user opens the app for the first time, I could download the file, extract the data, and set the state serialization to the saved value. I am not sure if this would work. I do not know if state serialization is tied to the device or if it only represents the point where the sync engine left off. My guess is that it might reference some local device storage. I am not sure what else to try. I could fetch all data using CloudKit, create the sync engine with an empty state serialization, and let it fetch everything again, but that would still take a long time. My records are very small, mostly a date when something happened and an ID referencing the parent. Since the app tracks watched episodes, I only store the date the user watched the episode and the ID of that episode.

Hi there, I got two models here: Two Models, with Many-To-Many Relationship @Model final class PresetParams: Identifiable { @Attribute(.unique) var id: UUID = UUID() var positionX: Float = 0.0 var positionY: Float = 0.0 var positionZ: Float = 0.0 var volume: Float = 1.0 @Relationship(deleteRule: .nullify, inverse: \Preset.presetAudioParams) var preset = [Preset]() init(position: SIMD3<Float>, volume: Float) { self.positionX = position.x self.positionY = position.y self.positionZ = position.z self.volume = volume self.preset = [] } var position: SIMD3<Float> { get { return SIMD3<Float>(x: positionX, y: positionY, z: positionZ) } set { positionX = newValue.x positionY = newValue.y positionZ = newValue.z } } } @Model final class Preset: Identifiable { @Attribute(.unique) var id: UUID = UUID() var presetName: String var presetDesc: String? var presetAudioParams = [PresetParams]() // Many-To-Many Relationship. init(presetName: String, presetDesc: String? = nil) { self.presetName = presetName self.presetDesc = presetDesc self.presetAudioParams = [] } } To be honest, I don't fully understand how the @Relationship thing works properly in a Many-To-Many relationship situation. Some tutorials suggest that it's required on the "One" side of an One-To-Many Relationship, while the "Many" side doesn't need it. And then there is an ObservableObject called "ModelActors" to manage all ModelActors, ModelContainer, etc. ModelActors, ModelContainer... class ModelActors: ObservableObject { static let shared: ModelActors = ModelActors() let sharedModelContainer: ModelContainer private init() { var schema = Schema([ // ... Preset.self, PresetParams.self, // ... ]) do { sharedModelContainer = try ModelContainer(for: schema, migrationPlan: MigrationPlan.self) } catch { fatalError("Could not create ModelContainer: \(error.localizedDescription)") } } } And there is a migrationPlan: MigrationPlan // MARK: V102 // typealias ... // MARK: V101 typealias Preset = AppSchemaV101.Preset typealias PresetParams = AppSchemaV101.PresetParams // MARK: V100 // typealias ... enum MigrationPlan: SchemaMigrationPlan { static var schemas: [VersionedSchema.Type] { [ AppSchemaV100.self, AppSchemaV101.self, AppSchemaV102.self, ] } static var stages: [MigrationStage] { [AppMigrateV100toV101, AppMigrateV101toV102] } static let AppMigrateV100toV101 = MigrationStage.lightweight(fromVersion: AppSchemaV100.self, toVersion: AppSchemaV101.self) static let AppMigrateV101toV102 = MigrationStage.lightweight(fromVersion: AppSchemaV101.self, toVersion: AppSchemaV102.self) } // MARK: Here is the AppSchemaV101 enum AppSchemaV101: VersionedSchema { static var versionIdentifier: Schema.Version = Schema.Version(1, 0, 1) static var models: [any PersistentModel.Type] { return [ // ... Preset.self, PresetParams.self ] } } Fails on iOS 18.3.x: "Failed to fulfill link PendingRelationshipLink" So I expected the SwiftData subsystem to work correctly with version control. A good news is that on iOS 18.1 it does work. But it fails on iOS 18.3.x with a fatal Error: "SwiftData/SchemaCoreData.swift:581: Fatal error: Failed to fulfill link PendingRelationshipLink(relationshipDescription: (<NSRelationshipDescription: 0x30377fe80>), name preset, isOptional 0, isTransient 0, entity PresetParams, renamingIdentifier preset, validation predicates (), warnings (), versionHashModifier (null)userInfo {}, destination entity Preset, inverseRelationship (null), minCount 0, maxCount 0, isOrdered 0, deleteRule 1, destinationEntityName: "Preset", inverseRelationshipName: Optional("presetAudioParams")), couldn't find inverse relationship 'Preset.presetAudioParams' in model" Fails on iOS 17.5: Another Error I tested it on iOS 17.5 and found another issue: Accessing or mutating the "PresetAudioParams" property causes the SwiftData Macro Codes to crash, affecting both Getter and Setter. It fails with an error: "EXC_BREAKPOINT (code=1, subcode=0x1cc1698ec)" Tweaking the @Relationship marker and ModelContainer settings didn't fix the problem.

I'm trying to build a custom FetchRequest that I can use outside a View. I've built the following ObservableFetchRequest class based on this article: https://augmentedcode.io/2023/04/03/nsfetchedresultscontroller-wrapper-for-swiftui-view-models @Observable @MainActor class ObservableFetchRequest&lt;Result: Storable&gt;: NSObject, @preconcurrency NSFetchedResultsControllerDelegate { private let controller: NSFetchedResultsController&lt;Result.E&gt; private var results: [Result] = [] init(context: NSManagedObjectContext = .default, predicate: NSPredicate? = Result.E.defaultPredicate(), sortDescriptors: [NSSortDescriptor] = Result.E.sortDescripors) { guard let request = Result.E.fetchRequest() as? NSFetchRequest&lt;Result.E&gt; else { fatalError("Failed to create fetch request for \(Result.self)") } request.predicate = predicate request.sortDescriptors = sortDescriptors controller = NSFetchedResultsController(fetchRequest: request, managedObjectContext: context, sectionNameKeyPath: nil, cacheName: nil) super.init() controller.delegate = self fetch() } private func fetch() { do { try controller.performFetch() refresh() } catch { fatalError("Failed to fetch results for \(Result.self)") } } private func refresh() { results = controller.fetchedObjects?.map { Result($0) } ?? [] } var predicate: NSPredicate? { get { controller.fetchRequest.predicate } set { controller.fetchRequest.predicate = newValue fetch() } } var sortDescriptors: [NSSortDescriptor] { get { controller.fetchRequest.sortDescriptors ?? [] } set { controller.fetchRequest.sortDescriptors = newValue.isEmpty ? nil : newValue fetch() } } internal func controllerDidChangeContent(_ controller: NSFetchedResultsController&lt;any NSFetchRequestResult&gt;) { refresh() } } Till this point, everything works fine. Then, I conformed my class to RandomAccessCollection, so I could use in a ForEach loop without having to access the results property. extension ObservableFetchRequest: @preconcurrency RandomAccessCollection, @preconcurrency MutableCollection { subscript(position: Index) -&gt; Result { get { results[position] } set { results[position] = newValue } } public var endIndex: Index { results.endIndex } public var indices: Indices { results.indices } public var startIndex: Index { results.startIndex } public func distance(from start: Index, to end: Index) -&gt; Int { results.distance(from: start, to: end) } public func index(_ i: Index, offsetBy distance: Int) -&gt; Index { results.index(i, offsetBy: distance) } public func index(_ i: Index, offsetBy distance: Int, limitedBy limit: Index) -&gt; Index? { results.index(i, offsetBy: distance, limitedBy: limit) } public func index(after i: Index) -&gt; Index { results.index(after: i) } public func index(before i: Index) -&gt; Index { results.index(before: i) } public typealias Element = Result public typealias Index = Int } The issue is, when I update the ObservableFetchRequest predicate while searching, it causes a Index out of range error in the Collection subscript because the ForEach loop (or a List loop) access a old version of the array when the item property is optional. List(request, selection: $selection) { item in VStack(alignment: .leading) { Text(item.content) if let information = item.information { // here's the issue, if I leave this out, everything works Text(information) .font(.callout) .foregroundStyle(.secondary) } } .tag(item.id) .contextMenu { if Item.self is Client.Type { Button("Editar") { openWindow(ClientView(client: item as! Client), id: item.id!) } } } } Is it some RandomAccessCollection issue or a SwiftUI bug?

Greetings i have an app that uses three different SwiftData models and i want to know what is the best way to use the them accross the app. I though a centralized behaviour and i want to know if it a correct approach.First let's suppose that the first view of the app will load the three models using the @Enviroment that work with @Observation. Then to other views that add data to the swiftModels again with the @Environment. Another View that will use the swiftData models with graph and datas for average and min and max.Is this a corrent way? or i should use @Query in every view that i want and ModelContext when i add the data. @Observable class CentralizedDataModels { var firstDataModel: [FirstDataModel] = [] var secondDataModel: [SecondDataModel] = [] var thirdDataModel: [ThirdDataModel] = [] let context: ModelContext init(context:ModelContext) { self.context = context } }

Hello everyone, I'm trying to adopt the new Staged Migrations for Core Data and I keep running into an error that I haven't been able to resolve. The error messages are as follows: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'Movie' so +entity is unable to disambiguate. warning: 'Movie' (0x60000350d6b0) from NSManagedObjectModel (0x60000213a8a0) claims 'Movie'. error: +[Movie entity] Failed to find a unique match for an NSEntityDescription to a managed object subclass This happens for all of my entities when they are added/fetched. Movie is an abstract entity subclass, and it has the error error: +[Movie entity] Failed to find which is unique to the subclass entities, but this occurs for all entities. The NSPersistentContainer is loaded only once, and I set the following option after it's loaded: storeDescription.setOption( [stages], forKey: NSPersistentStoreStagedMigrationManagerOptionKey ) The warnings and errors only appear after I fetch or save to context. It happens regardless of whether the database was migrated or not. In my test project, using the generic NSManagedObject with NSEntityDescription.insertNewObject(forEntityName: "MyEntity", into: context) does not cause the issue. However, using the generic NSManagedObject is not a viable option for my app. Setting the module to "Current Project Module" doesn't change anything, except that it now prints "claims 'MyModule.Show'" in the warnings. I have verified that there are no other entities with the same name or renameIdentifier. Has anyone else encountered this issue, or can offer any suggestions on how to resolve it? Thanks in advance for any help!

I'm testing CloudKit Sharing (CKShare) in my app. My app uses CloudKit Sharing to share private data between users (this is not App Store Family Sharing or purchase sharing, it's app-level sharing via CKShare). To properly test this, I need three or four Apple Accounts with distinct roles in my app. This means I need three/four separate iCloud accounts signed in on test devices. Simulators are probably ok: two acting as "parents" (share owner and participant): parent1.sandbox@example.com parent2.sandbox@example.com, one or two as a "child" (participant) child1.sandbox@example.com child2.sandbox@example.com except obviously using my domain name. I attempted to create Sandbox Apple Accounts in App Store Connect, but these don't appear to work with CloudKit Sharing. I then created several standard Apple Accounts, but I've now hit a limit — I believe my mobile number (used for two-factor authentication on the test accounts) has been flagged or rate-limited for account creation, and I can no longer create or verify new accounts with it. It's also blocked the email addresses associated with those accounts from being used for new account creation. Can Apple or anyone advise on the recommended approach for testing CloudKit Sharing with multiple participants? are Sandbox accounts supposed to work for CKShare, or do I need full Apple Accounts? How do i create and verify these in the correct way to avoid hitting these limits or breaking terms of service?

I have an iOS app using SwiftData with VersionedSchema. The schema is synchronized with an CloudKit container. I previously introduced some model properties that I have now removed, as they are no longer needed. This results in the current schema version being identical to one of the previous ones (except for its version number). This results in the following exception: 'NSInvalidArgumentException', reason: 'Duplicate version checksums across stages detected.' So it looks like we cannot have a newer schema version with an identical content to an older schema version. The intuitive way would be to re-add the old (identical) schema version to the end of the "schemas" list property in the SchemaMigrationPlan, in order to signal that it is the newest one, and to add a migration stage back to it, thus: public enum MySchemaMigrationPlan: SchemaMigrationPlan { public static var schemas: [any VersionedSchema.Type] { [ SchemaV100.self, SchemaV101.self, SchemaV100.self ] } public static var stages: [MigrationStage] { [ migrateV100toV101, migrateV101toV100 ] } However, I am not sure if this is the right way to go, as previously, as I wanted to write unit tests for schema migration and rollback, I tried defining an inverse for each migration stage, so that I could trigger a migration and a rollback from a unit test, which resulted in an exception saying that it is not supported to downgrade a VersionedSchema. I must admit that I solved the original problem by introducing a dummy model property that I will later remove. What would have been the correct approach?

Hi everyone, I am experiencing an iCloud provisioning problem I cannot resolve, and Developer Support has not been able to help. My App ID: com.exaqservices.ArkyvTiles Symptoms: 1. In Xcode (v16.2), enabling iCloud in Signing & Capabilities repeatedly fails with: The app ID does not include the iCloud container. Click Try Again. Clicking Try Again does nothing. The error persists forever. 2. In Certificates, Identifiers & Profiles: • The iCloud capability is enabled for this App ID. • The CloudKit container is selected. • But the portal no longer shows the “iCloud Documents” checkbox, which used to be required for ubiquitous document support. 3. Xcode cannot regenerate provisioning profiles because it claims the App ID is missing the iCloud container — even though the container is attached. 4. Provisioning profiles on the Apple Developer site all appear expired, and new ones do not generate correctly. 5. The App Store Connect interface also does not show an iCloud Services section under App Information → Capabilities as older guides describe. Expected Behavior: Since iCloud and the CloudKit container are enabled on the App ID, Xcode should successfully enable: • com.apple.developer.icloud-services • com.apple.developer.icloud-container-identifiers • com.apple.developer.ubiquity-container-identifiers (if needed) • com.apple.developer.ubiquity-kvstore-identifier Instead, the entitlements never propagate. What I suspect: This seems like an App ID metadata mismatch or a stale backend entry where: • the CloudKit container is attached but the entitlement isn’t linked, • the “iCloud Documents” flag is missing due to a UI transition, • provisioning profiles cannot be regenerated because the App ID is not updating correctly. What I need help with: Can someone from Apple engineering confirm: • Whether my App ID metadata is corrupted, • If entitlements need to be manually refreshed, • Or if the “iCloud Documents” toggle has moved or is no longer exposed? This is blocking development completely — I cannot build, sign, or deploy the app with iCloud. Thank you! Alan Metzger

The app works on a local db but when I try to make it work with iCloud I get errors that I don't understand. CoreData+CloudKit: -[NSCloudKitMirroringDelegate _performSetupRequest:]_block_invoke(1247): <NSCloudKitMirroringDelegate: 0x10664c200>: Failed to set up CloudKit integration for store: <NSSQLCore: 0x106688140> (URL: file:///var/mobile/Containers/Data/Application/20EF350F-F0FA-4132-97DA-61B60AADB101/Library/Application%20Support/default.store) <CKError 0x109430e40: "Partial Failure" (2/1011); "Failed to modify some record zones"; uuid = 82ED152A-D015-414D-BB79-AF36E5AF4A8B; container ID = "iCloud.se.Grindegard.MinaRecept"; partial errors: { com.apple.coredata.cloudkit.zone:defaultOwner = <CKError 0x109431230: "Permission Failure" (10/2007); server message = "Invalid bundle ID for container"; op = E56A3CDA393641F8; uuid = 82ED152A-D015-414D-BB79-AF36E5AF4A8B> }> what can be wrong?

We have an unreleased SwiftData app for iOS18+. While we were testing I saw reports on the forum about unexpected database migrations for codable arrays on iOS26.1. I'd like to ask a couple of questions: 1- Does this issue originate from the new Xcode version, or is it specific to iOS 26.1? 2- Is it possible to change our attribute so that users on older iOS versions receive the same model, preventing a migration from being triggered when they upgrade to iOS 26.1? One of our models looks like this: struct Point: Codable, Hashable { let x: Int let y: Int } @Model class Grid { private(set) var gridId: String = "" var points: [Point] = [] var updatedAt: Date = Date() private(set) var createdAt: Date = Date() #Index<Grid>([\.gridId]) ... } I can think of some options like: // 1 @Attribute(.transformable(by: CustomJsonTransformer.self)) var points: [Point] = [] // 2 @Attribute(.externalStorage) var points: [Point] = [] // 3 var points: Data = Data() // store points as data However, I'm not sure which one to use. What would you recommend to handle this, or is there a better strategy you would suggest?

I’m trying to build a CRUD app using SwiftData, @Query model and multidatepicker. The data from a multidatepicker is stored or persists in SwiftData as Set = []. My current dilemma is how to use SwiftData and @Query model Predicate to find all records on the current date. I can’t find any SwiftData documentation or examples @Query using Set = []. My CRUD app should retrieve all records for the current date. Unfortunately, I don’t know the correct @Query model syntax for Set = [].

I'm writing some tests to confirm the behavior of my app. White creating a model actor to delete objects I realized that ModelContext.model(for:) does return objects that are deleted. I was able to reproduces this with this minimal test case: @Model class Activity { init() {} } struct MyLibraryTests { let modelContainer = try! ModelContainer( for: Activity.self, configurations: ModelConfiguration( isStoredInMemoryOnly: true ) ) init() throws { let context = ModelContext(modelContainer) context.insert(Activity()) try context.save() } @Test func modelForIdAfterDelete() async throws { let context = ModelContext(modelContainer) let id = try context.fetch(FetchDescriptor<Activity>()).first!.id context.delete(context.model(for: id) as! Activity) try context.save() let result = context.model(for: id) as? Activity #expect(result == nil) // Expectation failed: (result → MyLibrary.Activity) == nil } @Test func fetchDescriptorAfterDelete() async throws { let context = ModelContext(modelContainer) let id = try context.fetch(FetchDescriptor<Activity>()).first!.id context.delete(context.model(for: id) as! Activity) try context.save() let result = try context.fetch( FetchDescriptor<Activity>(predicate: #Predicate { $0.id == id }) ).first #expect(result == nil) } } Here I create a new context, insert an model and save it. The test modelForIdAfterDelete does fail, as result still contains the deleted object. I also tried to check #expect(result!.isDeleted), but it is also false. With the second test I use a FetchDescriptor to retrieve the object by ID and it correctly returns nil. Shouldn't both methods use a consistent behavior?

I'm experiencing the following error with my SwiftData container when running a build: Code=134504 "Cannot use staged migration with an unknown model version." Code Structure - Summary I am using a versionedSchema to store multiple models in SwiftData. I started experiencing this issue when adding two new models in the newest Schema version. Starting from the current public version, V4.4.6, there are two migrations. Migration Summary The first migration is to V4.4.7. This is a lightweight migration removing one attribute from one of the models. This was tested and worked successfully. The second migration is to V5.0.0. This is a custom migration adding two new models, and instantiating instances of the two new models based on data from instances of the existing models. In the initial testing of this version, no issues were observed. Issue and Steps to Reproduce Reproduction of issue: Starting from a fresh build of the publicly released V4.4.6, I run a new build that contains both Schema Versions (V4.4.7 and V5.0.0), and their associated migration stages. This builds successfully, and the container successfully migrates to V5.0.0. Checking the default.store file, all values appear to migrate and instantiate correctly. The second step in reproduction of the issue is to simply stop running the build, and then rebuild, without any code changes. This fails to initialize the model container every time afterwards. Going back to the simulator after successive builds are stopped in Xcode, the app launches and accesses/modifies the model container as normal. Supplementary Issue: I have been putting up with the same, persistent issue in the Xcode Preview Canvas of "Failed to Initialize Model Container" This is a 5 in 6 build issue, where builds will work at random. In the case of previews, I have cleared all data associated with all previews multiple times. The only difference being that the simulator is a 100% failure rate after the initial, successful initialization. I assume this is due to the different build structure of previews. Lastly, of note, the Xcode previews fail at the same line in instantiating the model container as the simulator does. From my research into this issue, people say that the Xcode preview is instantiating from elsewhere. I do have a separate model container set up specifically for canvas previews, but the error does not occur in that container, but rather the app's main container. Possible Contributing Factors & Tested Facts iOS: While I have experienced issues with SwiftData and the complier in iOS 26, I can rule that out as the issue here. This has been tested on simulators running iOS 18.6, 26.0.1, and 26.1, all encountering failures to initialize model container. While in iOS 18, subsequent builds after the successful migration did work, I did eventually encounter the same error and crash. In iOS 26.0.1 and 26.1, these errors come immediately on the second build. Container Initialization for V4.4.6 do { container = try ModelContainer( for: Job.self, JobTask.self, Day.self, Charge.self, Material.self, Person.self, TaskCategory.self, Service.self, migrationPlan: JobifyMigrationPlan.self ) } catch { fatalError("Failed to Initialize Model Container") } Versioned Schema Instance for V4.4.6 (V4.4.7 differs only by versionIdentifier) static var versionIdentifier = Schema.Version(4, 4, 6) static var models: [any PersistentModel.Type] { [Job.self, JobTask.self, Day.self, Charge.self, Material.self, Person.self, TaskCategory.self, Service.self] } Container Initialization for V5.0.0 do { let schema = Schema([Jobify.self, JobTask.self, Day.self, Charge.self, MaterialItem.self, Person.self, TaskCategory.self, Service.self, ServiceJob.self, RecurerRule.self]) container = try ModelContainer( for: schema, migrationPlan: JobifyMigrationPlan.self ) } catch { fatalError("Failed to Initialize Model Container") } Versioned Schema Instance for V5.0.0 static var versionIdentifier = Schema.Version(5, 0, 0) static var models: [any PersistentModel.Type] { [ JobifySchemaV500.Job.self, JobifySchemaV500.JobTask.self, JobifySchemaV500.Day.self, JobifySchemaV500.Charge.self, JobifySchemaV500.Material.self, JobifySchemaV500.Person.self, JobifySchemaV500.TaskCategory.self, JobifySchemaV500.Service.self, JobifySchemaV500.ServiceJob.self, JobifySchemaV500.RecurerRule.self ] } Addressing Differences in Object Names Type-aliasing: All my model types are type-aliased for simplification in view components. All types are aliased as 'JobifySchemeV446.<#Name#>' in V.4.4.6, and 'JobifySchemaV500.<#Name#>' in V5.0.0 Issues with iOS 26: My type-aliases dating back to iOS 17 overlapped with lower level objects in Swift, including 'Job' and 'Material'. These started to be an issue with initializing the model container when running in iOS 26. The type aliases have been renamed since, however the V4.4.6 build with the old names runs and builds perfectly fine in iOS 26 If there is any other code that may be relevant in determining where this error is occurring, I would be happy to add it. My current best theory is simply that I have mistakenly omitted code relevant to the SwiftData Migration.

We’re using a private database with a custom zone. Record types and related schema are created programmatically rather than through the dashboard. When running the app in the development environment, I can see that data is saved and can be retrieved successfully. However, in the iCloud console, I don’t see any record types or even the custom zone. Additionally, I’m unable to deploy any schema to production because no changes are detected. Do you have any ideas on what we might be missing? Installing the app from TestFlight when trying to upload a record CloudKit reports this error: <CKError 0x13f40bb10: "Invalid Arguments" (12/2006); server message = "Cannot create new type MyType in production schema" ...>

Hi everyone I would like to achieve having unidirectional relationships in my SwiftData project (which I believe is possible: https://developer.apple.com/documentation/updates/swiftdata?changes=_9) but I'm afraid I'm struggling to overcome the errors I'm experiencing. For example, I have the following models: @Model final class Quota { @Attribute(.unique) var id: UUID var allowance: Int @Relationship(inverse: nil) var fish: Fish init(id: UUID = UUID(), fish: Fish, allowance: Int) { self.id = id self.fish = fish self.allowance = allowance } } @Model final class Fish { @Attribute(.unique) var id: Int var name: String init(id: Int, name: String) { self.id = id, self.name = name } } However, when I attempt to save a quota as so: let quota: Quota = .init(fish: Fish(id: 2, name: "Salmon"), allowance: 50) modelContext?.insert(quota) try save() I keep getting the following error: SwiftData.DefaultStore save failed with error: Error Domain=NSCocoaErrorDomain Code=1570 "%{PROPERTY}@ is a required value." UserInfo={NSValidationErrorObject=<NSManagedObject: 0x600002217390> (entity: Fish; id: 0x83319d001151328d <x-coredata://C76A2A64-146E-432F-A565-319B5A2F23F5/Fish/p12>; data: { id = nil; }), NSLocalizedDescription=%{PROPERTY}@ is a required value., NSValidationErrorKey=id, NSValidationErrorValue=null} %{PROPERTY}@ is a required value. However, if I set up Quota and Fish with an inverse relationship then the data saves as expected, so I'm a little confused. Is there anyone out there who can provide some guidance as to why I'm seeing this error when I try to save a record in SwiftData with no inverse relationship? I do fully understand about unidirectional vs bidirectional relationships but I have a scenario where I need the relationship to be unidirectional. Also, as a side note, the Fish record already exists in my database, but if I delete it and try to save the record I still see this error. Thank you so much in advance for any help.

Hi Writing an app in Swift on Xcode for my iPhone, all software is the latest version. If after making a minor change and re-building all the application data has disappeared, is there a way to see if it is still in the .modelContainer and just not showing up?

Hello everyone, I am experiencing a persistent authentication error when querying a custom user profile record, and the error message seems to be a red herring. My Setup: I have a custom CKRecord type called ColaboradorProfile. When a new user signs up, I create this record and store their hashed password, salt, nickname, and a custom field called loginIdentifier (which is just their lowercase username). In the CloudKit Dashboard, I have manually added an index for loginIdentifier and set it to Queryable and Searchable. I have deployed this schema to Production. The Problem: During login, I run an async function to find the user's profile using this indexed loginIdentifier. Here is the relevant authentication code: func autenticar() async { // ... setup code (isLoading, etc.) let lowercasedUsername = username.lowercased() // My predicate ONLY filters on 'loginIdentifier' let predicate = NSPredicate(format: "loginIdentifier == %@", lowercasedUsername) let query = CKQuery(recordType: "ColaboradorProfile", predicate: predicate) // I only need these specific keys let desiredKeys = ["password", "passwordSalt", "nickname", "isAdmin", "isSubAdmin", "username"] let database = CKContainer.default().publicCloudDatabase do { // This is the line that throws the error let result = try await database.records(matching: query, desiredKeys: desiredKeys, resultsLimit: 1) // ... (rest of the password verification logic) } catch { // The error always lands here logDebug("Error authenticating with CloudKit: \(error.localizedDescription)") await MainActor.run { self.errorMessage = "Connection Error: \(error.localizedDescription)" self.isLoading = false self.showAlert = true } } } The Error: Even though my query predicate only references loginIdentifier, the catch block consistently reports this error: Error authenticating with CloudKit: Field 'createdBy' is not marked queryable. I know createdBy (the system creatorUserRecordID) is not queryable by default, but my query isn't touching that field. I already tried indexing createdBy just in case, but the error persists. It seems CloudKit cannot find or use my index for loginIdentifier and is incorrectly reporting a fallback error related to a system field. Has anyone seen this behavior? Why would CloudKit report an error about createdBy when the query is explicitly on an indexed, custom field? I'm new to Swift and I'm struggling quite a bit. Thank you,

I have a document based SwiftData app in which I would like to implement a persistent cache. For obvious reasons, I would not like to store the contents of the cache in the documents themselves, but in my app's data directory. Is a use case, in which a document based SwiftData app uses not only the ModelContainers from the currently open files, but also a ModelContainer writing a database file in the app's documents directory (for cache, settings, etc.) supported? If yes, how can you inject two different ModelContexts, one tied to the currently open file and one tied to the local database, into a SwiftUI view?