CloudKit is one of the best-kept secrets in the Apple platform stack. For years it has quietly powered sync, storage, and sharing for our apps — for free, with zero servers to run, and with end-to-end encryption we didn’t have to design ourselves. And yet, we’re moving off it.
[…]
When a user’s data won’t sync, we have no view into what happened on Apple’s side. We’ve spent years bolting telemetry onto
NSPersistentCloudKitContainer.eventChangedNotificationjust to find out why a save failed — and even with that, we’re guessing from client-side error codes. There are no server logs we can pull, no admin view into the user’s zone.[…]
CloudKit is supposed to “just work” across Apple platforms. In practice every target has been its own debugging project: macOS only synced on app restart for a while, Apple Watch silently stopped syncing because a user hadn’t accepted a new iCloud ToS — a failure mode we couldn’t even surface to them — and one of our entitlement bugs was reported to us by Apple. AppleTV sync is still flaky in user reports today.
[…]
iCloud signed-out, iCloud full, family-sharing edge cases — CloudKit hands all of this to the client. We’ve built distinct account-state UI for iOS, macOS, watchOS, tvOS, and visionOS, with localizations for each. “Warn the user when their iCloud is full” has been an open ticket of ours since 2025 because we can’t reliably detect it.
Via Fatbobman:
[For] small teams, CloudKit offers an almost unbelievable combination of features[…] But as their product evolved, CloudKit’s limitations became increasingly apparent[…] and most importantly, the inability to truly expand toward the Web and cross-platform ecosystems. Eventually, César’s team migrated to a Supabase/Postgres-based synchronization architecture.
Previously:
Update (2026-06-04): Fatbobman:
Many developers, after integrating CloudKit synchronization with Core Data or SwiftData, encounter a confusing phenomenon: The app synchronizes perfectly across multiple devices, yet when querying
Recordsin the Apple Developer CloudKit Console, it shows “No Records Found” or a completely blank list.[…]
To resolve this, you need to manually add indexes in the CloudKit Dashboard.
Sometimes you will mess up the magic. Perhaps you add a record or field to a Model class then remove it. The Schema may become confused and your app may have errors or crash. You can go into the CloudKit console and reset the environment at any point and the current Production Schema will be copied into the Development environment. If you are seeing odd issues with your app revolving around SwiftData or CloudKit feel free to nuke that environment and start over. The next time you run the app in Xcode/Simulator the Schema will be updated to match your actual code. Tip number one is nuke the Development environment and nuke often. Don’t spend hours trying to figure out some strange CloudKit error only to find out at the end that you got your Schema all mixed up.
[…]
In my case what appears to happen is the migration goes fine, the app launches and works as expected with all my new features and shiny new model updates. Until you fully close the app and relaunch. Then SwiftData acts like it’s never seen this data before and is very offended. Boom. FatalError.
Update (2026-06-11): Greg Pierce:
Drafts sync still has workarounds for issues that probably haven’t been in CloudKit since iOS 8, but I’m scared to rip them out. Those early days were rough.
But, I don’t have servers and user data to worry about, so I don’t complain too much.
CloudKit Core Data iOS iOS 26 Mac macOS Tahoe 26 PostgreSQL Programming SwiftData tvOS tvOS 26 visionOS visionOS 26 watchOS watchOS 26
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。