CKQuerySubscription save fails in Production with CKError 12 “attempting to create a subscription in a production container” (works in Development)

Saving any CKQuerySubscription to the private database fails in the Production environment with CKError 12 (badRequest): “attempting to create a subscription in a production container”. The same subscriptions save fine in Development. The schema, including the needed QUERYABLE index, has been deployed to Production. This looks like the same issue as FB22867235 and Developer Forums thread 826814.

Container: iCloud.com.darkstardev.chorecalendar
Environment: Production (TestFlight build 0.2 (5))
Device / OS: iPhone18,2, iOS 27.0.1
App: Core Data with NSPersistentCloudKitContainer (private and shared stores), sharing a zone with CKShare
Database: privateCloudDatabase of the share owner’s account
Zone: the Core Data share zone, com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376
Subscription:
CKQuerySubscription on recordType CD_Mark
predicate CD_status == "waiting"
options .firesOnRecordCreation and .firesOnRecordUpdate
zoneID set to the share zone
Schema: CD_Mark has a QUERYABLE index on CD_status in Production, which I verified in the CloudKit Console.

All three notificationInfo variants fail the same way in Production. All three succeed in Development:

An alert with titleLocalizationKey, alertLocalizationKey and alertLocalizationArgs ["CD_kidName", "CD_choreName"]
A plain alert with titleLocalizationKey and alertLocalizationKey, without args
A silent subscription with shouldSendContentAvailable = true and desiredKeys

Because even the silent subscription is refused, the cause isn’t the alert configuration. Production refuses CKQuerySubscription creation for this container.

Steps to reproduce:

Install the TestFlight build, signed in as the share owner.
Create and share a family record through NSPersistentCloudKitContainer.
Turn on the in-app setting that saves the subscription.

Expected: the subscription is saved, and a push arrives when a participant creates or updates a waiting CD_Mark record.

Actual: all three saves fail. Error text: “Error saving record subscription with id check-ins-com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 to server: attempting to create a subscription in a production container” (CKError 12).

Already tried:

Deploying the schema from Development to Production.
Turning the setting off and on again a day later.

Answered by DTS Engineer in 912196022

Thanks for providing the report, which does help.

CloudKit folks suggest that a query subscription (CKQuerySubscription) needs to be created in Development environment first and then promoted to Production with the rest of the container schema.

Did you try that yet? Concretely:

  1. Run your app against the Development environment and create every CKQuerySubscription your app uses.
  2. In CloudKit Console, confirm the subscription types appear in your Development schema.
  3. Deploy the schema to Production.
  4. Retry in Production.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

FB22867235 is still under investigation... Do you have a feedback report yet? If not, would you mind to file one with all the details, which hopefully helps the investigation, and share your report ID here? Thanks.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Hi Ziqao, I do have a feedback report, ID - FB25318850

Accepted Answer

Thanks for providing the report, which does help.

CloudKit folks suggest that a query subscription (CKQuerySubscription) needs to be created in Development environment first and then promoted to Production with the rest of the container schema.

Did you try that yet? Concretely:

  1. Run your app against the Development environment and create every CKQuerySubscription your app uses.
  2. In CloudKit Console, confirm the subscription types appear in your Development schema.
  3. Deploy the schema to Production.
  4. Retry in Production.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Thanks again Ziqiao, that fixed it. After creating the query subscriptions in the Development environment and deploying the schema (the Console showed no changes, but the deploy still carried them), Production accepted the subscription. Suggestion: the Console could show subscriptions as part of the schema deploy, and the error message could mention that the subscription needs to exist in Development first.