CloudKit Private Database requests fail with CKError 15 / HTTP 500, while Console works

Question

Created 2w

Replies 1

Boosts 0

Participants 2

Hi,

I’m running into a strange CloudKit issue and I’m trying to figure out whether this could be related to the China mainland iCloud environment, or whether I’m missing something on the client side.

I’m testing on macOS with Xcode 26.6, using the CloudKit Development environment and the Private Database. The Apple Account signed in on the Mac is a China mainland account, and CKAccountStatus reports available.

The original container is:

iCloud.com.hu.sujian

With that container:

I can create a custom zone in CloudKit Console.
The app can save a normal CKRecord to the Private Database default zone.
But the app consistently fails when creating a custom CKRecordZone.

The error is:

CKErrorDomain Code=15 (serverRejectedRequest) Underlying CKInternalErrorDomain Code=2000

I also opened DTS case 21678909 and filed FB24394907.

As part of the DTS investigation, I created a completely new CloudKit container:

iCloud.com.hu.sujian.dtstest21678909

I then repeated the same tests using the same Apple Account and the same minimal test app.

On the new container, both of these app-side operations fail:

Saving a CKRecord to the Private Database default zone

CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500

Request UUID: D4B4DC7A-4167-4987-8BB1-4C61E658EDB6

Creating a custom CKRecordZone named SujianLibrary

CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500

Request UUID: 00B4A294-9C63-4DBC-9133-03D969536B73

However, if I open CloudKit Console for that same new container, I can create a custom Private Database zone successfully.

I created:

DTSConsoleTest21678909

and it shows up normally as:

REGULAR_CUSTOM_ZONE

The code is very small. The relevant paths are essentially:

let container = CKContainer(identifier: containerIdentifier) let database = container.privateCloudDatabase

let record = CKRecord(recordType: "DTSWriteTest") record["message"] = "test" as CKRecordValue try await database.save(record)

and:

let zone = CKRecordZone(zoneName: "SujianLibrary") try await database.save(zone)

What confuses me is that CloudKit Console works, while the app receives an HTTP 500 from the CloudKit service.

The behavior also changed slightly between the two containers:

Original container:

default-zone record write from app: works
custom-zone creation from app: fails
custom-zone creation in Console: works

New container:

default-zone record write from app: fails
custom-zone creation from app: fails
custom-zone creation in Console: works

FB24394907 contains the full reproduction details and logs.

Has anyone seen something similar, especially with a China mainland iCloud account?

I also have a small standalone reproduction project if that would be useful.

Thanks.

Answer 1

BROEKNLABS OP

2w

I'm seeing what looks like the same fault, started abruptly at ~03:11 UTC on 2026-08-28 after weeks of working normally.

Symptoms, matching yours almost exactly:

Every private-database WRITE returns HTTP 500 with an empty response body. The client surfaces CKErrorDomain 15 (Server Rejected Request) with underlying CKInternalErrorDomain: 2001. Server header AppleHttpServer, via icloud-xrail. READS work. accountStatus reports available. Sign-in is fine. Reproduces identically through NSPersistentCloudKitContainer mirroring AND a raw CKModifyRecordsOperation probe, on device (iOS 17.2.1). Crucially, like you: I created a brand-new, fresh container and pointed the app at it — writes fail there too with the same 500/2001, so it's not container state. This appears to be account-scoped. Entitlements, provisioning profile, and App ID iCloud capability all verified correct (codesign inspection + ASC API). Development environment.

One possibly relevant correlating event on my side: the legal name on my Apple Account was changed the same morning the failures began. I can't prove causation, but the timing is exact, and the failure being account-scoped (two containers, same signature) fits an account-state wedge in the write path — possibly the PCS/user-record layer, which would explain writes failing while reads keep working.

Sample failing request UUIDs, if it helps anyone at Apple find these in server logs:

244DA811-E4AA-4771-88F0-7C092EFD8DEF (2026-08-28 ~09:57 UTC) 1FD544D6-6ED2-4181-8976-B4F4C35830D9 E55EFF8F-FC32-48BD-9165-F4EA263F130A

I'm filing a Feedback and a support case referencing this thread so the reports get correlated rather than triaged separately. @OP — did case 21678909 / FB24394907 produce any movement? Happy to supply more request UUIDs or a CloudKit sysdiagnose (TN3163) if an Apple engineer picks this up.