CKShare save fails with BAD_REQUEST on _pcs_data in Production private database

Question

Created 1w

Replies 1

Boosts 0

Participants 1

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.

Answer 1

masonChai OP

1w

Resolved. Two separate causes, neither visible from the client-side CKError.

The Production schema was missing the system record type cloudkit.share.

Enabling verbose error output in our own build surfaced the real server text:

CKError 12 - Cannot create new type cloudkit.share in production schema

CloudKit Console confirmed neither Development nor Production had cloudkit.share (only our own MedStatus and Users). This type cannot be created by hand in the console. It is auto-created the first time a share is actually saved in the DEVELOPMENT environment, and then must be pushed with Deploy Schema Changes.

Our app had only ever run against Production (TestFlight / App Store builds), so that type was never created. The BAD_REQUEST on _pcs_data was the downstream symptom, not the cause.

Fix: install a Debug build on a device (Development environment), perform one share, confirm cloudkit.share appears under Record Types, then Deploy Schema Changes to Production.

Note for testing Production on-device: a Release configuration is not enough. If the build is signed with a development certificate it still targets Development unless the entitlement com.apple.developer.icloud-container-environment is explicitly set to Production.

Acceptance was never delivered to the app (SwiftUI / scene-based apps).

After sharing worked, tapping the invitation link opened the app but nothing happened. SwiftUI apps get a UIApplicationSceneManifest generated automatically, so they are scene-based, and iOS delivers the accepted share to

UIWindowSceneDelegate.windowScene(_:userDidAcceptCloudKitShareWith:)

not to UIApplicationDelegate.application(_:userDidAcceptCloudKitShareWith:). With CKSharingSupported = YES the link still launches the app, so the failure looks like "the app opens and silently does nothing".

Fix: return a UISceneConfiguration with a delegateClass from application(:configurationForConnecting:options:), implement the scene method, and also handle connectionOptions.cloudKitShareMetadata in scene(:willConnectTo:options:) for the cold-launch path.

Both are now confirmed working on a real device.