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

Is that possible to update ModelContainer?
Here is what I thought I want to give each user a unique container, when the user login or register, the user could isolate their data in specific container. I shared the container in a singleton actor, I found it's possible to update the container in that actor. But I think it won't affect the modelContext which is in the Environment. Does SwiftData allow me or recommend to do that?
4
0
226
Nov ’25
Swift Data Predicate Evaluation Crashes in Release Build When Generics Used
I'm using Swift Data for an app that requires iOS 18. All of my models conform to a protocol that guarantees they have a 'serverID' String variable. I wrote a function that would allow me to pass in a serverID String and have it fetch the model object that matched. Because I am lazy and don't like writing the same functions over and over, I used a Self reference so that all of my conforming models get this static function. Imagine my model is called "WhatsNew". Here's some code defining the protocol and the fetching function. protocol RemotelyFetchable: PersistentModel { var serverID: String { get } } extension WhatsNew: RemotelyFetchable {} extension RemotelyFetchable { static func fetchOne(withServerID identifier: String, inContext modelContext: ModelContext) -> Self? { var fetchDescriptor = FetchDescriptor<Self>() fetchDescriptor.predicate = #Predicate<Self> { $0.serverID == identifier } do { let allModels = try modelContext.fetch(fetchDescriptor) return allModels.first } catch { return nil } } } Worked great! Or so I thought... I built this and happily ran a debug build in the Simulator and on devices for months while developing the initial version but when I went to go do a release build for TestFlight, that build reliably crashed on every device with a message like this: SwiftData/DataUtilities.swift:65: Fatal error: Couldn't find \WhatsNew. on WhatsNew with fields [SwiftData.Schema.PropertyMetadata(name: "serverID", keypath: \WhatsNew., defaultValue: nil, metadata: Optional(Attribute - name: , options: [unique], valueType: Any, defaultValue: nil, hashModifier: nil)), SwiftData.Schema.PropertyMetadata(name: "title", keypath: \WhatsNew., defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "bulletPoints", keypath: \WhatsNew.)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "dateDescription", keypath: \WhatsNew., defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "readAt", keypath: \WhatsNew.)>, defaultValue: nil, metadata: nil)] It seems (cannot confirm) that something in the release build optimization process is stripping out some metadata / something about these models that makes this predicate crash. Tested on iOS 18.0 and 18.1 beta. How can I resolve this? I have two dozen types that conform to this protocol. I could manually specialize this function for every type myself but... ugh.
2
2
1.5k
Oct ’25
Naming Collision Between Model Attribute and Enum Case in SwiftData and CloudKit
There is a conflict in SwiftData (specifically when synced with CloudKit) when a @Model attribute shares the same name as a case within its assigned enum type. When this occurs, accessing the attribute on a model instance consistently returns the value corresponding to the enum case name, rather than the actual value persisted in the database. Steps to Reproduce Define an enumeration (e.g., Status) with a case that matches a planned property name (e.g., case status). Create a SwiftData @Model that uses this enum. Name the property in the model the same as the enum case. Attempt to save and then retrieve the value. Example Code enum TaskStatus: String, Codable { case status // The conflict source case pending case completed } @Model class TodoItem { // Conflict: Property name matches enum case name var status: TaskStatus init(status: TaskStatus) { self.status = status } } Expected Behavior The property item.status should return the value stored in the database (e.g., .pending or .completed). Actual Behavior The property item.status consistently resolves to the enum case .status, ignoring the actual persisted data.
1
0
102
Jan ’26
Increase Background Asset Limitations
Hello, From the documentation linked below, the limitations for Background Assets are the following: Size Limit: 200 GB Asset Pack Count: 100 I'm expecting I will need ~175 Asset Packs and around 500GB of storage. I understand Background Assets is a new, but is there a process or a potential that these limits will be increased in the future? Or is there a way to request an increase? I've tried contacting Apple Support as this is more of an Admin issue, however they've directed me here. Case ID 102725356578 https://aninterestingwebsite.com/help/app-store-connect/reference/apple-hosted-asset-pack-size-limits Thank you, Tanner
4
0
366
Oct ’25
CloudKit references — is this a forward reference or a back reference?
I'm trying to understand the terminology around forward vs backward references in CloudKit. Say I have two record types: User LeaderboardScore (a score belongs to a user) The score record stores a user reference: score["user"] = CKRecord.Reference( recordID: userRecordID, action: .deleteSelf ) So: LeaderboardScore → User The user record does not store any references to scores From a data-model perspective: Is this considered a forward reference (child → parent)? Or a back reference, since the score is "pointing back" to its owner? My use case is having leaderboard in my app and so i have created a user table to store all the users and a score table for saving the scores of each user of the app.
4
0
186
Mar ’26
CloudKit: Records not indexing
Since publishing new record types to my CloudKit schema in production, a previously unchanged record type has stopped indexing new records. While records of this type are successfully saved without errors, they are not returned in query results—they can only be accessed directly via their recordName. This issue occurs exclusively in the Production environment, both in the CloudKit Console and our iOS app. The problem began on July 21, 2025, and continues to persist. The issue affects only new records of this specific record type; all other types are indexing and querying as expected. The affected record's fields are properly configured with the appropriate index types (e.g., QUERYABLE) and have been not been modified prior to publishing the schema. With this, are there any steps I should take to restore indexing functionality for this record type in Production? There have been new records inserted, and I would prefer to not have to reset the production database, if possible.
4
1
512
Aug ’25
Swiftdata cloudkit synchronization issues
Hi, I did cloudkit synchronization using swiftdata. However, synchronization does not occur automatically, and synchronization occurs intermittently only when the device is closed and opened. For confirmation, after changing the data in Device 1 (saving), when the data is fetched from Device 2, there is no change. I've heard that there's still an issue with swiftdata sync and Apple is currently troubleshooting it, is the phenomenon I'm experiencing in the current version normal?
2
1
622
Oct ’25
Suspicious CloudKit Telemetry Data
Starting 20th March 2025, I see an increase in bandwidth and latency for one of my CloudKit projects. I'm using NSPersistentCloudKitContainer to synchronise my data. I haven't changed any CloudKit scheme during that time but shipped an update. Since then, I reverted some changes from that update, which could have led to changes in the sync behaviour. Is anyone else seeing any issues? I would love to file a DTS and use one of my credits for that, but unfortunately, I can't because I cannot reproduce it with a demo project because I cannot travel back in time and check if it also has an increase in metrics during that time. Maybe an Apple engineer can green-light me filing a DTS request, please.
0
1
159
Apr ’25
CKSyncEngine on macOS: Automatic Fetch Extremely Slow Compared to iOS
Hi everyone, We’re currently using CKSyncEngine to sync all our locally persisted data across user devices (iOS and macOS) via iCloud. We’ve noticed something strange and reproducible: On iOS, when the CKSyncEngine is initialized with manual sync behavior, both manual calls to fetchChanges() and sendChanges() happen nearly instantly (usually within seconds). Automatic syncing is also very fast. On macOS, when the CKSyncEngine is initialized with manual sync behavior, fetchChanges() and sendChanges() are also fast and responsive. However, once CKSyncEngine is initialized with automatic syncing enabled on macOS: sendChanges() still appears to transmit changes immediately. But automatic fetching becomes significantly slower — often taking minutes to pick up changes from the cloud, even when new data is already available. Even manual calls to fetchChanges() behave as if they’re throttled or delayed, rather than performing an immediate fetch. Our questions: Is this delay in automatic (and post-automatic manual) fetch behavior on macOS expected, or possibly a bug? Are there specific macOS constraints that impact CKSyncEngine differently than on iOS? Once CKSyncEngine has been initialized in automatic mode, is fetchChanges() no longer treated as a truly manual trigger? Is there a recommended workaround to enable fast sync behavior on macOS — for example, by sticking to manual sync configuration and triggering sync using a CKSubscription-based mechanism when remote changes occur? Any guidance, clarification, or experiences from other developers (or Apple engineers) would be greatly appreciated — especially regarding maintaining parity between iOS and macOS sync performance. Thanks in advance!
1
1
169
Oct ’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.6k
Apr ’25
Production Mac app becomes progressively unusable in Issues workspace; Mac_Dev remains fast
The production macOS build is showing severe performance problems, while Mac_Dev performs normally. Observed behavior in production Mac build: Issue board scrolling becomes inconsistent or nearly unusable Changing an issue status in detail view is very slow Scrolling the status menu/options can be slow Typing in issue description/notes fields becomes sluggish Dragging issues between milestones/statuses on the board can lag badly Observed behavior in Mac_Dev: Board scrolling is smooth Status changes are immediate Typing in description fields is responsive Drag/drop between milestones works well Important comparison: Mac_Dev appears to run against an isolated local SwiftData store Production Mac app uses the normal CloudKit-backed store Because the same UI is fast in Mac_Dev, this does not look like a pure rendering problem Most likely cause is production store / CloudKit sync churn amplifying existing SwiftUI invalidation and save behavior Current hypothesis: The production app is saving or observing live Issue mutations too aggressively Detail view edits and some quick actions may be causing repeated saves / broad view invalidation Cloud-backed persistence likely makes the problem much worse than the isolated dev store The UI architecture may still need cleanup, but the production data lane is likely a major factor Any help in understanding how best to address this would be helpful.
2
0
55
3d
Missing demo project
Hi forum! I’m currently following a series of videos about SwiftData. In the WWDC23 Build an app with SwiftData video, it mentions that you can follow up with a demo project. However, I’m encountering an issue (at least in my case) where there’s no link on the entire page to download the project. I can download the video and other resources (even using the Developer’s App), but there’s no link for the project. Does anyone else face this issue? Is it possible that the project has been removed? I’m using my developer (single user) account, by the way. Any guidance would be greatly appreciated!
1
0
328
3w
macOS SwiftData app never syncs with CloudKit
I'm using SwiftData with CloutKit with a very simple app. Data syncs between iOS, iPadOS, and visionOS, but not macOS. From what I can tell, macOS is never getting CK messages unless I'm running the app from Xcode. I can listen for the CK messages and show a line in a debug overlay. This works perfectly when I run from Xcode. I can see the notifications and see updates in my app. However, if I just launch the app outside of Xcode I will never see any changes or notifications. It is as if the Mac app never even tries to contact CloudKit. Schema has been deployed in the CloudKit console. The app is based on the multi-platform Xcode template. Again, only the macOS version has this issue. Is there some extra permission or setting I need to set up in order to use CloudKit on macOS? @State private var publisher = NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification).receive(on: DispatchQueue.main) .onReceive(publisher) { notification in // Listen for changes in CK events if let userInfo = notification.userInfo, let event = userInfo[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { let message = "CloudKit Sync: \(event.type.rawValue) - \(event.succeeded ? "Success" : "Failed") - \(event.description)" // Store for UI display syncNotifications.append(message) if syncNotifications.count > 10 { syncNotifications.removeFirst() } } } .overlay(alignment: .topTrailing) { if !syncNotifications.isEmpty { VStack(alignment: .leading) { ForEach(syncNotifications, id: \.self) { notification in Text(notification) .padding(8) } } .frame(width: 800, height: 500) .cornerRadius(8) .background(Color.secondary.opacity(0.2)) .padding() .transition(.move(edge: .top)) } }
1
1
206
May ’25
Fatal error on rollback after delete
I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<ChildModel> I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test environment, so the model that's being deleted (or any other) is not being accessed by any other part of the application. However, problem looks the same in the real app. I also changed the target version of iOS from 18.0 to 26.0, but to no avail. My models look kind of like this: @Model final class ParentModel { var name: String @Relationship(deleteRule: .cascade, inverse: \ChildModel.parent) var children: [ChildModel]? init(name: String) { self.name = name } } @Model final class ChildModel { var name: String @Relationship(deleteRule: .nullify) var parent: ParentModel? init(name: String) { self.name = name } } I tried many approaches that didn't help: Fetching all children (via fetch) just to "populate" the context Accessing all children on parent model (via let _ = parentModel.children?.count) Deleting all children reading models from parent: for child in parentModel.children ?? [] { modelContext.delete(child) } Deleting all children like this: let parentPersistentModelID = parentModel.persistentModelID modelContext.delete(model: ChildModel.self, where: #Predicate { $0.parent.persistentModelID == parentPersistentModelID }, includeSubclasses: true) Removing @Relationship(deleteRule: .nullify) from ChildModel relationship definition I found 2 solution for the problem: To manually fetch and delete all children prior to deleting parent: let parentPersistentModelID = parentModel.persistentModelID for child in try modelContext.fetch(FetchDescriptor<ChildModel>(predicate: #Predicate { $0.parent.persistentModelID == parentPersistentModelID })) { modelContext.delete(child) } modelContext.delete(parentModel) Trying to run my code in child context (let childContext = ModelContext(modelContext.container)) All that sounds to me like a problem deep inside Swift Data itself. The first solution I found, fetching potentially hundreds of child models just to delete them in case I might need to rollback changes on some error, sounds like awful waste of resources to me. The second one however seems to work fine has that drawback that I can't fully test my code. Right now I can wrap the context (literally creating class that holds ModelContext and calls its methods) and in tests for throwing methods force them to throw. By creating scratch ModelContext I loose that possibility. What might be the real issue here? Am I missing something?
2
0
113
1w
SwiftData - Cloudkit stopped syncing
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.
3
1
251
Sep ’25
CoreData + CloudKit -- Many-to-Many Relationship not Syncing
In an iOS App that uses CKShare I have a many-to-many relationship that does not consistently sync between the share's N participants. The relationship is between Group and Player as group.players and player.groups. As an example, given 3 group each with 4 players (aka 4:4:4), some devices show CoreData (it is NOT a UI issue) with 4:2:3 or 3:4:4. (A deletion of CoreData from a device, forcing a full re-sync from CloudKit, seems to populate the group:player relationships consistently; but obviously that is impractical to resolving the issue). How do I avoid these sync-from-CloudKit inconsistencies? Note: AI agents generally suggest adding a CoreData 'join' entity - such as 'GroupPlayer'. Is that THE fix?
1
0
74
1w
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
How to diagnose spurious SwiftDataMacros error
I have a Package.swift file that builds and runs from Xcode 15.2 without issue but fails to compile when built from the command line ("swift build"). The swift version is 6.0.3. I'm at wits end trying to diagnose this and would welcome any thoughts. The error in question is error: external macro implementation type 'SwiftDataMacros.PersistentModelMacro' could not be found for macro 'Model()'; plugin for module 'SwiftDataMacros' not found The code associated with the module is very vanilla. import Foundation import SwiftData @Model public final class MyObject { @Attribute(.unique) public var id:Int64 public var vertexID:Int64 public var updatedAt:Date public var codeUSRA:Int32 init(id:Int64, vertexID:Int64, updatedAt:Date, codeUSRA:Int32) { self.id = id self.vertexID = vertexID self.updatedAt = updatedAt self.codeUSRA = codeUSRA } public static func create(id:Int64, vertexID:Int64, updatedAt:Date, codeUSRA:Int32) -> MyObject { MyObject(id: id, vertexID: vertexID, updatedAt: updatedAt, codeUSRA: codeUSRA) } } Thank you.
1
1
350
Apr ’25
Is that possible to update ModelContainer?
Here is what I thought I want to give each user a unique container, when the user login or register, the user could isolate their data in specific container. I shared the container in a singleton actor, I found it's possible to update the container in that actor. But I think it won't affect the modelContext which is in the Environment. Does SwiftData allow me or recommend to do that?
Replies
4
Boosts
0
Views
226
Activity
Nov ’25
Swift Data Predicate Evaluation Crashes in Release Build When Generics Used
I'm using Swift Data for an app that requires iOS 18. All of my models conform to a protocol that guarantees they have a 'serverID' String variable. I wrote a function that would allow me to pass in a serverID String and have it fetch the model object that matched. Because I am lazy and don't like writing the same functions over and over, I used a Self reference so that all of my conforming models get this static function. Imagine my model is called "WhatsNew". Here's some code defining the protocol and the fetching function. protocol RemotelyFetchable: PersistentModel { var serverID: String { get } } extension WhatsNew: RemotelyFetchable {} extension RemotelyFetchable { static func fetchOne(withServerID identifier: String, inContext modelContext: ModelContext) -> Self? { var fetchDescriptor = FetchDescriptor<Self>() fetchDescriptor.predicate = #Predicate<Self> { $0.serverID == identifier } do { let allModels = try modelContext.fetch(fetchDescriptor) return allModels.first } catch { return nil } } } Worked great! Or so I thought... I built this and happily ran a debug build in the Simulator and on devices for months while developing the initial version but when I went to go do a release build for TestFlight, that build reliably crashed on every device with a message like this: SwiftData/DataUtilities.swift:65: Fatal error: Couldn't find \WhatsNew. on WhatsNew with fields [SwiftData.Schema.PropertyMetadata(name: "serverID", keypath: \WhatsNew., defaultValue: nil, metadata: Optional(Attribute - name: , options: [unique], valueType: Any, defaultValue: nil, hashModifier: nil)), SwiftData.Schema.PropertyMetadata(name: "title", keypath: \WhatsNew., defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "bulletPoints", keypath: \WhatsNew.)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "dateDescription", keypath: \WhatsNew., defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "readAt", keypath: \WhatsNew.)>, defaultValue: nil, metadata: nil)] It seems (cannot confirm) that something in the release build optimization process is stripping out some metadata / something about these models that makes this predicate crash. Tested on iOS 18.0 and 18.1 beta. How can I resolve this? I have two dozen types that conform to this protocol. I could manually specialize this function for every type myself but... ugh.
Replies
2
Boosts
2
Views
1.5k
Activity
Oct ’25
Naming Collision Between Model Attribute and Enum Case in SwiftData and CloudKit
There is a conflict in SwiftData (specifically when synced with CloudKit) when a @Model attribute shares the same name as a case within its assigned enum type. When this occurs, accessing the attribute on a model instance consistently returns the value corresponding to the enum case name, rather than the actual value persisted in the database. Steps to Reproduce Define an enumeration (e.g., Status) with a case that matches a planned property name (e.g., case status). Create a SwiftData @Model that uses this enum. Name the property in the model the same as the enum case. Attempt to save and then retrieve the value. Example Code enum TaskStatus: String, Codable { case status // The conflict source case pending case completed } @Model class TodoItem { // Conflict: Property name matches enum case name var status: TaskStatus init(status: TaskStatus) { self.status = status } } Expected Behavior The property item.status should return the value stored in the database (e.g., .pending or .completed). Actual Behavior The property item.status consistently resolves to the enum case .status, ignoring the actual persisted data.
Replies
1
Boosts
0
Views
102
Activity
Jan ’26
Increase Background Asset Limitations
Hello, From the documentation linked below, the limitations for Background Assets are the following: Size Limit: 200 GB Asset Pack Count: 100 I'm expecting I will need ~175 Asset Packs and around 500GB of storage. I understand Background Assets is a new, but is there a process or a potential that these limits will be increased in the future? Or is there a way to request an increase? I've tried contacting Apple Support as this is more of an Admin issue, however they've directed me here. Case ID 102725356578 https://aninterestingwebsite.com/help/app-store-connect/reference/apple-hosted-asset-pack-size-limits Thank you, Tanner
Replies
4
Boosts
0
Views
366
Activity
Oct ’25
CloudKit references — is this a forward reference or a back reference?
I'm trying to understand the terminology around forward vs backward references in CloudKit. Say I have two record types: User LeaderboardScore (a score belongs to a user) The score record stores a user reference: score["user"] = CKRecord.Reference( recordID: userRecordID, action: .deleteSelf ) So: LeaderboardScore → User The user record does not store any references to scores From a data-model perspective: Is this considered a forward reference (child → parent)? Or a back reference, since the score is "pointing back" to its owner? My use case is having leaderboard in my app and so i have created a user table to store all the users and a score table for saving the scores of each user of the app.
Replies
4
Boosts
0
Views
186
Activity
Mar ’26
Cloudkit dashboard won't load
For the past several days every time I log in to to the Cloudkit dashboard I get Error looking up Developer Teams, Please sign out and try again. No amount of singing out and back in changes anything.
Replies
6
Boosts
2
Views
516
Activity
Nov ’25
CloudKit: Records not indexing
Since publishing new record types to my CloudKit schema in production, a previously unchanged record type has stopped indexing new records. While records of this type are successfully saved without errors, they are not returned in query results—they can only be accessed directly via their recordName. This issue occurs exclusively in the Production environment, both in the CloudKit Console and our iOS app. The problem began on July 21, 2025, and continues to persist. The issue affects only new records of this specific record type; all other types are indexing and querying as expected. The affected record's fields are properly configured with the appropriate index types (e.g., QUERYABLE) and have been not been modified prior to publishing the schema. With this, are there any steps I should take to restore indexing functionality for this record type in Production? There have been new records inserted, and I would prefer to not have to reset the production database, if possible.
Replies
4
Boosts
1
Views
512
Activity
Aug ’25
Swiftdata cloudkit synchronization issues
Hi, I did cloudkit synchronization using swiftdata. However, synchronization does not occur automatically, and synchronization occurs intermittently only when the device is closed and opened. For confirmation, after changing the data in Device 1 (saving), when the data is fetched from Device 2, there is no change. I've heard that there's still an issue with swiftdata sync and Apple is currently troubleshooting it, is the phenomenon I'm experiencing in the current version normal?
Replies
2
Boosts
1
Views
622
Activity
Oct ’25
Suspicious CloudKit Telemetry Data
Starting 20th March 2025, I see an increase in bandwidth and latency for one of my CloudKit projects. I'm using NSPersistentCloudKitContainer to synchronise my data. I haven't changed any CloudKit scheme during that time but shipped an update. Since then, I reverted some changes from that update, which could have led to changes in the sync behaviour. Is anyone else seeing any issues? I would love to file a DTS and use one of my credits for that, but unfortunately, I can't because I cannot reproduce it with a demo project because I cannot travel back in time and check if it also has an increase in metrics during that time. Maybe an Apple engineer can green-light me filing a DTS request, please.
Replies
0
Boosts
1
Views
159
Activity
Apr ’25
Error when running a modelContext rollback
I'm getting the following error message when executing the rollback method in a modelContext, what could be causing this ? SwiftData/ModelSnapshot.swift:46: Fatal error: A ModelSnapshot must be initialized with a known-keys dictionary
Replies
5
Boosts
1
Views
172
Activity
May ’25
CKSyncEngine on macOS: Automatic Fetch Extremely Slow Compared to iOS
Hi everyone, We’re currently using CKSyncEngine to sync all our locally persisted data across user devices (iOS and macOS) via iCloud. We’ve noticed something strange and reproducible: On iOS, when the CKSyncEngine is initialized with manual sync behavior, both manual calls to fetchChanges() and sendChanges() happen nearly instantly (usually within seconds). Automatic syncing is also very fast. On macOS, when the CKSyncEngine is initialized with manual sync behavior, fetchChanges() and sendChanges() are also fast and responsive. However, once CKSyncEngine is initialized with automatic syncing enabled on macOS: sendChanges() still appears to transmit changes immediately. But automatic fetching becomes significantly slower — often taking minutes to pick up changes from the cloud, even when new data is already available. Even manual calls to fetchChanges() behave as if they’re throttled or delayed, rather than performing an immediate fetch. Our questions: Is this delay in automatic (and post-automatic manual) fetch behavior on macOS expected, or possibly a bug? Are there specific macOS constraints that impact CKSyncEngine differently than on iOS? Once CKSyncEngine has been initialized in automatic mode, is fetchChanges() no longer treated as a truly manual trigger? Is there a recommended workaround to enable fast sync behavior on macOS — for example, by sticking to manual sync configuration and triggering sync using a CKSubscription-based mechanism when remote changes occur? Any guidance, clarification, or experiences from other developers (or Apple engineers) would be greatly appreciated — especially regarding maintaining parity between iOS and macOS sync performance. Thanks in advance!
Replies
1
Boosts
1
Views
169
Activity
Oct ’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.6k
Activity
Apr ’25
Production Mac app becomes progressively unusable in Issues workspace; Mac_Dev remains fast
The production macOS build is showing severe performance problems, while Mac_Dev performs normally. Observed behavior in production Mac build: Issue board scrolling becomes inconsistent or nearly unusable Changing an issue status in detail view is very slow Scrolling the status menu/options can be slow Typing in issue description/notes fields becomes sluggish Dragging issues between milestones/statuses on the board can lag badly Observed behavior in Mac_Dev: Board scrolling is smooth Status changes are immediate Typing in description fields is responsive Drag/drop between milestones works well Important comparison: Mac_Dev appears to run against an isolated local SwiftData store Production Mac app uses the normal CloudKit-backed store Because the same UI is fast in Mac_Dev, this does not look like a pure rendering problem Most likely cause is production store / CloudKit sync churn amplifying existing SwiftUI invalidation and save behavior Current hypothesis: The production app is saving or observing live Issue mutations too aggressively Detail view edits and some quick actions may be causing repeated saves / broad view invalidation Cloud-backed persistence likely makes the problem much worse than the isolated dev store The UI architecture may still need cleanup, but the production data lane is likely a major factor Any help in understanding how best to address this would be helpful.
Replies
2
Boosts
0
Views
55
Activity
3d
Missing demo project
Hi forum! I’m currently following a series of videos about SwiftData. In the WWDC23 Build an app with SwiftData video, it mentions that you can follow up with a demo project. However, I’m encountering an issue (at least in my case) where there’s no link on the entire page to download the project. I can download the video and other resources (even using the Developer’s App), but there’s no link for the project. Does anyone else face this issue? Is it possible that the project has been removed? I’m using my developer (single user) account, by the way. Any guidance would be greatly appreciated!
Replies
1
Boosts
0
Views
328
Activity
3w
macOS SwiftData app never syncs with CloudKit
I'm using SwiftData with CloutKit with a very simple app. Data syncs between iOS, iPadOS, and visionOS, but not macOS. From what I can tell, macOS is never getting CK messages unless I'm running the app from Xcode. I can listen for the CK messages and show a line in a debug overlay. This works perfectly when I run from Xcode. I can see the notifications and see updates in my app. However, if I just launch the app outside of Xcode I will never see any changes or notifications. It is as if the Mac app never even tries to contact CloudKit. Schema has been deployed in the CloudKit console. The app is based on the multi-platform Xcode template. Again, only the macOS version has this issue. Is there some extra permission or setting I need to set up in order to use CloudKit on macOS? @State private var publisher = NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification).receive(on: DispatchQueue.main) .onReceive(publisher) { notification in // Listen for changes in CK events if let userInfo = notification.userInfo, let event = userInfo[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { let message = "CloudKit Sync: \(event.type.rawValue) - \(event.succeeded ? "Success" : "Failed") - \(event.description)" // Store for UI display syncNotifications.append(message) if syncNotifications.count > 10 { syncNotifications.removeFirst() } } } .overlay(alignment: .topTrailing) { if !syncNotifications.isEmpty { VStack(alignment: .leading) { ForEach(syncNotifications, id: \.self) { notification in Text(notification) .padding(8) } } .frame(width: 800, height: 500) .cornerRadius(8) .background(Color.secondary.opacity(0.2)) .padding() .transition(.move(edge: .top)) } }
Replies
1
Boosts
1
Views
206
Activity
May ’25
Fatal error on rollback after delete
I encountered an error when trying to rollback context after deleting some model with multiple one-to-many relationships when encountered a problem later in a deleting method and before saving the changes. Something like this: do { // Fetch model modelContext.delete(model) // Do some async work that potentially throws try modelContext.save() } catch { modelContext.rollback() } When relationship is empty - the parent has no children - I can safely delete and rollback with no issues. However, when there is even one child when I call even this code: modelContext.delete(someModel) modelContext.rollback() I'm getting a fatal error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<ChildModel> I use ModelContext from within the ModelActor but using mainContext changes nothing. My ModelContainer is quite simple and problem occurs on both in-memory and persistent storage, with or without CloudKit database being enabled. I can isolate the issue in test environment, so the model that's being deleted (or any other) is not being accessed by any other part of the application. However, problem looks the same in the real app. I also changed the target version of iOS from 18.0 to 26.0, but to no avail. My models look kind of like this: @Model final class ParentModel { var name: String @Relationship(deleteRule: .cascade, inverse: \ChildModel.parent) var children: [ChildModel]? init(name: String) { self.name = name } } @Model final class ChildModel { var name: String @Relationship(deleteRule: .nullify) var parent: ParentModel? init(name: String) { self.name = name } } I tried many approaches that didn't help: Fetching all children (via fetch) just to "populate" the context Accessing all children on parent model (via let _ = parentModel.children?.count) Deleting all children reading models from parent: for child in parentModel.children ?? [] { modelContext.delete(child) } Deleting all children like this: let parentPersistentModelID = parentModel.persistentModelID modelContext.delete(model: ChildModel.self, where: #Predicate { $0.parent.persistentModelID == parentPersistentModelID }, includeSubclasses: true) Removing @Relationship(deleteRule: .nullify) from ChildModel relationship definition I found 2 solution for the problem: To manually fetch and delete all children prior to deleting parent: let parentPersistentModelID = parentModel.persistentModelID for child in try modelContext.fetch(FetchDescriptor<ChildModel>(predicate: #Predicate { $0.parent.persistentModelID == parentPersistentModelID })) { modelContext.delete(child) } modelContext.delete(parentModel) Trying to run my code in child context (let childContext = ModelContext(modelContext.container)) All that sounds to me like a problem deep inside Swift Data itself. The first solution I found, fetching potentially hundreds of child models just to delete them in case I might need to rollback changes on some error, sounds like awful waste of resources to me. The second one however seems to work fine has that drawback that I can't fully test my code. Right now I can wrap the context (literally creating class that holds ModelContext and calls its methods) and in tests for throwing methods force them to throw. By creating scratch ModelContext I loose that possibility. What might be the real issue here? Am I missing something?
Replies
2
Boosts
0
Views
113
Activity
1w
SwiftData - Cloudkit stopped syncing
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.
Replies
3
Boosts
1
Views
251
Activity
Sep ’25
CoreData + CloudKit -- Many-to-Many Relationship not Syncing
In an iOS App that uses CKShare I have a many-to-many relationship that does not consistently sync between the share's N participants. The relationship is between Group and Player as group.players and player.groups. As an example, given 3 group each with 4 players (aka 4:4:4), some devices show CoreData (it is NOT a UI issue) with 4:2:3 or 3:4:4. (A deletion of CoreData from a device, forcing a full re-sync from CloudKit, seems to populate the group:player relationships consistently; but obviously that is impractical to resolving the issue). How do I avoid these sync-from-CloudKit inconsistencies? Note: AI agents generally suggest adding a CoreData 'join' entity - such as 'GroupPlayer'. Is that THE fix?
Replies
1
Boosts
0
Views
74
Activity
1w
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
How to diagnose spurious SwiftDataMacros error
I have a Package.swift file that builds and runs from Xcode 15.2 without issue but fails to compile when built from the command line ("swift build"). The swift version is 6.0.3. I'm at wits end trying to diagnose this and would welcome any thoughts. The error in question is error: external macro implementation type 'SwiftDataMacros.PersistentModelMacro' could not be found for macro 'Model()'; plugin for module 'SwiftDataMacros' not found The code associated with the module is very vanilla. import Foundation import SwiftData @Model public final class MyObject { @Attribute(.unique) public var id:Int64 public var vertexID:Int64 public var updatedAt:Date public var codeUSRA:Int32 init(id:Int64, vertexID:Int64, updatedAt:Date, codeUSRA:Int32) { self.id = id self.vertexID = vertexID self.updatedAt = updatedAt self.codeUSRA = codeUSRA } public static func create(id:Int64, vertexID:Int64, updatedAt:Date, codeUSRA:Int32) -> MyObject { MyObject(id: id, vertexID: vertexID, updatedAt: updatedAt, codeUSRA: codeUSRA) } } Thank you.
Replies
1
Boosts
1
Views
350
Activity
Apr ’25