Our production container has hit the record type ceiling. Any schema change that adds a new type is rejected with: The request was not allowed: max user record types limit exceeded A schema export taken from production with cktool shows exactly 250 record types: 148 our active schema, CKSyncEngine based 98 CD_* types, auto-generated by NSPersistentCloudKitContainer years ago, before we migrated to CKSyncEngine. The current binary does not use that mirroring path at all (every ModelConfiguration is created with .cloudKitDatabase: .none, and there is not a single CD_ literal in our source). They are never read and never written. 4 system and pre-migration legacy types So 39% of the budget belongs to a framework we no longer use, and because the production schema is append-only we cannot reclaim any of it. Our effective ceiling is 152 types, and we have used 148. The user-visible symptom is CKError 12, "Cannot create new type in production schema". The record is created locally, the client uploads it, the server correctly rejects it, and the data never reaches the user's other Mac or iPad. It fails silently from the user's point of view. Eight shipped features are affected. One of them carries allergen availability, which our restaurant customers print on recipes and communicate to guests, so this is not cosmetic for us. The wall is exactly 250 and it is deterministic: a batch of 13 new types was rejected (245 + 13), and a batch of 5 succeeded, landing the container on 250 precisely. What I have already done: Filed FB24239614 with the full schema export attached. Opened Developer Support case 20000130013570, which came back with general information about what CloudKit is and did not address the quota. Adopted an internal rule that new synchronised data lives as a field or blob on an existing record type wherever the data model allows. Adding fields to existing types works fine and does not consume the budget — that part is not the problem. Some of the eight genuinely need to be their own type. My questions: Is there any supported way to reclaim record type slots left behind by NSPersistentCloudKitContainer after migrating off it? Everything I have found says the production schema is append-only with no exceptions, but these types were generated by the framework rather than authored by us, so I wanted to ask before assuming. If slots cannot be reclaimed, is a per-container record type limit increase something that can be requested through a channel that reaches the CloudKit team? The Developer Support case did not get there. Has anyone migrated a container that uses CKShare-based sharing to a new container? Our model gives each customer a shared zone that their staff accept through a CKShare. My understanding is that shares cannot be migrated, which would force every one of those users to re-accept access. I would like to know if that understanding is correct before treating it as an option. Happy to share the container identifier with an Apple engineer, and the Feedback report has the full export.

Hello, I am investigating a persistent CloudKit Web Services authentication failure that occurs in both Production and Development for the same container. I filed Feedback Assistant report FB24212003 with the full private configuration and timestamps. Configuration The site is served over HTTPS. Its allowed origin and web authentication return URL exactly match the CloudKit Dashboard configuration. The Web Services API token is origin-restricted. No token, Apple Account, container identifier, or user data is included here. Minimal reproduction Configure CloudKit JS with apiTokenAuth for the target environment. Begin CloudKit web authorization and complete Apple Account authorization successfully. The browser returns with a one-time ckWebAuthToken/ckSession callback parameter. On that callback page, make exactly one GET request to /database/1/[container]/[environment]/public/users/current, passing only ckAPIToken and the one-time ckWebAuthToken. The request uses credentials: omit, cache: no-store, and no referrer. Actual result The first request immediately returns HTTP 421 with serverErrorCode AUTHENTICATION_REQUIRED and reason "request needs authorization". Production request UUID: 19e12af3-4cc1-474f-910e-cc98a18a6637 Development request UUID: 2ebabb8d-efba-41c5-8268-69123e056fd6 Controls completed A direct one-time REST probe on the callback page reproduces the failure while bypassing CloudKit JS entirely. CloudKit JS default Cookie store and a custom same-origin authTokenStore both reproduce it. Fresh authorization reproduces in Edge and in an independent Safari profile. Native iOS CloudKit synchronization for this container and Apple Account succeeds, including an explicit web-sync upload. The Production schema is deployed. A previous query-index issue was resolved separately; this failure occurs at users/current before any record read. Questions Could a container-level or team-level CloudKit Web Services authorization/provisioning state cause callback tokens to be rejected by users/current in both environments? Is there a server-side configuration or remediation that should be checked? I can provide the container identifier, exact endpoint timestamps, and additional redacted diagnostics privately through FB24212003. I will not post credentials or user data publicly.

The traditional way to initialize a SwiftData app looks like some variation of the following: @main struct TrainingCornerApp: App { let dbSchema: Schema = ... init() { } var body: some Scene { WindowGroup { MainAppScreen() .modelContainer(modelContainer) } } } private var modelContainer: ModelContainer { let container: ModelContainer let modelConfiguration = ModelConfiguration(schema: dbSchema, isStoredInMemoryOnly: false, cloudKitDatabase: .automatic) do { container = try ModelContainer(for: dbSchema, migrationPlan: MigrationPlan.self, configurations: [modelConfiguration]) } catch { fatalError("Failed to create model container: \(error.localizedDescription)") } return container } } That is, if creating the modelContainer fails, the app aborts with a fatalError. What I want to do is have the application present an alert message for the user before terminating. (Let the user know the app can't run and suggest how to get help -- that sort of thing.) However, I've been having a hard time getting this to work, and it seems that the problems are related to trying to generate the alert at such an early stage in app startup. Does anyone have ideas/suggestions on how I might do this?

I have an Apple app that uses SwiftData and icloud to sync the App's data across users' devices. Everything is working well. However, I am facing the following issue: SwiftData does not support public sharing of the object graph with other users via iCloud. How can I overcome this limitation without stopping using SwiftData? Thanks in advance!

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.

Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments. The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type: { "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" } In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails. Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x What we do (simplified) let zone = CKRecordZone(zoneID: ownerZoneID) _ = try await db.modifyRecordZones(saving: [zone], deleting: []) // succeeds let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID) // plain String / Int64 / Date fields only let share = CKShare(rootRecord: record) share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue share.publicPermission = .none _ = try await db.modifyRecords(saving: [record, share], deleting: [], savePolicy: .allKeys, atomically: true) // FAILS User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted. Already ruled out iCloud sign-in - accountStatus() == .available immediately before the call. iCloud Keychain - enabled on both the iPhone and a Mac on the same account. Advanced Data Protection - OFF. Leftover/broken share - also fails when no record exists yet (brand new). UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save. Schema - the record type and every field we write are deployed to Production. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented. Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25: "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered. "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500. Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout. Questions What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record. Is there an account-level or container-level condition that can block PCS key provisioning? Has anyone else seen CKShare creation (not query) failing in the same period? Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.

Hello, I've been working on this side project to help me understand the uses of Swift and CloudKit. In the middle of this project my "MHLocation" Data Record always keeps facing an internal error and this has been happening on and off for the past 6 months. What can I do to stop this error? I am willing to work with anyone on this. Best, Jordan

I want to prompt users when their iCloud storage quota is full. My test device's iCloud space is full, and when subscribing to the NSPersistentCloudKitContainer-eventChangedNotification event, events exceeding the quota will not be passed to the application at runtime. When I tried to add data to Core data using NSPersistentCloudKitContainer, I got an error: <CKError 0x600000c15890: "Quota Exceeded" (25/2035); server message = "Quota exceeded"; op = 1ECF73B9554DF79F; uuid = 34D12DF0-A307-49EB-AD3A-BB646FF66F54; Retry after 316.0 seconds>}> My iCloud storage space is full, but I am unable to retrieve the 'Quota exceeded' error.I have written a demo, please help me fix the issue. github: CloudKit Sync Demo

Recently, I am experiencing a CKErrorServerRejectedRequest error during my app's iCloud data sync process. I have not modified or migrated the schema recently. To troubleshoot, I logged into the iCloud Dashboard (CloudKit Console) to query the records directly. However, the dashboard also returns a generic "Internal Error" with no additional details whenever I attempt a query. Here is what I have tried so far: Private Database Only: The error only occurs within the Private Database. Querying the Public Database works normally and correctly returns "No records found." Multiple Containers: This issue affects all of my existing containers across both Development and Production environments. New Container Test: I created a brand new container with a new table, verified that the indexes are set to QUERYABLE, and attempted a query. The same "Internal Error" occurs. System Status: I checked the Apple Developer System Status page (https://developer.apple.com/system-status/), and both "CloudKit Console" and "CloudKit Database" are showing green (normal). Is anyone else experiencing this, or is there a known workaround for account-wide dashboard query failures?

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)

您好，想咨询下Configuration ID为32b92585-4221-4b39-a305-c3de951bb53a的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

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?

您好，想咨询下Configuration ID为2641fd1b-8023-4644-b301-1d57785b8f6c的Live Caller ID Request的最新审批状态，目前功能开发已完成缺少OHTTP网关就可以正式投入使用。

Guideline 5.1.3(ii) says apps "may not store personal health information in iCloud." Does this apply to any use of a private, per-user CloudKit database for health-related data, or is it specifically about unencrypted/shared storage, or data sourced from HealthKit? If a health app end-to-end encrypts sensitive fields so that even Apple's infrastructure can't read them, and the data never leaves the individual user's own iCloud account, does that change how 5.1.3(ii) applies — or is the guideline a blanket restriction regardless of encryption? Has anyone gotten reviewer feedback (approval or rejection) that clarifies how this is actually enforced in practice? Thanks in advance!

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.