Since July 25, multiple production users have been unable to load previously saved records from a CloudKit private database. The query uses CKQueryOperation with: Record type: UserAnLi Predicate: category_sub_id == "1401" Sort descriptor: creationDate descending Results limit: 20 The requests consistently fail after approximately 10 seconds with: Error domain: CKErrorDomain Error code: 15 (CKErrorServerRejectedRequest) Underlying error: CKInternalErrorDomain Code=2000 HTTP status: 500 CKErrorRetryAfterKey: absent CKErrorShouldThrottleClient: absent Examples from two different users/devices: iOS 18.3.2 RequestUUID: 67890D6B-8076-4135-9635-7DCCFF38D94F OperationID: A796C6799FA69D66 CloudKit partition: 233 Edge response time: 10024 ms iOS 26.6 RequestUUID: 1249FEAE-9D5A-40CB-9076-DAD2D8396BCF OperationID: CEC87546C31D61E2 CloudKit partition: 227 Edge response time: 10086 ms Users are signed in to iCloud, iCloud Drive is enabled, and general network access works normally. According to TN3162, documented CloudKit throttling normally returns CKErrorServiceUnavailable or CKErrorRequestRateLimited with a retry-after value. These failures instead return CKErrorServerRejectedRequest, HTTP 500, and no retry-after information. The issue has been reported through Feedback Assistant: FB24046201 Could this indicate a production CloudKit query/index problem, a server-side query timeout, or an undocumented/misreported throttle? Is there any client-side mitigation, or does this require investigation by the CloudKit backend team?

I am preparing to save CLLocation data to CloudKit. In the dashboard, when you create a location object, you only can specify lat/long. In the archived CloudKit web services reference, the location dictionary shows more than that is being saved. https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/Types.html#//apple_ref/doc/uid/TP40015240-CH3-SW5 However, this is in the archive. I want to know via documentation if all of the current properties of a CLLocation are saved, and if it is reasonable to assume future fields would be too. The documentation was likely archived BEFORE properties like speedAccuracy, courseAccuracy, source, information floor, and ellipsoidal altitude. FB24049646 - CloudKit: Do all properties of CLLocation get persisted in CloudKit when setting a record value as CLLocation - CKWS archive reference Location Dictionary doesn't show new fields (speed/course accuracy, source info, floor, ellipsoidalAltitude)

Hello, We have a CloudKit-based sharing feature where an app owner shares a single record hierarchy (one CKShare in a dedicated CKRecordZone) with one external recipient. The recipient does not necessarily own an Apple device — they open a link in a browser on a website and authenticate via Sign in with Apple using CloudKit JS, then read and write a small subset of fields. The shared data is sensitive (health-related), so we evaluated CKRecord.encryptedValues for the sensitive fields. Our understanding is that encrypted fields are not accessible through CloudKit JS / CloudKit Web Services — only through the native frameworks or CKTool JS. If that's correct, using encryptedValues would make our web recipient flow impossible. Our questions: Is that understanding still accurate for the current CloudKit JS version, or is there a supported way to read encryptedValues fields from a browser-based CloudKit JS client? If not: for this kind of sensitive-but-web-accessible data, is relying on CloudKit's standard encryption (in transit and at rest) the intended approach, or would you recommend a different architecture — for example encrypting the payload ourselves before writing it and passing the key out-of-band with the share link? Is there any guidance on enforcing a time limit on a CKShare? We currently expire shares client-side, but that only works while the owner's app runs. Is there a server-side mechanism (or a recommended pattern) for shares that should expire automatically? We enforce "only one recipient per link" by setting share.publicPermission = .none client-side as soon as the owner's device observes an accepted participant. We found that if the accepted participant's own access had only ever been granted through publicPermission (not as an explicitly invited participant), revoking publicPermission this way also revoked that same participant's write access (CKError "Zone not found" on their next saveRecords call from CloudKit JS) — until we explicitly set participant.permission = .readWrite on the already-joined CKShare.Participant before nulling publicPermission. Is this expected/documented behavior, or is there a more official API pattern for "convert a public-permission joiner into a permanent named participant, then close the link"? Thank you!

Starting today (approximately) I've been seeing intermittent CloudKit Error Code 15 (CKErrorServerRejectedRequest). Code has not changed. Anyone else getting these errors?

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?

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?

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!