Posting here per DTS guidance (no reduced sample project available). Creating a CKQuerySubscription on the PUBLIC database in the Production environment always fails, on a production-signed TestFlight build. It works in the Development environment; only Production rejects it. Error: CKError 12 (invalidArguments); underlying "BadSyntax" (2006); server message = "attempting to create a subscription in a production container". The subscription: let sub = CKQuerySubscription( recordType: "PublicSolution", predicate: NSPredicate(format: "%K == %@", "challengeAuthorID", myUserRecordName), subscriptionID: "MyChallengeSolved-", options: [.firesOnRecordCreation]) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true sub.notificationInfo = info try await container.publicCloudDatabase.save(sub) Verified (all good): TestFlight build is distribution-signed: aps-environment = production (confirmed with codesign on the archive). APNs registration succeeds on device (valid token). CKContainer.accountStatus = .available; userRecordID resolves. Reads of PublicSolution succeed in Production. challengeAuthorID on PublicSolution is QUERYABLE in the deployed Production schema (verified in CloudKit Console). Dev and Production schemas are identical; deployed to Production multiple times (Console reports "no changes"). Removing notificationInfo.desiredKeys made no difference. Push Notifications capability present; entitlement aps-environment = production. Question: What makes Production reject this public-DB CKQuerySubscription create, and what container-side configuration allows it? Same code succeeds in Development. Container: iCloud.JCM.Contraptor

My scenario I have an app which stores data using SwiftData / CloudKit automatic sync It works as expected on iOS, sync happens even when the app is closed. On Mac, when mac app is closed the data from the CloudKit is not pulled into the DB. It would be nice if the widget on the Mac is updated even when the Mac app is closed. Like from a sync from an iPhone. My problem: I don't do anything for sync other than just initializing the ModelContainer and everything is taken care of. The local store has its own system level tables to maintain the sync states. So I am a bit hesitant to do a separate sync in the background process (LoginItem / LaunchAgent / LaunchDaemon. I need to read a lot on this because I am just beginning to explore this part Questions Is it feasible / advisable to have one instance of the ModelContainer created in the background process and access it in the main app for the Mac? Reason for asking is because ModelContainer is the one that does all the sync magically. Or is this too much of an overhead and users can open the app to keep the widget updated?

Since ~July 10, NSPersistentCloudKitContainer export has failed on every device on my iCloud account; import still works. In CloudKit Console → Logs (Production), the only failing operations are RecordDelete/RecordSave of record type pcs_data (error BAD_REQUEST) in the private com.apple.coredata.cloudkit.zone. No CD* app-record failures; the app schema is fully deployed to Production. Advanced Data Protection is enabled on the account, so PCS keys are managed end-to-end on-device. This looks like a wedged PCS key state rather than an app/schema problem. Tried with no effect: toggling ADP off/on, toggling iCloud Keychain, multiple reboots, app reinstall, extended foreground on Wi-Fi. Still failing after updating from iOS 27 Seed 3 to beta 4. Is there a way to get the account's Protected Cloud Storage key state reset so export can resume? Happy to share the Feedback number and sysdiagnoses privately with an Apple engineer.

Usually, when you call fetchRecordZoneChanges with the previous change token, you get a list of the record ID’s that have been deleted since your last fetch. But if you get a changeTokenExpired error because it‘s been too long since you last fetched, you have to call fetch again without a token. For my specific application, I still need to know, though, if any records have been deleted since my last sync. How can I get that information if I no longer have a valid change token?

A sandboxed Mac app with correct CloudKit entitlements fails to connect to com.apple.cloudd (the CloudKit daemon) when distributed via TestFlight (Mac Team Store Provisioning Profile). The identical binary works correctly when launched from Xcode (Mac Team Provisioning Profile also present). All entitlements are correctly embedded and the App ID is properly configured in Apple Developer Portal. Environment macOS 26.5.1 (25F80) Xcode 26.5 (17F42) SwiftData with NSPersistentCloudKitContainer / ModelConfiguration(cloudKitDatabase: .private(...)) Steps to Reproduce Create a sandboxed Mac app using SwiftData with CloudKit sync Enable iCloud + CloudKit in Signing & Capabilities Archive and distribute to TestFlight (Mac Team Store Provisioning Profile) Install via TestFlight on macOS 26 and launch Check Console for kernel sandbox messages Expected Result CloudKit connects to com.apple.cloudd and syncs data, matching behavior of the iOS version using the same container. Actual Result Console shows repeated kernel sandbox denials followed by CloudKit setup failure: kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.cloudd kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.duetactivityscheduler CheatSheet Mac CoreData+CloudKit: Failed to set up CloudKit integration for store Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon." Key Diagnostic Finding When launched from Xcode, taskgated-helper validates both the Mac Team Store Provisioning Profile AND the Mac Team Provisioning Profile, and CloudKit succeeds: cloudd: TCC approved access for container containerID=iCloud.com.michaelendres.CheatSheet:Production When launched from TestFlight, only the Mac Team Store Provisioning Profile is present, and the sandbox denies com.apple.cloudd despite identical entitlements in the binary: codesign -d --entitlements shows: com.apple.developer.icloud-services: [CloudKit] com.apple.developer.icloud-container-identifiers: [iCloud.com.michaelendres.CheatSheet] com.apple.developer.icloud-container-environment: Production com.apple.security.app-sandbox: true Conclusion The Mac Team Store Provisioning Profile on macOS 26 does not appear to grant the sandbox exception for mach-lookup com.apple.cloudd, while the Mac Team Provisioning Profile (development) does. This prevents any Mac App Store / TestFlight app using CloudKit from syncing on macOS 26.

Hello, my question is exactly the title, is it possible to change capitalization of CloudKit container? I am unable to create a new one since it seems to be case-insensitive and tells me it would be a duplicate but I would like to change the capitalization since that is how the name appears within Settings > iCloud > Manage Storage. Thanks

Bundle ID: com.lavillamergo.Betriebszentrale CloudKit Container: iCloud.com.lavillamergo.Betriebszentrale Environment: Production Stack: SwiftUI + SwiftData with NSPersistentCloudKitContainer (cloudKitDatabase: .automatic) Issue: CloudKit sync (export) fails consistently in the Production environment with CKError.partialFailure (CKErrorDomain error 2). The underlying console log (captured via Console.app on a connected device) reveals: CoreData+CloudKit: -[PFCloudKitExporter exportOperationFinished:withSavedRecords:deletedRecordIDs:operationError:]: Modify records finished: ... Error Domain=CKErrorDomain Code=2 "CKInternalErrorDomain: 1011" ... Never successfully initialized and cannot execute request. Reproducibility: The error occurs on every device that connects to this container in Production, including a brand-new iPhone (iPhone 12, iOS 26.5.2) that had never previously used this app or synced with this iCloud account — ruling out device-local corruption. Already ruled out: iCloud storage quota (6TB plan, 2TB used, ample free space) Stale/duplicate records in the Production zone (queried CD_Verkauf sorted by createdTimestamp ascending via CloudKit Console — no pre-existing records found, all from the current session) Development/Production schema mismatch ("Deploy Schema Changes" dialog shows 0 pending changes across Record Types, Indexes, and Security Roles) Network connectivity (stable fiber WiFi throughout all testing) Recent schema changes made: added missing inverse relationships on several @Relationship properties, changed deleteRule from .cascade to .nullify on three relationships (Verkauf.positionen, LVVerkauf.positionen, Aufgabe.checklistePunkteStorage) — required by CloudKit's relationship constraints. Impact: Cross-device sync via Production CloudKit is effectively non-functional. Local per-device data storage works correctly. Question: What causes "Never successfully initialized" (CKInternalErrorDomain 1011) in this scenario, and how can it be resolved without a full container/environment reset?

Posting this in case others are seeing unexplained high memory usage on Windows with iCloud installed, and to document the diagnosis in case it's useful to Apple engineering. Environment: Windows 11, 32 GB RAM, AMD platform, NVMe SSDs. iCloud for Windows with iCloud Drive, Photos, and Keychain in use. Symptom: Memory usage climbed to ~91% (28+ GB "in use") with no user-mode process accounting for it. Task Manager's process list only summed to a few GB, so the memory was being held somewhere the process view doesn't show. Diagnosis: RAMMap showed nonpaged pool sitting at ~21 GB. That's abnormal — nonpaged pool is normally a few hundred MB. poolmon isolated it to the NTFS "NtFC" (file-context) pool tag: ~51.3 million allocations against only ~12,000 frees, roughly 18.4 GB outstanding. That allocations-far-exceeding-frees pattern is a classic handle/file-context leak. The NtFC tag is owned by ntfs.sys, which means something above the filesystem was opening file references and never releasing them. iCloud was the only cloud client running its full process set (iCloudDrive, iCloudHome, iCloudCKKS, FileCoAuth) alongside the Windows cloud files filter driver. Behavior: By the time I checked, the leaked count was frozen rather than actively climbing, which suggests it accumulates during sync/enumeration activity rather than continuously. Note that leaked nonpaged pool is not reclaimed when you kill the processes — those allocations persist until reboot. Workaround / fix: Uninstalling iCloud for Windows and rebooting cleared the ~18 GB and returned memory to normal. Post-reboot, with OneDrive and WSL still running, usage settled around 32% and stayed stable, which points to iCloud as the source. Has anyone else run into this? Curious whether it correlates with a specific iCloud version, iCloud Photos being enabled, or large-folder sync. Would be good to get this in front of Apple if it's reproducible for others.

Overview Using NotificationCenter's messages NSPersistentCloudKitContainer.EventChangedMessage (AsyncMessage) causes crash When the this project is run on iOS 27 simulator, app crashes Environment macOS: 26.5.1 (25F80) Xcode: Version 27.0 beta (27A5194q) Simulator: iPhone 17 Pro Simulator OS: iOS 27 Code causing the crash: let messages = NotificationCenter.default.messages( of: NSPersistentCloudKitContainer.self, for: .eventChanged ) Looks like the symbol is not even present Feedback: FB23220378 Logs dyld[31078]: Symbol not found: _$sSo29NSPersistentCloudKitContainerC8CoreDataE19EventChangedMessageVSo20NSNotificationCenterC10FoundationE05AsyncI0ACMc Referenced from: <488D9AA6-ED4C-3189-9A08-044D576D498D> /Users/username/Library/Developer/CoreSimulator/Devices/331ADE41-8F3A-4EBE-9E3B-B335B29224D3/data/Containers/Bundle/Application/573DF3FC-E202-4D47-A85F-E5D4D1421EAC/NotificationMessageDemo.app/NotificationMessageDemo.debug.dylib Expected in: <483D9879-24DB-3695-AFE5-B14E2D673F36> /private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreData.framework/CoreData Symbol not found: _$sSo29NSPersistentCloudKitContainerC8CoreDataE19EventChangedMessageVSo20NSNotificationCenterC10FoundationE05AsyncI0ACMc Referenced from: <488D9AA6-ED4C-3189-9A08-044D576D498D> /Users/username/Library/Developer/CoreSimulator/Devices/331ADE41-8F3A-4EBE-9E3B-B335B29224D3/data/Containers/Bundle/Application/573DF3FC-E202-4D47-A85F-E5D4D1421EAC/NotificationMessageDemo.app/NotificationMessageDemo.debug.dylib Expected in: <483D9879-24DB-3695-AFE5-B14E2D673F36> /private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreData.framework/CoreData dyld config: DYLD_SHARED_CACHE_DIR=/Library/Developer/CoreSimulator/Caches/dyld/25F80/com.apple.CoreSimulator.SimRuntime.iOS-27-0.24A5355p/ DYLD_ROOT_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=/Users/username/Library/Developer/Xcode/DerivedData/NotificationMessageDemo-gungjtytarzeijdspglltylscocj/Build/Products/Debug-iphonesimulator DYLD_INSERT_LIBRARIES=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libLogRedirect.dylib:/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=/Users/username/Library/Developer/Xcode/DerivedData/NotificationMessageDemo-gungjtytarzeijdspglltylscocj/Build/Products/Debug-iphonesimulator DYLD_FALLBACK_FRAMEWORK_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/private/var/run/com.apple.security.cryptexd/mnt/com.apple.iPhoneOS.SimulatorRuntime-v24.1.5355.16.mnzElK/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 27.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib Debug session ended with code 9: killed

Hello, everyone, I've started a thread and got a recommendation from DTS Engineer to move the conversation here. The sample code for https://developer.apple.com/documentation/coredata/sharing-core-data-objects-between-icloud-users is with Swift 5. I have a Swift 6 project and I'm running into issue porting the sample code. I've found that NSManagedObjectContext is sendable (https://fatbobman.com/en/posts/sendable-nsmanagedobjectcontext/). From it I can get the persistence controller, and from it I get the stores and this solves the Swift 6 migration path and looks good. i.e. not rely on the private and shared references to the persistence stores, I'll be getting them from the context. I've also notices that once I start to change the PersistenceController from lazy vars for lazy var previewContainer: NSPersistentCloudKitContainer and lazy var persistentContainer: NSPersistentCloudKitContainer to struct PersistenceController { static let shared = PersistenceController() @MainActor static let preview: PersistenceController = { let result = PersistenceController(inMemory: true) which is the default pattern for new CoreData applications (Xcode 26 / Xcode 27) I start getting preview crashes similar to https://developer.apple.com/forums/thread/654126. It turns out this is because of let persistenceController = PersistenceController.shared in the App. Quite unexpected. The persistence controller looks more suitable for actor based on the CloudKit sharing requirements. I saw such question on WWDC 26, however there was not enough time for an answer - is a good pattern to have the PersistenceController as an actor or in another way. Which is that most swiftly way for Swift 6?

I'm adding CloudKit sharing to an app that already uses NSPersistentCloudKitContainer successfully. Private-database sync works flawlessly across my devices. But every attempt to create a share hangs: container.share(_:to:) never returns and never invokes its completion handler. No error is thrown, nothing prints, the operation simply stalls indefinitely. Environment: Xcode 26, iOS 26.5, iPhone 16 Paid Individual developer account Single NSPersistentCloudKitContainer, two stores (private + shared) What works: Private database sync across multiple devices (iPhone + iPad) is reliable eventChangedNotification reports setup/import/export events succeeding continuously CloudKit schema was initialized via initializeCloudKitSchema() and record types appear in the CloudKit Console The problem: Calling share on a root object hangs. I've reproduced the identical hang with all three API variants: async/await: try await container.share([object], to: nil) — never returns Completion handler: container.share([object], to: nil) { ... } — closure never fires UICloudSharingController preparation-closure initializer — the closure never fires, controller presents an empty sheet A log line immediately before the share call prints; a log line inside the completion/closure never does. My two-store setup (per WWDC21 session 10015): swiftlet sharedURL = privateDesc.url! .deletingLastPathComponent() .appendingPathComponent("YerBoat-Shared.sqlite") let sharedDesc = NSPersistentStoreDescription(url: sharedURL) let sharedOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: "iCloud.com.example.app") sharedOptions.databaseScope = .shared sharedDesc.cloudKitContainerOptions = sharedOptions sharedDesc.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) sharedDesc.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) container.persistentStoreDescriptions = [privateDesc, sharedDesc] Possibly relevant: the objects I'm trying to share (and their related records via cascade relationships) were all created before I added the sharing/shared-store code. Could existing records in the default zone fail to migrate into a shareable zone, causing the hang? Questions: What causes share() to hang silently with no error and no completion? Does sharing require records to be created after the shared store exists, or should existing private-database records be shareable? Is there a required step between initializeCloudKitSchema() and the first share() call that I'm missing? I've reviewed WWDC21-10015 and TN3164. Any guidance appreciated.

I could not find iCloud invading capabilities, it Shows nothing found, is there a problem in account or what

I have the following code - you can see where I had to comment out the code on the simulator. Is this expected? The code works perfectly fine on a physical iPad device. Is it documented somewhere that NSFileVersion doesn't work with non-local versions in the simulator? func loadPreviewDirectly( from version: NSFileVersion, completion: @escaping (CIImage?) -> Void ) { let versionURL = version.url let access = versionURL.startAccessingSecurityScopedResource() defer { if access { versionURL.stopAccessingSecurityScopedResource() } } print("Loading version: \(version.persistentIdentifier) | Local: \(version.hasLocalContents)") // 1. SIMULATOR CATCH: If running in simulator and the file is missing, it will never download. #if targetEnvironment(simulator) if !version.hasLocalContents { print("⚠️ iOS Simulator cannot materialize remote NSFileVersions. Fallback triggered.") // You cannot test remote versions here. For testing on the simulator, // test with a version where version.hasLocalContents == true (created locally in this session). DispatchQueue.main.async { completion(nil) } return } #endif let coordinator = NSFileCoordinator() var coordinationError: NSError? // 2. Wrap everything in a sequential reading coordination coordinator.coordinate(readingItemAt: versionURL, options: [], error: &coordinationError) { readURL in let image = CIImage(contentsOf: readURL) DispatchQueue.main.async { completion(image) } } if let error = coordinationError { DispatchQueue.main.async { self.errorMessage = error.localizedDescription completion(nil) } } }

Hey, I'm building an app that uses App Intents to modify data stored in SwiftData and synced through CloudKit. My expectation is that these changes should eventually be reflected in my app's widgets across all of the user's devices (iPhone, iPad, and Mac). However, I'm struggling to find a reliable way to ensure widgets reload when the underlying data changes as a result of a CloudKit sync. Reloading widgets on the device that modifies the data works reliably. The challenge is ensuring widgets reload on other devices after the updated data has been synced through CloudKit. In practice, this doesn't appear to happen reliably. I do not expect the user to manually open the app on those devices. I'm fine with the system launching my app in the background if that's part of the intended solution. Is there a recommended approach for keeping widgets in sync with SwiftData and CloudKit across devices? More specifically: Can WidgetKit be notified when SwiftData receives updates from CloudKit? Is there any supported way to trigger widget reloads on remote devices after a CloudKit sync? If not, what is the recommended architecture for ensuring widgets stay reasonably up to date when synchronized data changes? Things I've considered and/or tried: Calling sendChanges(_:) on CKSyncEngine from my App Intent to push changes immediately. However, this depends on an active Internet connection and doesn't address the case where changes are made offline and synchronized to CloudKit at a later time. Sending push notifications to the user's devices after an App Intent runs and using WidgetPushHandler to reload widgets. However, this requires confidence that the changes have already been uploaded to CloudKit. As far as I can tell, that's difficult or impossible to guarantee in the general case because of the issue described above. Calling fetchChanges(_:) on CKSyncEngine from the widget's timeline provider to ensure the widget has the latest data. However, the widget first needs some indication that new changes are available in CloudKit. Additionally, widget timeline reloads appear to have fairly strict execution time limits, which makes performing CloudKit synchronization work in that context seem less than ideal. My goal is for a Shortcut run on one device to update data and have widgets on all of the user's devices reflect those changes without requiring the user to manually open the app on each device. Am I thinking about this problem correctly, or is there a recommended pattern I'm missing? I'd appreciate any guidance on the intended WidgetKit + SwiftData + CloudKit integration story for this scenario. Thanks!

iCloud KeySyc is a privacy-focused feature that securely syncs a user’s personalized keyboard learning across all Apple devices through iCloud. Today, when users upgrade to a new iPhone or begin using a new iPad or Mac, the keyboard often loses much of the personalization it has developed over time. Users must re-teach autocorrect, rebuild custom vocabulary, and wait for the keyboard to relearn their typing habits. iCloud KeySync would allow users to move seamlessly between devices while keeping the keyboard experience familiar from day one. Problem Statement Apple’s keyboard becomes more useful over time as it learns: Frequently used words and phrases Personal slang and abbreviations Emoji preferences Autocorrect adjustments Writing patterns and typing habits When users switch devices, much of this personalization is lost or takes time to rebuild. This creates friction during device upgrades and reduces the feeling of continuity within the Apple ecosystem. Proposed Solution iCloud KeySync securely synchronizes keyboard personalization data across Apple devices. The feature would: Learn and store personalized keyboard behavior on-device. Encrypt and sync personalization data through iCloud. Restore keyboard preferences automatically when signing into a new device. Keep keyboard learning consistent across iPhone, iPad, and Mac. Key Features Personalized Vocabulary Sync Synchronizes user-added words, nicknames, slang, and frequently used phrases. Emoji Preference Sync Maintains commonly used emoji patterns across devices. Autocorrect Learning Sync Preserves learned corrections and accepted custom spellings. Typing Behavior Continuity Allows devices to share keyboard learning so users receive familiar suggestions regardless of which Apple device they use. User Controls Enable or disable iCloud KeySync. Reset keyboard learning at any time. View privacy information and storage usage. Privacy and Security Privacy should remain the foundation of the feature. All keyboard learning occurs on-device. Personalization data is end-to-end encrypted. Raw message content is never uploaded. Users retain full control over synchronization settings. Security protections match the standards used by iCloud Keychain. User Benefits New devices feel familiar immediately. Less time correcting autocorrect mistakes. Faster onboarding after device upgrades. Consistent typing experience across the Apple ecosystem. Improved customer satisfaction and retention. Example User Scenario A user upgrades from an older iPhone to a new iPhone. After signing into iCloud and restoring their device, the keyboard immediately recognizes their commonly used phrases, preferred emoji, custom words, and learned typing patterns. The new device feels personalized from the first message typed, without requiring weeks of retraining Business Value Improves the upgrade experience. Strengthens ecosystem continuity. Reinforces Apple’s privacy-first approach to AI and machine learning. Creates a subtle but meaningful quality-of-life improvement for millions of users. Switch phones. Keep your vibe.

I have been having this weird issue. Whenever I tap on "Act as iCloud Account" in cloudkit console, my login never works. I have been having this issue for more than 6 months now. ANy one have any insights on this?

I've noticed that new record saves added using add(pendingRecordZoneChanges:) while handling events such as sentRecordZoneChanges or fetchedRecordZoneChanges aren't processed by CKSyncEngine until the app restarts, i.e. the app process has to be terminated and started again for CKSyncEngine to actually attempt to send the pending record saves. This started happening ever since I updated iOS and macOS to 26.5. Is this by design or a bug I should report?

I’m building a macOS app that displays a large grid of image thumbnails similar to Photos. What is the recommended way to determine whether a file is locally available/downloaded without making a blocking call to the filesystem for every thumbnail? Thanks!

I have a CloudKit container that I share across several apps. when I look at the App Privacy Report for these apps, it reflects the app connecting to Google storage APIs. While Apple might host with Google, the perception for users is iCloud and Apple. Can something be done about this? FB16410232 (CloudKit: CloudKit requests contacting google upload servers unexpectedly in app privacy report)

In the past I ran into issues where the CloudKit client SDK was not attributing network usage in MetricKit. Since MetricKit got a major update this year I’d like to make sure usage goes here agains the app. I would expect transfer metrics to also count for CKSyncEngine, or the CloudKit config for core/swift data too. Is this assumption correct? FB12673917 (CloudKit / MetricKit: CloudKit queries are not counting towards network transfer metrics in MetricKit - WWDC23 lab, possible missing URLSession 'attributedBundleIdentifier' not being set)