iCloud & Data

RSS for tag

Learn how to integrate your app with iCloud and data frameworks for effective data storage

CloudKit Documentation

Posts under iCloud & Data subtopic

Post

Replies

Boosts

Views

Activity

CloudKit Dashboard completely empty (no containers at all) while Xcode 26 still shows my production container iCloud.gainzCloud and builds fine – Tahoe 26.1 / Xcode 26.0 (17A321)
Hi, I’m completely stuck with a very strange CloudKit problem that started recently and has now killed all iCloud sync for a live production app. What is happening Production container: iCloud.gainzCloud (created ~11 months ago, has been working perfectly until now) In Xcode 26.0 (17A321): → Signing & Capabilities → iCloud is enabled → Container correctly shows as iCloud.gainzCloud → App builds and runs on device/simulator with zero provisioning or container errors CloudKit Dashboard (https://icloud.developer.apple.com/dashboard/): completely blank – “No containers found” Result: CloudKit sync is dead for every user (development + production environments) What I know for sure Apple Developer Support confirmed the container iCloud.gainzCloud still exists and is correctly attached to my Team ID on their backend Personal iCloud (Mail, Notes, Photos, etc.) syncs perfectly on the same Mac / same Apple ID under macOS Tahoe 26.1 I have NOT changed the password on either the Apple ID or the Developer Program account New containers I create appear in Xcode but never show up in the Dashboard Environment macOS Tahoe 26.1 (latest) Xcode Version 26.0 (17A321) Has anyone on the new Tahoe/Xcode 26 releases seen the CloudKit Dashboard suddenly go completely empty while Xcode still “sees” the container just fine? Any known trick to force the dashboard to re-index containers or clear whatever cache is broken? Thanks a lot in advance – this is blocking all iCloud functionality for a released app with active users.
0
0
67
Nov ’25
iCloud Container Cannot Enable in Xcode — App ID Won’t Accept Container / Missing iCloud Documents Toggle
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
1
0
201
Dec ’25
NSPersistentCloudkitContainer Memory Leak -> Crash? (iOS 15 beta 4 & 5)
Background I have an established app in the App Store which has been using NSPersistentCloudkitContainer since iOS 13 without any issues. I've been running my app normally on an iOS device running the iOS 15 betas, mainly to see problems arise before my users see them. Ever since iOS 15 (beta 4) my app has failed to sync changes - no matter how small the change. An upload 'starts' but never completes. After a minute or so the app quits to the Home Screen and no useful information can be gleaned from crash reports. Until now I've had no idea what's going on. Possible Bug in the API? I've managed to replicate this behaviour on the simulator and on another device when building my app with Xcode 13 (beta 5) on iOS 15 (beta 5). It appears that NSPersistentCloudkitContainer has a memory leak and keeps ramping up the RAM consumption (and CPU at 100%) until the operating system kills the app. No code of mine is running. I'm not really an expert on these things and I tried to use Instruments to see if that would show me anything. It appears to be related to NSCloudkitMirroringDelegate getting 'stuck' somehow but I have no idea what to do with this information. My Core Data database is not tiny, but not massive by any means and NSPersistentCloudkitContainer has had no problems syncing to iCloud prior to iOS 15 (beta 4). If I restore my App Data (from an external backup file - 700MB with lots of many-many, many-one relationships, ckAssets, etc.) the data all gets added to Core Data without an issue at all. The console log (see below) then shows that a sync is created, scheduled & then started... but no data is uploaded. At this point the memory consumption starts and all I see is 'backgroundTask' warnings appear (only related to CloudKit) with no code of mine running. CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExporter analyzeHistoryInStore:withManagedObjectContext:error:](501): <PFCloudKitExporter: 0x600000301450>: Exporting changes since (0): <NSPersistentHistoryToken - { "4B90A437-3D96-4AC9-A27A-E0F633CE5D9D" = 906; }> CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExportContext processAnalyzedHistoryInStore:inManagedObjectContext:error:]_block_invoke_3(251): Finished processing analyzed history with 29501 metadata objects to create, 0 deleted rows without metadata. CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _scheduleAutomatedExportWithLabel:activity:completionHandler:](2800): <NSCloudKitMirroringDelegate: 0x6000015515c0> - Beginning automated export - ExportActivity: <CKSchedulerActivity: 0x60000032c500; containerID=<CKContainerID: 0x600002ed3240; containerIdentifier=iCloud.com.nitramluap.Somnus, containerEnvironment="Sandbox">, identifier=com.apple.coredata.cloudkit.activity.export.4B90A437-3D96-4AC9-A27A-E0F633CE5D9D, priority=2, xpcActivityCriteriaOverrides={ Priority=Utility }> CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate executeMirroringRequest:error:](765): <NSCloudKitMirroringDelegate: 0x6000015515c0>: Asked to execute request: <NSCloudKitMirroringExportRequest: 0x600002ed2a30> CBE1852D-7793-46B6-8314-A681D2038B38 2021-08-13 08:41:01.518422+1000 Somnus[11058:671570] [BackgroundTask] Background Task 68 ("CoreData: CloudKit Export"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. 2021-08-13 08:41:03.519455+1000 Somnus[11058:671570] [BackgroundTask] Background Task 154 ("CoreData: CloudKit Scheduling"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. Just wondering if anyone else is having a similar issue? It never had a problem syncing an initial database restore prior to iOS 15 (beta 4) and the problems started right after installing iOS 15 (beta 4). I've submitted this to Apple Feedback and am awaiting a response (FB9412346). If this is unfixable I'm in real trouble (and my users are going to be livid). Thanks in advance!
25
0
13k
Jun ’25
Container Failing to Initialize After a Successful Migration & Initialization
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.
2
0
749
Nov ’25
What is going on with transformable
Hi, I keep trying to use transformable to store an array of strings with SwiftData, and I can see that it is activating the transformer, but it keeps saying that I am still using NSArray instead of NSData. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Unacceptable type of value for attribute: property = "category"; desired type = NSData; given type = Swift.__SwiftDeferredNSArray; value = ( yo, gurt ).' terminating due to uncaught exception of type NSException CoreSimulator 1010.10 - Device: iPhone 16 18.0 (6879535B-3174-4025-AD37-ED06E60291AD) - Runtime: iOS 18.0 (22A3351) - DeviceType: iPhone 16 Message from debugger: killed @Model class MyModel: Identifiable, Equatable { @Attribute(.transformable(by: StringArrayTransformer.self)) var category: [String]? @Attribute(.transformable(by: StringArrayTransformer.self)) var amenities: [String]? var image: String? var parentChunck: HenricoPostDataChunk_V1? init(category: [String]?, amenities: [String]?) { self.category = category self.amenities = amenities } } class StringArrayTransformer: ValueTransformer { override func transformedValue(_ value: Any?) -> Any? { print(value) guard let array = value as? [String] else { return nil } let data = try? JSONSerialization.data(withJSONObject: array, options: []) print(data) return data } override func reverseTransformedValue(_ value: Any?) -> Any? { guard let data = value as? Data else { return nil } let string = (try? JSONSerialization.jsonObject(with: data, options: [])) as? [String] print(string) return string } override class func transformedValueClass() -> AnyClass { return NSData.self } override class func allowsReverseTransformation() -> Bool { return true } static func register() { print("regitsering") ValueTransformer.setValueTransformer(StringArrayTransformer(), forName: .stringArrayTransformerName) } } extension NSValueTransformerName { static let stringArrayTransformerName = NSValueTransformerName("StringArrayTransformer") }
3
0
212
Jul ’25
iCloud Database Errors and Limits
We are currently implementing a custom iCloud sync for our macOS and iOS apps using CloudKit. Syncing works fine as long as the number of record sends is relatively small. But when we test with a large number of changes ( 80,000+ CKRecords ) we start running into problems. Our sending strategy is very conservative to avoid rate limits: We send records sequentially in batches of 250 records With about 2 seconds pause between operations Records are small and contain no assets (assets are uploaded separately) At some point we start receiving: “Database commit size exceeds limit” After that, CloudKit begins returning rate-limit errors with retryAfter-Information in the error. We wait for the retry time and try again, but from this moment on, nothing progresses anymore. Every subsequent attempt fails. We could not find anything in the official documentation regarding such a “commit size” limit or what triggers this failure state. So my questions are: Are there undocumented limits on the total number of records that can exist in an iCloud database (private or shared)? Is there a maximum volume of record modifications a container can accept within a certain timeframe, even if operations are split into small batches with pauses? Is it possible that sending large numbers of records in a row can temporarily or permanently “stall” a CloudKit container? Any insights or experiences would be greatly appreciated. Thank you!
0
0
210
Nov ’25
SwiftData shared across apps?
The stuff I've found by searching has confused me, so hopefully someone can help simplify it for me? I have an app (I use it for logging which books I've given away), and I could either add a bunch of things to the app, or I could have another app (possibly a CLI tool) to generate some reports I'd like.
0
0
94
May ’25
SwiftData with CloudKit Sync Issue
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?
2
1
303
Jan ’26
Consequences of incorrect VersionedSchema.versionIdentifier
About 4 months ago, I shipped the first version of my app with 4 versioned schemas that, unintentionally, had the same versionIdentifier of 1.2.0 in 2 of them: V1: 1.0.0 V2: 1.1.0 V3: 1.2.0 V4: 1.2.0 They are ordered correctly in the MigrationPlan, and they are all lightweight. Migration works, SwiftData doesn't crash on init and I haven't encountered any issues related to this. The app syncs with iCloud. Questions, preferable for anybody with knowledge of SwiftData internals: What will break in SwiftData when there are 2 duplicate numbers? Not that I would expect it to be safe, but does it happen to be safe to ship an update that changes V4's version to 1.3.0, what was originally intended?
0
0
171
Jul ’25
CloudKit CKRecordZone Deletion Issue
CloudKit CKRecordZone Deletion Issue Problem: CloudKit record zones deleted via CKDatabase.modifyRecordZones(deleting:) or CKModifyRecordZonesOperation are successfully removed but then reappear. I suspect they are automatically reinstated by CloudKit sync, despite successful deletion confirmation. Environment: SwiftData with CloudKit integration Custom CloudKit zones created for legacy zone-based sharing Observed Behavior: Create custom zone (e.g., "TestZone1") via CKDatabase.modifyRecordZones(saving:) Copy records to zone for sharing purposes Delete zone using any CloudKit deletion API - returns success, no errors Immediate verification: Zone is gone from database.allRecordZones() After SwiftData/CloudKit sync or app restart: Zone reappears Reproduction: Tested with three different deletion methods - all exhibit same behaviour: modifyRecordZones(deleting:) async API CKModifyRecordZonesOperation (fire-and-forget) CKModifyRecordZonesOperation with result callbacks Zone deletion succeeds, change tokens (used to track updates to shared records) cleaned up But zones are restored presumably by CloudKit background sync Expected: Deleted zones should remain deleted Actual: Zones are reinstated, creating orphaned zones
1
0
140
Dec ’25
NSPersistentCloudKitContainer losing data
Some users of my app are reporting total loss of data while using the app. This is happening specifically when they enable iCloud sync. I am doing following private func setupContainer(enableICloud: Bool) { container = NSPersistentCloudKitContainer(name: "") container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy guard let description: NSPersistentStoreDescription = container.persistentStoreDescriptions.first else { fatalError() } description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) if enableICloud == false { description.cloudKitContainerOptions = nil } container.loadPersistentStores { description, error in if let error { // Handle error } } } When user clicks on Toggle to enable/disable iCloud sync I just set the description.cloudKitContainerOptions to nil and then user is asked to restart the app. Apart from that I periodically run the clear history func deleteTransactionHistory() { let sevenDaysAgo = Calendar.current.date(byAdding: .day, value: -7, to: Date())! let purgeHistoryRequest = NSPersistentHistoryChangeRequest.deleteHistory(before: sevenDaysAgo) let backgroundContext = container.newBackgroundContext() backgroundContext.performAndWait { try! backgroundContext.execute(purgeHistoryRequest) } }
4
0
1.3k
Nov ’25
SwiftData Background Fetching?
Hi, I am experiencing main thread freezes from fetching on Main Actor. Attempting to move the function to a background thread, but whenever I reference the TestModel in a nonisolated context or in another model actor, I get this warning: Main actor-isolated conformance of 'TestModel' to 'PersistentModel' cannot be used in actor-isolated context; this is an error in the Swift 6 language mode Is there a way to do this correctly? Recreation, warning on line 13: class TestModel { var property: Bool = true init() {} } struct SendableTestModel: Sendable { let property: Bool } @ModelActor actor BackgroundActor { func fetch() throws -> [SendableTestModel] { try modelContext.fetch(FetchDescriptor<TestModel>()).map { SendableTestModel(property: $0.property) } } }
1
0
149
Jul ’25
Core Data complaining about store being opened without persistent history tracking... but I don't think that it has been
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?
2
0
1.2k
May ’25
CloudKit: how to handle CKError partialFailure when using NSPersistentCloudKitContainer?
I'm using NSPersistentCloudKitContainer with Core Data and I receive errors because my iCloud space is full. The errors printed are the following: <CKError 0x280df8e40: "Quota Exceeded" (25/2035); server message = "Quota exceeded"; op = 61846C533467A5DF; uuid = 6A144513-033F-42C2-9E27-693548EF2150; Retry after 342.0 seconds>. I want to inform the user about this issue, but I can't find a way to access the details of the error. I'm listening to NSPersistentCloudKitContainer.eventChangedNotification, I receive a error of type .partialFailure. But when I want to access the underlying errors, the partialErrorsByItemID property on the error is nil. How can I access this Quota Exceeded error? import Foundation import CloudKit import Combine import CoreData class SyncMonitor { fileprivate var subscriptions = Set<AnyCancellable>() init() { NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification) .sink { notification in if let cloudEvent = notification.userInfo?[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { guard let ckerror = cloudEvent.error as? CKError else { return } print("Error: \(ckerror.localizedDescription)") if ckerror.code == .partialFailure { guard let errors = ckerror.partialErrorsByItemID else { return } for (_, error) in errors { if let currentError = error as? CKError { print(currentError.localizedDescription) } } } } } // end of sink .store(in: &subscriptions) } }
2
1
1.5k
Aug ’25
"Failed to set up CloudKit integration" in TestFlight build
I'm building a macOS + iOS SwiftUI app using Xcode 14.1b3 on a Mac running macOS 13.b11. The app uses Core Data + CloudKit. With development builds, CloudKit integration works on the Mac app and the iOS app. Existing records are fetched from iCloud, and new records are uploaded to iCloud. Everybody's happy. With TestFlight builds, the iOS app has no problems. But CloudKit integration isn't working in the Mac app at all. No existing records are fetched, no new records are uploaded. In the Console, I see this message: error: CoreData+CloudKit: Failed to set up CloudKit integration for store: <NSSQLCore: 0x1324079e0> (URL: <local file url>) Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction.} I thought it might be that I was missing the com.apple.security.network.client entitlement, but adding that didn't help. Any suggestions what I might be missing? (It's my first sandboxed Mac app, so it might be really obvious to anyone but me.)
4
1
3.7k
Apr ’25
SwiftData crash when using a @Query sort descriptor with a relationship
I am using SwiftData for storage and have a view that uses the @Query property wrapper with a sort descriptor that points to a relationship on a model. In a release build on device running iOS 18.3, the app crashes. This is the line that crashes: @Query(sort: \Item.info.endDate, order: .reverse) private var items: [Item] Item has a relationship to ItemInfo, which is where the endDate property is defined. This code works in debug and on a simulator. In the project referenced here: https://github.com/lepolt/swiftdata-crash, change the scheme build configuration to “Release” and run on device. The app will crash. Using Xcode Version 16.2 (16C5032a) iPhone 12, iOS 18.3 (22D60)
9
12
1.5k
Aug ’25
SwiftData Fatal error: Editors must register their identifiers before invoking operations on this store
I have a UIKit app where I've adopted SwiftData and I'm struggling with a crash coming in from some of my users. I'm not able to reproduce it myself and as it only happens to a small fraction of my user base, it seems like a race condition of some sort. This is the assertion message: SwiftData/DefaultStore.swift:453: Fatal error: API Contract Violation: Editors must register their identifiers before invoking operations on this store SwiftData.DefaultStore: 00CF060A-291A-4E79-BEC3-E6A6B20F345E did not. (ID is unique per crash) This is the ModelActor that crashes: @available(iOS 17, *) @ModelActor actor ConsumptionDatabaseStorage: ConsumptionSessionStorage { struct Error: LocalizedError { var errorDescription: String? } private let sortDescriptor = [SortDescriptor(\SDConsumptionSession.startTimeUtc, order: .reverse)] static func createStorage(userId: String) throws -> ConsumptionDatabaseStorage { guard let appGroupContainer = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: UserDefaults.defaultAppGroupIdentifier) else { throw Error(errorDescription: "Invalid app group container ID") } func createModelContainer(databaseUrl: URL) throws -> ModelContainer { return try ModelContainer(for: SDConsumptionSession.self, SDPriceSegment.self, configurations: ModelConfiguration(url: databaseUrl)) } let databaseUrl = appGroupContainer.appendingPathComponent("\(userId).sqlite") do { return self.init(modelContainer: try createModelContainer(databaseUrl: databaseUrl)) } catch { // Creating the model storage failed. Remove the database file and try again. try? FileManager.default.removeItem(at: databaseUrl) return self.init(modelContainer: try createModelContainer(databaseUrl: databaseUrl)) } } func isStorageEmpty() async -> Bool { (try? self.modelContext.fetchCount(FetchDescriptor<SDConsumptionSession>())) ?? 0 == 0 // <-- Crash here! } func sessionsIn(interval: DateInterval) async throws -> [ConsumptionSession] { let fetchDescriptor = FetchDescriptor(predicate: #Predicate<SDConsumptionSession> { sdSession in if let startDate = sdSession.startTimeUtc { return interval.start <= startDate && interval.end > startDate } else { return false } }, sortBy: self.sortDescriptor) let consumptionSessions = try self.modelContext.fetch(fetchDescriptor) // <-- Crash here! return consumptionSessions.map { ConsumptionSession(swiftDataSession: $0) } } func updateSessions(sessions: [ConsumptionSession]) async throws { if #unavailable(iOS 18) { // Price segments are duplicated if re-inserted so unfortunately we have to delete and reinsert sessions. // On iOS 18, this is enforced by the #Unique macro on SDPriceSegment. let sessionIds = Set(sessions.map(\.id)) try self.modelContext.delete(model: SDConsumptionSession.self, where: #Predicate<SDConsumptionSession> { sessionIds.contains($0.id) }) } for session in sessions { self.modelContext.insert(SDConsumptionSession(consumptionSession: session)) } if self.modelContext.hasChanges { try self.modelContext.save() } } func deleteAllSessions() async { if #available(iOS 18, *) { try? self.modelContainer.erase() } else { self.modelContainer.deleteAllData() } } } The actor conforms to this protocol: protocol ConsumptionSessionStorage { func isStorageEmpty() async -> Bool func hasCreditCardSessions() async -> Bool func sessionsIn(interval: DateInterval) async throws -> [ConsumptionSession] func updateSessions(sessions: [ConsumptionSession]) async throws func deleteAllSessions() async } The crash is coming in from line 30 and 41, in other words, when trying to fetch data from the database. There doesn't seem to be any common trait for the crashes. They occur across iOS versions and device types. Any idea what might cause this?
5
0
300
Aug ’25
CloudKit Dashboard completely empty (no containers at all) while Xcode 26 still shows my production container iCloud.gainzCloud and builds fine – Tahoe 26.1 / Xcode 26.0 (17A321)
Hi, I’m completely stuck with a very strange CloudKit problem that started recently and has now killed all iCloud sync for a live production app. What is happening Production container: iCloud.gainzCloud (created ~11 months ago, has been working perfectly until now) In Xcode 26.0 (17A321): → Signing & Capabilities → iCloud is enabled → Container correctly shows as iCloud.gainzCloud → App builds and runs on device/simulator with zero provisioning or container errors CloudKit Dashboard (https://icloud.developer.apple.com/dashboard/): completely blank – “No containers found” Result: CloudKit sync is dead for every user (development + production environments) What I know for sure Apple Developer Support confirmed the container iCloud.gainzCloud still exists and is correctly attached to my Team ID on their backend Personal iCloud (Mail, Notes, Photos, etc.) syncs perfectly on the same Mac / same Apple ID under macOS Tahoe 26.1 I have NOT changed the password on either the Apple ID or the Developer Program account New containers I create appear in Xcode but never show up in the Dashboard Environment macOS Tahoe 26.1 (latest) Xcode Version 26.0 (17A321) Has anyone on the new Tahoe/Xcode 26 releases seen the CloudKit Dashboard suddenly go completely empty while Xcode still “sees” the container just fine? Any known trick to force the dashboard to re-index containers or clear whatever cache is broken? Thanks a lot in advance – this is blocking all iCloud functionality for a released app with active users.
Replies
0
Boosts
0
Views
67
Activity
Nov ’25
Good Morning I am building a app that uses cloudkit and am trying to find our the app limits allowed
I have been trying to find out the app limits to my app when released into the app store, I understand that in the public database the app worldwide can use 200g of bandwidth free per month. What happens after that? is it throttled? is there a pricing structure for overages? thanks
Replies
1
Boosts
0
Views
156
Activity
Jun ’25
iCloud Container Cannot Enable in Xcode — App ID Won’t Accept Container / Missing iCloud Documents Toggle
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
Replies
1
Boosts
0
Views
201
Activity
Dec ’25
NSPersistentCloudkitContainer Memory Leak -> Crash? (iOS 15 beta 4 & 5)
Background I have an established app in the App Store which has been using NSPersistentCloudkitContainer since iOS 13 without any issues. I've been running my app normally on an iOS device running the iOS 15 betas, mainly to see problems arise before my users see them. Ever since iOS 15 (beta 4) my app has failed to sync changes - no matter how small the change. An upload 'starts' but never completes. After a minute or so the app quits to the Home Screen and no useful information can be gleaned from crash reports. Until now I've had no idea what's going on. Possible Bug in the API? I've managed to replicate this behaviour on the simulator and on another device when building my app with Xcode 13 (beta 5) on iOS 15 (beta 5). It appears that NSPersistentCloudkitContainer has a memory leak and keeps ramping up the RAM consumption (and CPU at 100%) until the operating system kills the app. No code of mine is running. I'm not really an expert on these things and I tried to use Instruments to see if that would show me anything. It appears to be related to NSCloudkitMirroringDelegate getting 'stuck' somehow but I have no idea what to do with this information. My Core Data database is not tiny, but not massive by any means and NSPersistentCloudkitContainer has had no problems syncing to iCloud prior to iOS 15 (beta 4). If I restore my App Data (from an external backup file - 700MB with lots of many-many, many-one relationships, ckAssets, etc.) the data all gets added to Core Data without an issue at all. The console log (see below) then shows that a sync is created, scheduled & then started... but no data is uploaded. At this point the memory consumption starts and all I see is 'backgroundTask' warnings appear (only related to CloudKit) with no code of mine running. CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExporter analyzeHistoryInStore:withManagedObjectContext:error:](501): <PFCloudKitExporter: 0x600000301450>: Exporting changes since (0): <NSPersistentHistoryToken - { "4B90A437-3D96-4AC9-A27A-E0F633CE5D9D" = 906; }> CoreData: CloudKit: CoreData+CloudKit: -[PFCloudKitExportContext processAnalyzedHistoryInStore:inManagedObjectContext:error:]_block_invoke_3(251): Finished processing analyzed history with 29501 metadata objects to create, 0 deleted rows without metadata. CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate _scheduleAutomatedExportWithLabel:activity:completionHandler:](2800): <NSCloudKitMirroringDelegate: 0x6000015515c0> - Beginning automated export - ExportActivity: <CKSchedulerActivity: 0x60000032c500; containerID=<CKContainerID: 0x600002ed3240; containerIdentifier=iCloud.com.nitramluap.Somnus, containerEnvironment="Sandbox">, identifier=com.apple.coredata.cloudkit.activity.export.4B90A437-3D96-4AC9-A27A-E0F633CE5D9D, priority=2, xpcActivityCriteriaOverrides={ Priority=Utility }> CoreData: CloudKit: CoreData+CloudKit: -[NSCloudKitMirroringDelegate executeMirroringRequest:error:](765): <NSCloudKitMirroringDelegate: 0x6000015515c0>: Asked to execute request: <NSCloudKitMirroringExportRequest: 0x600002ed2a30> CBE1852D-7793-46B6-8314-A681D2038B38 2021-08-13 08:41:01.518422+1000 Somnus[11058:671570] [BackgroundTask] Background Task 68 ("CoreData: CloudKit Export"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. 2021-08-13 08:41:03.519455+1000 Somnus[11058:671570] [BackgroundTask] Background Task 154 ("CoreData: CloudKit Scheduling"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this. Just wondering if anyone else is having a similar issue? It never had a problem syncing an initial database restore prior to iOS 15 (beta 4) and the problems started right after installing iOS 15 (beta 4). I've submitted this to Apple Feedback and am awaiting a response (FB9412346). If this is unfixable I'm in real trouble (and my users are going to be livid). Thanks in advance!
Replies
25
Boosts
0
Views
13k
Activity
Jun ’25
Container Failing to Initialize After a Successful Migration & Initialization
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.
Replies
2
Boosts
0
Views
749
Activity
Nov ’25
What is going on with transformable
Hi, I keep trying to use transformable to store an array of strings with SwiftData, and I can see that it is activating the transformer, but it keeps saying that I am still using NSArray instead of NSData. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Unacceptable type of value for attribute: property = "category"; desired type = NSData; given type = Swift.__SwiftDeferredNSArray; value = ( yo, gurt ).' terminating due to uncaught exception of type NSException CoreSimulator 1010.10 - Device: iPhone 16 18.0 (6879535B-3174-4025-AD37-ED06E60291AD) - Runtime: iOS 18.0 (22A3351) - DeviceType: iPhone 16 Message from debugger: killed @Model class MyModel: Identifiable, Equatable { @Attribute(.transformable(by: StringArrayTransformer.self)) var category: [String]? @Attribute(.transformable(by: StringArrayTransformer.self)) var amenities: [String]? var image: String? var parentChunck: HenricoPostDataChunk_V1? init(category: [String]?, amenities: [String]?) { self.category = category self.amenities = amenities } } class StringArrayTransformer: ValueTransformer { override func transformedValue(_ value: Any?) -> Any? { print(value) guard let array = value as? [String] else { return nil } let data = try? JSONSerialization.data(withJSONObject: array, options: []) print(data) return data } override func reverseTransformedValue(_ value: Any?) -> Any? { guard let data = value as? Data else { return nil } let string = (try? JSONSerialization.jsonObject(with: data, options: [])) as? [String] print(string) return string } override class func transformedValueClass() -> AnyClass { return NSData.self } override class func allowsReverseTransformation() -> Bool { return true } static func register() { print("regitsering") ValueTransformer.setValueTransformer(StringArrayTransformer(), forName: .stringArrayTransformerName) } } extension NSValueTransformerName { static let stringArrayTransformerName = NSValueTransformerName("StringArrayTransformer") }
Replies
3
Boosts
0
Views
212
Activity
Jul ’25
iCloud Database Errors and Limits
We are currently implementing a custom iCloud sync for our macOS and iOS apps using CloudKit. Syncing works fine as long as the number of record sends is relatively small. But when we test with a large number of changes ( 80,000+ CKRecords ) we start running into problems. Our sending strategy is very conservative to avoid rate limits: We send records sequentially in batches of 250 records With about 2 seconds pause between operations Records are small and contain no assets (assets are uploaded separately) At some point we start receiving: “Database commit size exceeds limit” After that, CloudKit begins returning rate-limit errors with retryAfter-Information in the error. We wait for the retry time and try again, but from this moment on, nothing progresses anymore. Every subsequent attempt fails. We could not find anything in the official documentation regarding such a “commit size” limit or what triggers this failure state. So my questions are: Are there undocumented limits on the total number of records that can exist in an iCloud database (private or shared)? Is there a maximum volume of record modifications a container can accept within a certain timeframe, even if operations are split into small batches with pauses? Is it possible that sending large numbers of records in a row can temporarily or permanently “stall” a CloudKit container? Any insights or experiences would be greatly appreciated. Thank you!
Replies
0
Boosts
0
Views
210
Activity
Nov ’25
SwiftData shared across apps?
The stuff I've found by searching has confused me, so hopefully someone can help simplify it for me? I have an app (I use it for logging which books I've given away), and I could either add a bunch of things to the app, or I could have another app (possibly a CLI tool) to generate some reports I'd like.
Replies
0
Boosts
0
Views
94
Activity
May ’25
SwiftData with CloudKit Sync Issue
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?
Replies
2
Boosts
1
Views
303
Activity
Jan ’26
Consequences of incorrect VersionedSchema.versionIdentifier
About 4 months ago, I shipped the first version of my app with 4 versioned schemas that, unintentionally, had the same versionIdentifier of 1.2.0 in 2 of them: V1: 1.0.0 V2: 1.1.0 V3: 1.2.0 V4: 1.2.0 They are ordered correctly in the MigrationPlan, and they are all lightweight. Migration works, SwiftData doesn't crash on init and I haven't encountered any issues related to this. The app syncs with iCloud. Questions, preferable for anybody with knowledge of SwiftData internals: What will break in SwiftData when there are 2 duplicate numbers? Not that I would expect it to be safe, but does it happen to be safe to ship an update that changes V4's version to 1.3.0, what was originally intended?
Replies
0
Boosts
0
Views
171
Activity
Jul ’25
CloudKit CKRecordZone Deletion Issue
CloudKit CKRecordZone Deletion Issue Problem: CloudKit record zones deleted via CKDatabase.modifyRecordZones(deleting:) or CKModifyRecordZonesOperation are successfully removed but then reappear. I suspect they are automatically reinstated by CloudKit sync, despite successful deletion confirmation. Environment: SwiftData with CloudKit integration Custom CloudKit zones created for legacy zone-based sharing Observed Behavior: Create custom zone (e.g., "TestZone1") via CKDatabase.modifyRecordZones(saving:) Copy records to zone for sharing purposes Delete zone using any CloudKit deletion API - returns success, no errors Immediate verification: Zone is gone from database.allRecordZones() After SwiftData/CloudKit sync or app restart: Zone reappears Reproduction: Tested with three different deletion methods - all exhibit same behaviour: modifyRecordZones(deleting:) async API CKModifyRecordZonesOperation (fire-and-forget) CKModifyRecordZonesOperation with result callbacks Zone deletion succeeds, change tokens (used to track updates to shared records) cleaned up But zones are restored presumably by CloudKit background sync Expected: Deleted zones should remain deleted Actual: Zones are reinstated, creating orphaned zones
Replies
1
Boosts
0
Views
140
Activity
Dec ’25
NSPersistentCloudKitContainer losing data
Some users of my app are reporting total loss of data while using the app. This is happening specifically when they enable iCloud sync. I am doing following private func setupContainer(enableICloud: Bool) { container = NSPersistentCloudKitContainer(name: "") container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy guard let description: NSPersistentStoreDescription = container.persistentStoreDescriptions.first else { fatalError() } description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) description.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) if enableICloud == false { description.cloudKitContainerOptions = nil } container.loadPersistentStores { description, error in if let error { // Handle error } } } When user clicks on Toggle to enable/disable iCloud sync I just set the description.cloudKitContainerOptions to nil and then user is asked to restart the app. Apart from that I periodically run the clear history func deleteTransactionHistory() { let sevenDaysAgo = Calendar.current.date(byAdding: .day, value: -7, to: Date())! let purgeHistoryRequest = NSPersistentHistoryChangeRequest.deleteHistory(before: sevenDaysAgo) let backgroundContext = container.newBackgroundContext() backgroundContext.performAndWait { try! backgroundContext.execute(purgeHistoryRequest) } }
Replies
4
Boosts
0
Views
1.3k
Activity
Nov ’25
SwiftData Background Fetching?
Hi, I am experiencing main thread freezes from fetching on Main Actor. Attempting to move the function to a background thread, but whenever I reference the TestModel in a nonisolated context or in another model actor, I get this warning: Main actor-isolated conformance of 'TestModel' to 'PersistentModel' cannot be used in actor-isolated context; this is an error in the Swift 6 language mode Is there a way to do this correctly? Recreation, warning on line 13: class TestModel { var property: Bool = true init() {} } struct SendableTestModel: Sendable { let property: Bool } @ModelActor actor BackgroundActor { func fetch() throws -> [SendableTestModel] { try modelContext.fetch(FetchDescriptor<TestModel>()).map { SendableTestModel(property: $0.property) } } }
Replies
1
Boosts
0
Views
149
Activity
Jul ’25
Core Data complaining about store being opened without persistent history tracking... but I don't think that it has been
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?
Replies
2
Boosts
0
Views
1.2k
Activity
May ’25
CloudKit: how to handle CKError partialFailure when using NSPersistentCloudKitContainer?
I'm using NSPersistentCloudKitContainer with Core Data and I receive errors because my iCloud space is full. The errors printed are the following: <CKError 0x280df8e40: "Quota Exceeded" (25/2035); server message = "Quota exceeded"; op = 61846C533467A5DF; uuid = 6A144513-033F-42C2-9E27-693548EF2150; Retry after 342.0 seconds>. I want to inform the user about this issue, but I can't find a way to access the details of the error. I'm listening to NSPersistentCloudKitContainer.eventChangedNotification, I receive a error of type .partialFailure. But when I want to access the underlying errors, the partialErrorsByItemID property on the error is nil. How can I access this Quota Exceeded error? import Foundation import CloudKit import Combine import CoreData class SyncMonitor { fileprivate var subscriptions = Set<AnyCancellable>() init() { NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification) .sink { notification in if let cloudEvent = notification.userInfo?[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { guard let ckerror = cloudEvent.error as? CKError else { return } print("Error: \(ckerror.localizedDescription)") if ckerror.code == .partialFailure { guard let errors = ckerror.partialErrorsByItemID else { return } for (_, error) in errors { if let currentError = error as? CKError { print(currentError.localizedDescription) } } } } } // end of sink .store(in: &subscriptions) } }
Replies
2
Boosts
1
Views
1.5k
Activity
Aug ’25
"Failed to set up CloudKit integration" in TestFlight build
I'm building a macOS + iOS SwiftUI app using Xcode 14.1b3 on a Mac running macOS 13.b11. The app uses Core Data + CloudKit. With development builds, CloudKit integration works on the Mac app and the iOS app. Existing records are fetched from iCloud, and new records are uploaded to iCloud. Everybody's happy. With TestFlight builds, the iOS app has no problems. But CloudKit integration isn't working in the Mac app at all. No existing records are fetched, no new records are uploaded. In the Console, I see this message: error: CoreData+CloudKit: Failed to set up CloudKit integration for store: <NSSQLCore: 0x1324079e0> (URL: <local file url>) Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.cloudd was invalidated: failed at lookup with error 159 - Sandbox restriction.} I thought it might be that I was missing the com.apple.security.network.client entitlement, but adding that didn't help. Any suggestions what I might be missing? (It's my first sandboxed Mac app, so it might be really obvious to anyone but me.)
Replies
4
Boosts
1
Views
3.7k
Activity
Apr ’25
SwiftData and SpotLight Search
Hi all, has anybody found the trick how to get SwiftData working with SpotLight Search? Setting the attribute "spotlight" in the Model definition seems to do nothing at all, as pointed out by Paul Hudson in his new book as well (https://www.hackingwithswift.com/quick-start/swiftdata/how-to-index-swiftdata-objects-in-spotlight) Thanks a lot!
Replies
3
Boosts
3
Views
1.1k
Activity
Apr ’25
SwiftData crash when using a @Query sort descriptor with a relationship
I am using SwiftData for storage and have a view that uses the @Query property wrapper with a sort descriptor that points to a relationship on a model. In a release build on device running iOS 18.3, the app crashes. This is the line that crashes: @Query(sort: \Item.info.endDate, order: .reverse) private var items: [Item] Item has a relationship to ItemInfo, which is where the endDate property is defined. This code works in debug and on a simulator. In the project referenced here: https://github.com/lepolt/swiftdata-crash, change the scheme build configuration to “Release” and run on device. The app will crash. Using Xcode Version 16.2 (16C5032a) iPhone 12, iOS 18.3 (22D60)
Replies
9
Boosts
12
Views
1.5k
Activity
Aug ’25
CloudKit Database console crashes
I see a chunk load error in the browser console. I already reported this: FB17664487
Replies
3
Boosts
1
Views
132
Activity
May ’25
SwiftData Fatal error: Editors must register their identifiers before invoking operations on this store
I have a UIKit app where I've adopted SwiftData and I'm struggling with a crash coming in from some of my users. I'm not able to reproduce it myself and as it only happens to a small fraction of my user base, it seems like a race condition of some sort. This is the assertion message: SwiftData/DefaultStore.swift:453: Fatal error: API Contract Violation: Editors must register their identifiers before invoking operations on this store SwiftData.DefaultStore: 00CF060A-291A-4E79-BEC3-E6A6B20F345E did not. (ID is unique per crash) This is the ModelActor that crashes: @available(iOS 17, *) @ModelActor actor ConsumptionDatabaseStorage: ConsumptionSessionStorage { struct Error: LocalizedError { var errorDescription: String? } private let sortDescriptor = [SortDescriptor(\SDConsumptionSession.startTimeUtc, order: .reverse)] static func createStorage(userId: String) throws -> ConsumptionDatabaseStorage { guard let appGroupContainer = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: UserDefaults.defaultAppGroupIdentifier) else { throw Error(errorDescription: "Invalid app group container ID") } func createModelContainer(databaseUrl: URL) throws -> ModelContainer { return try ModelContainer(for: SDConsumptionSession.self, SDPriceSegment.self, configurations: ModelConfiguration(url: databaseUrl)) } let databaseUrl = appGroupContainer.appendingPathComponent("\(userId).sqlite") do { return self.init(modelContainer: try createModelContainer(databaseUrl: databaseUrl)) } catch { // Creating the model storage failed. Remove the database file and try again. try? FileManager.default.removeItem(at: databaseUrl) return self.init(modelContainer: try createModelContainer(databaseUrl: databaseUrl)) } } func isStorageEmpty() async -> Bool { (try? self.modelContext.fetchCount(FetchDescriptor<SDConsumptionSession>())) ?? 0 == 0 // <-- Crash here! } func sessionsIn(interval: DateInterval) async throws -> [ConsumptionSession] { let fetchDescriptor = FetchDescriptor(predicate: #Predicate<SDConsumptionSession> { sdSession in if let startDate = sdSession.startTimeUtc { return interval.start <= startDate && interval.end > startDate } else { return false } }, sortBy: self.sortDescriptor) let consumptionSessions = try self.modelContext.fetch(fetchDescriptor) // <-- Crash here! return consumptionSessions.map { ConsumptionSession(swiftDataSession: $0) } } func updateSessions(sessions: [ConsumptionSession]) async throws { if #unavailable(iOS 18) { // Price segments are duplicated if re-inserted so unfortunately we have to delete and reinsert sessions. // On iOS 18, this is enforced by the #Unique macro on SDPriceSegment. let sessionIds = Set(sessions.map(\.id)) try self.modelContext.delete(model: SDConsumptionSession.self, where: #Predicate<SDConsumptionSession> { sessionIds.contains($0.id) }) } for session in sessions { self.modelContext.insert(SDConsumptionSession(consumptionSession: session)) } if self.modelContext.hasChanges { try self.modelContext.save() } } func deleteAllSessions() async { if #available(iOS 18, *) { try? self.modelContainer.erase() } else { self.modelContainer.deleteAllData() } } } The actor conforms to this protocol: protocol ConsumptionSessionStorage { func isStorageEmpty() async -> Bool func hasCreditCardSessions() async -> Bool func sessionsIn(interval: DateInterval) async throws -> [ConsumptionSession] func updateSessions(sessions: [ConsumptionSession]) async throws func deleteAllSessions() async } The crash is coming in from line 30 and 41, in other words, when trying to fetch data from the database. There doesn't seem to be any common trait for the crashes. They occur across iOS versions and device types. Any idea what might cause this?
Replies
5
Boosts
0
Views
300
Activity
Aug ’25