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

Question

Created 3d

Replies 1

Boosts 0

Participants 2

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.

Answer 1

DTS Engineer OP

Apple

7h

The "Cannot create new type cloudkit.share in production schema" message indicates that the cloudkit.share record type didn't exist in the production environment of your CloudKit container, which could happen if the development environment didn't have record type when you deployed your CloudKit schema.

CloudKit automatically creates cloudkit.share in the development environment when you successfully create a CloudKit share. You can check if the record type exists by loggin in to CloudKit Console, and looking into Container > Development > Record types.

If the record type exists in the development environment but not in the production environment, try clicking Deploy Schema Changes... to deploy the changes. If the Confirm Deployment dialog does not show any change in that situation, try the following:

Click Reset Environments to have CloudKit overwrite the development schema with the production schema. Note that changes in your development schema, if any, will be lost.
Run your app against the development environment and go through the share process to create and accept a share.
Confirm that CloudKit creates the cloudkit.share record type in development environment at Container > Development > Record types.
Try Deploy Schema Changes... again.

If the Confirm Deployment dialog still show no changes, I’d suggest that you file a feedback report with the following info, and share your report ID here:

The CloudKit container ID
The development schema of the container
The production schema of the container
A screen recording that shows Deploy Schema Changes... > Confirm Deployment dialog doesn't detect the change.

I can route your feedback report ID to the CloudKit folks to see if they have any insight on why the difference between the development schema and the production schema is not detected.

Regarding the notAuthenticated error, I am unclear what "user-identity fetch" means here. The CloudKit APIs for fetching user identity were deprecated. If you meant to fetch owner of a share, see the com.apple.developer.icloud-extended-share-access entitlement.

Other than that, the notAuthenticated error is most likely triggered by the wrong configuration of your project, CloudKit container, or device. I'd start with checking Configure iCloud on your devices and Configure CloudKit in your project.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.