NSPersistentCloudKitContainer share() never completes in Production — CKShare.url never populates, reproduces on a brand-new container

Container ID: iCloud.com.bluecrestcreative.HouseholdWizard (and a brand-new test container, iCloud.com.bluecrestcreative.HouseholdWizard2 — see below)

Calling persistentContainer.share(_:to:) on an NSPersistentCloudKitContainer never successfully completes against the Production CloudKit environment. The identical code works fine against Development.

What I've ruled out so far, each with a real test:

  • Stale local state — wiped the local Core Data store entirely and retried from empty. Same failure, new share/zone UUID each time.
  • Container-specific corruption — created a brand-new CloudKit container under the same team (never used before, zero history) and pointed the app at it instead. Same failure.
  • Permissions — confirmed full "Edit Production" access in Container Permissions for my account.
  • Entitlements mismatch — verified identical entitlements between a working Development build and the failing Production build (only the environment key differs).
  • Daemon/session staleness — rebooted the Mac, retried. Same failure.
  • CloudKit Dashboard schema — "Deploy Schema Changes to Production" shows zero pending changes even after a successful share in Development, so the cloudkit.share system type doesn't appear to be tracked by the normal schema-deploy mechanism.

The specific error captured from the original container (Xcode 26.6, macOS):

NSCloudKitMirroringDelegate _requestAbortedNotInitialized: Never successfully initialized and cannot execute request due to error: CKError "Partial Failure" (2/1011); "Failed to modify some records"; partial errors: { cloudkit.zoneshare:(com.apple.coredata.cloudkit.share.<ZONE-UUID>:defaultOwner) = CKError "Invalid Arguments" (12/2006); server message = "Cannot create new type cloudkit.share in production schema" }

On the brand-new test container, the failure mode was slightly different (an initial CKError Code=5 / notAuthenticated during user-identity fetch, then CKShare.url simply never populates, indefinitely), but the end result is identical: sharing never actually completes.

Has anyone seen this, or know what's needed to make CKShare record creation work against Production for a container? Already have a DTS incident open (Case-ID 21466535) but wanted to ask here in parallel since code-level questions get routed here anyway.

NSPersistentCloudKitContainer share() never completes in Production — CKShare.url never populates, reproduces on a brand-new container
 
 
Q