I am running into some issues when trying to destroy CoreData persistentStores. When a user logs out of my app, I want to completely reset CoreData and delete any existing data. My code to reset CoreData looks like this: let coordinator = self.persistentContainer.persistentStoreCoordinator self.persistentContainer.viewContext.reset() coordinator.persistentStores.forEach { store in guard let url = store.url else { return } do { try coordinator.destroyPersistentStore(at: url, type: .sqlite) _ = try coordinator.addPersistentStore(ofType: NSSQLiteStoreType, configurationName: nil, at: url) } catch { print(error) } } However, my app is crashing with Object 0xb2b5cc80445813de <x-coredata://BDB999D4-49A4-4CB3-AC3A-666AD60BEFC6/AccountEntity/p5> persistent store is not reachable from this NSManagedObjectContext's coordinator It seems this is related to the SwiftUI @FetchRequest wrappers. If I do not open the views where I am using @FetchRequest, the logout goes smoothly. Otherwise, I get the crash above. Has anyone run into anything similar? Is there something else I need to do to get the underlying FRC to release its references to those entities? I was under the impression that calling reset() on the managed object context would be enough to remove those items from memory and get the destroying of the persistent store to go smoothly. Alternately, is there another/better way I should be destroying the DB? Any advice or related observations would be greatly appreciated. Thank you!

I have a ModelActor that creates a hierarchy of models and returns a PersistentIdentifier for the root. I'd like to do that in a transaction, but I don't know of a good method of getting that identifier if the models are created in a transaction. For instance, an overly simple example: func createItem(timestamp: Date) throws -> PersistentIdentifier { try modelContext.transaction { let item = Item(timestamp: timestamp) modelContext.insert(item) } // how to return item.persistentModelID? } I can't return the item.persistentModelID from the transaction closure and even if I could, it will be a temporary ID until after the transaction is executed. I can't create the Item outside the transaction and just have the transaction do an insert because swift will raise a data race error if you then try to return item.persistentModelID. Is there any way to do this besides a modelContext.fetch* with separate unique identifiers?

I'm running a project with these settings: Default Actor Isolation: MainActor Approachable Concurrency: Yes Strict Concurrency Checking: Complete (this issue does not appear on the other two modes) I receive a warning for this very simple use case. Can I actually fix anything about this or is this a case of Core Data not being entirely ready for this? In reference to this, there was a workaround listed in the release notes of iOS 26 beta 5 (https://forums.swift.org/t/defaultisolation-mainactor-and-core-data-background-tasks/80569/22). Does this still apply as the only fix for this? This is a simplified sample meant to run on a background context. The issue obviously goes away if this function would just run on the MainActor, then I can remove the perform block entirely. class DataHandler { func createItem() async { let context = ... await context.perform { let newGame = Item(context: context) /// Main actor-isolated property 'timestamp' can not be mutated from a Sendable closure newGame.timestamp = Date.now // ... } } } The complete use case would be more like this: nonisolated struct DataHandler { @concurrent func saveItem() async throws { let context = await PersistenceController.shared.container.newBackgroundContext() try await context.perform { let newGame = Item(context: context) newGame.timestamp = Date.now try context.save() } } }

I have an iOS app (1Address) which allows users to share their address with family and friends using CloudKit Sharing. Users share their address record (CKRecord) via a share link/url which when tapped allows the receiving user to accept the share and have a persistent view into the sharing user's address record (CKShare). However, most users when they recieve a sharing link do not have the app installed yet, and so when a new receiving user taps the share link, it prompts them to download the app from the app store. After the new user downloads the app from the app store and opens the app, my understanding is that the system (iOS) will/should then vend to my app the previously tapped cloudKitShareMetadata (or share url), however, this metadata is not being vended by the system. This forces the user to re-tap the share link and leads to some users thinking the app doesn't work or not completing the sharing / onboarding flow. Is there a workaround or solve for this that doesn't require the user to tap the share link a second time? In my scene delegate I am implementing: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {...} And also func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {...} And also: func windowScene(_ windowScene: UIWindowScene, userDidAcceptCloudKitShareWith cloudKitShareMetadata: CKShare.Metadata) {...} And: func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {...} Unfortunately, none of these are called or passed metadata on the initial app run after install. Only after the user goes back and taps a link again can they accept the share. This documentation: https://developer.apple.com/documentation/cloudkit/ckshare says that adding the CKSharingSupported key to your app's Info.plist file allows the system to launch your app when a user taps or clicks a share URL, but it does not clarify what should happen if your app is being installed for the first time. This seems to imply that the system is holding onto the share metadata and/or url, but for some reason it is not being vended to the app on first run. Open to any ideas here for how to fix and I also filed feedback: FB20934189.

Hi everyone, I’m working on an offline-first iOS app using Core Data. I have a question about safe future updates: in my project, I want to be able to add new optional fields to existing Entities or even completely new Entities in future versions — but nothing else (no renaming, deleting, or type changes). Here’s how my current PersistenceController looks: import CoreData struct PersistenceController { static let shared = PersistenceController() let container: NSPersistentContainer init(inMemory: Bool = false) { container = NSPersistentContainer(name: "MyApp") if inMemory { container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: "/dev/null") } container.loadPersistentStores(completionHandler: { (storeDescription, error) in if let error = error as NSError? { print("Core Data failed to load store: \(error), \(error.userInfo)") } }) container.viewContext.automaticallyMergesChangesFromParent = true } } Do I need to explicitly set these properties to ensure lightweight migration works? shouldMigrateStoreAutomatically = true shouldInferMappingModelAutomatically = true Or, according to the documentation, are they already true by default, so I can safely add optional fields and new Entities in future versions without breaking users’ existing data? Thanks in advance for your guidance!

I have a SwiftData flashcard app which I am syncing with CloudKit using NSPersistentCloudKitContainer. While syncing itself is working perfectly, I have noticed a dramatic increase in the app size after enabling sync. Specifically, without CloudKit, 15k flashcards results in the default.store file being about 4.5 MB. With CloudKit, default.store is about 67 MB. I have inspected the store and found that most of this increase is due to the ANSCKRECORDMETADATA table. My question is, does implementing CloudKit normally cause this magnitude of increase in storage? If it doesn’t, is there something in my model, schema, implementation, etc. that could be causing it? Below are two other posts describing a similar issue, but neither with a solution. I replied to the first one about a month ago. I then submitted this to Developer Technical Support, but was asked to post my question in the forums, so here it is. Strange behavior with 100k+ records in NSPersistentCloudKitContainer Huge increase in sqlite file size after adopting CloudKit

Since running on iOS 14b1, I'm getting this in my log (I have Core Data logging enabled): error: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only mode store at 'file:///private/var/mobile/Containers/Shared/AppGroup/415B75A6-92C3-45FE-BE13-7D48D35909AF/StoreFile.sqlite' As far as I can tell, it's impossible to open my store without that key set - it's in the init() of my NSPersistentContainer subclass, before anyone calls it to load stores. Any ideas?

Hello Apple Team, We’re building a CloudKit-enabled Core Data app and would like clarification on the behavior and performance characteristics of Binary Data attributes with “Allows External Storage” enabled when used with NSPersistentCloudKitContainer. Initially, we tried storing image files manually on disk and only saving the metadata (file URLs, dimensions, etc.) in Core Data. While this approach reduced the size of the Core Data store, it introduced instability after app updates and broke sync between devices. We would prefer to use the official Apple-recommended method and have Core Data manage image storage and CloudKit syncing natively. Specifically, we’d appreciate guidance on the following: When a Binary Data attribute is marked as “Allows External Storage”, large image files are stored as separate files on device rather than inline in the SQLite store. How effective is this mechanism in keeping the Core Data store size small on device? Are there any recommended size thresholds or known limits for how many externally stored blobs can safely be managed this way? How are these externally stored files handled during CloudKit sync? Does each externally stored Binary Data attribute get mirrored to CloudKit as a CKAsset? Does external storage reduce the sync payload size or network usage, or is the full binary data still uploaded/downloaded as part of the CKAsset? Are there any bandwidth implications for users syncing via their private CloudKit database, versus developer costs in the public CloudKit database? Is there any difference in CloudKit or Core Data behavior when a Binary Data attribute is managed this way versus manually storing image URLs and handling the file separately on disk? Our goal is to store user-generated images efficiently and safely sync them via CloudKit, without incurring excessive local database bloat or CloudKit network overhead. Any detailed guidance or internal performance considerations would be greatly appreciated. Thank you, Paul Barry Founder & Lead Developer — Boat Buddy / Vessel Buddy iOS App Archipelago Environmental Solutions Inc.

I am using SwiftData with CloudKit to synchronize data across multiple devices, and I have encountered an issue: occasionally, abnormal sync behavior occurs between two devices (it does not happen 100% of the time—only some users have reported this problem). It seems as if synchronization between the two devices completely stops; no matter what operations are performed on one end, the other end shows no response. After investigating, I suspect the issue might be caused by both devices simultaneously modifying the same field, which could lead to CloudKit's logic being unable to handle such conflicts and causing the sync to stall. Are there any methods to avoid or resolve this situation? Of course, I’m not entirely sure if this is the root cause. Has anyone encountered a similar issue?

I'm a first time developer for Swift, (getting on a bit!) but after programming in VB back in the late 90s I wanted to write an app for iPhone. I think I might have gone about it the wrong way, but I've got an app that works great on my iPhone or works great on my iPad. It saves the data persistently on device, but, no matter how much I try, what I read and even resorting to AI (ChatGPT & Gemini) I still can't get it to save the data on iCloud to synchronise between the two and work across the devices. I think it must be something pretty fundamental I'm doing (or more likely not doing) that is causing the issue. I'm setting up my signing and capabilities as per the available instructions but I always get a fatal error. I think it might be something to do with making fields optional, but at this point I'm second guessing myself and feeling a complete failure. Any advice or pointers would be really gratefully appreciated. I like my app and would like eventually to get it on the App Store but at this point in time I feel it should be on the failed projects heap! I've even tried a new Xcode project for iOS and asking it to use SwiftData and CloudKit - the default project should work - right? But it absolutely doesn't for me. Please send help!!

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.

Hello 👋, I encounter the "This model instance was invalidated because its backing data could no longer be found the store" crash with SwiftData. Which from what I understood means I try to access a model after it has been removed from the store (makes sense). I made a quick sample to reproduce/better understand because there some case(s) I can't figure it out. Let's take a concrete example, we have Home model and a Home can have many Room(s). // Sample code @MainActor let foo = Foo() // A single reference let database = Database(modelContainer: sharedModelContainer) // A single reference @MainActor class Foo { // Properties to explicilty keep reference of model(s) for the purpose of the POC var _homes = [Home]() var _rooms = [Room]() func fetch() async { let homes = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home } print(ObjectIdentifier(homes[0]), homes[0].rooms?.map(\.id)) // This will crash here or not. } // Same version of a delete function with subtle changes. // Depending on the one you use calling delete then fetch will result in a crash or not. // Keep a reference to only homes == NO CRASH func deleteV1() async { self._homes = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home } await database.delete() } // Keep a reference to only rooms == NO CRASH func deleteV2() async { self._rooms = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home }[0].rooms ?? [] await database.delete() } // Keep a reference to homes & rooms == CRASH 💥 func deleteV3() async { self._homes = await database.fetch().map { sharedModelContainer.mainContext.model(for: $0) as! Home } self._rooms = _homes[0].rooms ?? [] // or even only retain reference to rooms that have NOT been deleted 🤔 like here "id: 2" make it crash // self._rooms = _homes[0].rooms?.filter { r in r.id == "2" } ?? [] await database.delete() } } Calling deleteV() then fetch() will result in a crash or not depending on the scenario. I guess I understand deleteV1, deleteV2. In those case an unsaved model is served by the model(for:) API and accessing properties later on will resolve correctly. The doc says: "The identified persistent model, if known to the context; otherwise, an unsaved model with its persistentModelID property set to persistentModelID." But I'm not sure about deleteV3. It seems the ModelContext is kind of "aware" there is still cyclic reference between my models that are retained in my code so it will serve these instances instead when calling model(for:) API ? I see my home still have 4 rooms (instead of 2). So I then try to access rooms that are deleted and it crash. Why of that ? I mean why not returning home with two room like in deleteV1 ? Because SwiftData heavily rely on CoreData may be I miss a very simple thing here. If someone read this and have a clue for me I would be extremely graceful. PS: If someone wants to run it on his machine here's some helpful code: // Database let sharedModelContainer: ModelContainer = { let schema = Schema([ Home.self, Room.self, ]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false) debugPrint(modelConfiguration.url.absoluteString.replacing("%20", with: "\\ ")) return try! ModelContainer(for: schema, configurations: [modelConfiguration]) }() extension Database { static let shared = Database(modelContainer: sharedModelContainer) } @ModelActor actor Database { func insert() async { let r1 = Room(id: "1", name: "R1") let r2 = Room(id: "2", name: "R2") let r3 = Room(id: "3", name: "R3") let r4 = Room(id: "4", name: "R4") let home = Home(id: "1", name: "My Home") home.rooms = [r1, r2, r3, r4] modelContext.insert(home) try! modelContext.save() } func fetch() async -> [PersistentIdentifier] { try! modelContext.fetchIdentifiers(FetchDescriptor<Home>()) } @MainActor func delete() async { let mainContext = sharedModelContainer.mainContext try! mainContext.delete( model: Room.self, where: #Predicate { r in r.id == "1" || r.id == "4" } ) try! mainContext.save() // 🤔 Calling fetch here seems to solve crash too, force home relationship to be rebuild correctly ? // let _ = try! sharedModelContainer.mainContext.fetch(FetchDescriptor<Home>()) } } // Models @Model class Home: Identifiable { @Attribute(.unique) public var id: String var name: String @Relationship(deleteRule: .cascade, inverse: \Room.home) var rooms: [Room]? init(id: String, name: String, rooms: [Room]? = nil) { self.id = id self.name = name self.rooms = rooms } } @Model class Room: Identifiable { @Attribute(.unique) public var id: String var name: String var home: Home? init(id: String, name: String, home: Home? = nil) { self.id = id self.name = name self.home = home } }

I have transitioned to CKSyncEngine for syncing data to iCloud, and it is working quite well. I have a question regarding best practices for modifying and saving a CKRecord which already exists in the private or shared database. In my current app, most CKRecords will never be modified after saving to the database, so I do not persist a received record locally after updating my local data model. In the rare event that the local data for that record is modified, I manually fetch the associated server record from the database, modify it, and then use CKSyncEngine to save the modified record. As an alternative method, I can create a new CKRecord locally with the corresponding recordID and the modified data, and then use CKSyncEngine to attempt to save that record to the database. Doing so generates an error in the delegate method handleSentRecordZoneChanges, where I receive the local record I tried to save back inevent.failedRecordSaves with a .serverRecordChanged error, along with the corresponding server CKRecord. I can then update that server record with the local data and re-save using CKSyncEngine. I have not yet seen any issues when doing it this way. The advantage of the latter method is that CKSyncEngine handles the entire database operation, eliminating the manual fetch step. My question is: is this an acceptable practice, or could this result in other unforeseen issues?

Here’s the situation: • You’re downloading a huge list of data from iCloud. • You’re saving it one by one (sequentially) into SwiftData. • You don’t want the SwiftUI view to refresh until all the data is imported. • After all the import is finished, SwiftUI should show the new data. The Problem If you insert into the same ModelContext that SwiftUI’s @Environment(.modelContext) is watching, each insert may cause SwiftUI to start reloading immediately. That will make the UI feel slow, and glitchy, because SwiftUI will keep trying to re-render while you’re still importing. How to achieve this in Swift Data ?

我正在使用 Core Data 开发一个 SwiftUI 项目。我的数据模型中有一个名为 AppleUser 的实体，具有以下属性：id （UUID）、name （String）、email （String）、password （String） 和 createdAt （Date）。所有属性都是非可选的。 我使用 Xcode 的自动生成创建了相应的 Core Data 类文件（AppleUser+CoreDataClass.swift 和 AppleUser+CoreDataProperties.swift）。我还有一个 PersistenceController，它使用模型名称 JobLinkModel 初始化 NSPersistentContainer。 当我尝试使用以下方法保存新的 AppleUser 对象时： 让用户 = AppleUser（上下文：viewContext） user.id = UUID（） user.name = “用户 1” user.email = “...” user.password = “密码 1” user.createdAt = Date（）【电子邮件格式正确，但已替换为“...”出于隐私原因】 尝试？viewContext.save（） 我在控制台中收到以下错误：核心数据保存失败：Foundation._GenericObjCError.nilError， [：] 用户快照： [“id”： ...， “name”： “User1”， “email”： “...”， “password”： “...”， “createdAt”： ...] 所有字段都有有效值，核心数据模型似乎正确。我还尝试过： • 检查 NSPersistentContainer（name：） 中的模型名称是否与 .xcdatamodeld 文件 （JobLinkModel） 匹配 • 确保正确设置 AppleUser 实体类、模块和 Codegen（类定义、当前产品模块） • 删除重复或旧的 AppleUser 类文件 • 清理 Xcode 构建文件夹并从模拟器中删除应用程序 • 对上下文使用 @Environment（.managedObjectContext） 尽管如此，在保存新的 AppleUser 对象时，我仍然会收到 _GenericObjCError.nilError。 我想了解： 为什么即使所有字段都不是零且正确分配，核心数据也无法保存？ 这可能是由于一些残留的旧类文件引起的，还是我缺少设置中的其他内容？ 我应该采取哪些步骤来确保 Core Data 正确识别 AppleUser 实体并允许保存？ 任何帮助或指导将不胜感激。

HI, swiftdata is new to me and any help would be appreciated. In my swiftui app I have a functionality that reinstates the database from an archive. I first move the three database files (database.store datebase.store-wal and database.store-shm) to a new name (.tmp added for backup incase) and then copy the Archived three files to the same location. the move creates the following errors: " BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: /private/var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store.tmp invalidated open fd: 4 (0x20)" I get the same message in console for all three files. then I reinitialise the model container and get no errors as my code below .... let schema = Schema([....my different models are here]) let config = ModelConfiguration("database", schema: schema) do { // Recreate the container with the same store URL let container = try ModelContainer(for: schema, configurations: config) print("ModelContainer reinitialized successfully!") } catch { print("Failed to reinitialize ModelContainer: (error)") } } I get the success message but when I leave the view (backup-restore view) to the main view I get: CoreData: error: (6922) I/O error for database at /var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store. SQLite error code:6922, 'disk I/O error' and error: SQLCore dispatchRequest: exception handling request: &lt;NSSQLFetchRequestContext: 0x302920460&gt; , I/O error for database at /var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store. SQLite error code:6922, 'disk I/O error' with userInfo of { NSFilePath = "/var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store"; NSSQLiteErrorDomain = 6922; } error: -executeRequest: encountered exception = I/O error for database at /var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store. SQLite error code:6922, 'disk I/O error' with userInfo = { NSFilePath = "/var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store"; NSSQLiteErrorDomain = 6922; } CoreData: error: SQLCore dispatchRequest: exception handling request: &lt;NSSQLFetchRequestContext: 0x302920460&gt; , I/O error for database at /var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store. SQLite error code:6922, 'disk I/O error' with userInfo of { NSFilePath = "/var/mobile/Containers/Data/Application/499A6802-02E5-4547-83C4-88389AEA50F5/Library/Application Support/database.store"; NSSQLiteErrorDomain = 6922; } Can anyone let me know how I should go about this - reseting the database from old backup files by copying over them. or if there is a way to stop the database and restart it with the new files in swiftdata my app is an ios app for phone and ipad

Hello Apple Team, We are looking at developing an iOS feature on our current development that stores user-generated images as CKAssets in the public CloudKit database, with access control enforced by our app’s own logic (not CloudKit Sharing as that has a limit of 100 shares per device). Each story or post is a public record, and users only see content based on buddy relationships handled within the app. We’d like to confirm that this pattern is consistent with Apple’s best practices for social features. Specifically: Is it acceptable to store user-uploaded CKAssets in the public CloudKit database, as long as access visibility is enforced by the app? Are there any performance or quota limitations (e.g., storage, bandwidth, or user sync limits) that apply to CKAssets in the public database when used at scale? Would CloudKit Sharing be recommended instead, even if we don’t require user-to-user sharing invitations? For App Review, is this model (public CKAssets + app-enforced access control) compliant with Apple’s data and security expectations? Are there any caching or bandwidth optimization guidelines for handling image-heavy public CKAsset data in CloudKit? Thanks again for your time

I'm running into an undocumented error coming back from CloudKit operations. Specifically, I'm attempting to save new records via CKModifyRecordsOperation. I'm receiving this error for each of the records in the perRecordSaveBlock callback: &lt;CKError 0x3018ac3c0: "Internal Error" (1/3001); "MMCSEngineCreate failed"&gt; Is anyone else facing this error? It has been happening for several days and I'm finally getting around to reproduction with the Console app and logs. I have 16 records on my device locally that each one gets this error back. FB16547732 - CloudKit: CKModifyRecordsOperation saving new records results in Error &lt;CKError 0x3018ac1e0: "Internal Error" (1/3001); "MMCSEngineCreate failed"&gt;

I have an app that from day 1 has used Swiftdata and successfully sync'd across devices with Cloudkit. I have added models to the data in the past and deployed the schema and it continued to sync across devices. Sometime I think in June.2025 I added a new model and built out the UI to display and manage it. I pushed a version to Test Flight (twice over a matter of 2 versions and a couple of weeks) and created objects in the new model in Test Flight versions of the app which should push the info to Cloudkit to update the schema. When I go to deploy the schema though there are no changes. I confirmed in the app that Cloudkit is selected and it's point to the correct container. And when I look in Cloudkit the new model isn't listed as an indes. I've pushed deploy schema changes anyway (more than once) and now the app isn't sync-ing across devices at all (even the pre-existing models aren't sync-ing across devices). I even submitted the first updated version to the app store and it was approved and released. I created objects in the new model in production which I know doesn't create the indexes in the development environment. But this new model functions literally everywhere except Cloudkit and I don't know what else to do to trigger an update.

Hi, Before the iOS 17.2 update the saving behavior of SwiftData was very straightforward, by default it saves to persistence storage and can be configured to save in memory only. Now it saves to memory by default and to make it save to persistence storage we need to use modelContext.Save(). But if we don't quit the App the changes will be saved after a while to persistence storage even without running modelContext.Save() ! How confusing can that be for both developer and the user ! Am I missing something here ? -- Kind Regards