CKQuerySubscription on public database failing with BAD_REQUEST in Production — distinct from iOS 26.4 silent-push regression

I don't have an immediate answer just yet, but would like to check the following:

1. Are you testing with a device that is logged in with an iCloud account? Without a valid iCloud account, your app can't write to the CloudKit database.

2. Do you have any special configuration on the security roles (CloudKit Console > Schema > Security Roles), which prevents the your account to write to the database?

3. For debugging purpose, would you mind to try with visible notifications, as shown in the following code example?

extension CKDatabase {
    public func addQuerySubscription(_ recordType: String, subscriptionID: String, predicate: NSPredicate? = nil,
                                     options: CKQuerySubscription.Options, operationQueue: OperationQueue? = nil,
                                     completionHandler: @escaping (CKSubscription?, Error?) -> Void) {
        let predicate = predicate ?? NSPredicate(value: true)
        let subscription = CKQuerySubscription(recordType: recordType, predicate: predicate,
                                               subscriptionID: subscriptionID, options: options)
        let notificationInfo = CKSubscription.NotificationInfo()
        notificationInfo.shouldBadge = true
        notificationInfo.alertBody = "Changed \(recordType) satisfying \(predicate.predicateFormat)"
        // notificationInfo.shouldSendContentAvailable = false
        
        subscription.notificationInfo = notificationInfo
        
        let operation = CKModifySubscriptionsOperation(subscriptionsToSave: [subscription], subscriptionIDsToDelete: nil)
        operation.modifySubscriptionsCompletionBlock = { savedSubscriptions, _, error in
            completionHandler(savedSubscriptions?.first, error)
        }
        add(operation, to: operationQueue)
    }
}

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

Hi Ziqiao, thank you, both suggestions were worth testing. Unfortunately neither resolves it. Reporting back with results and fresh request IDs you can correlate server-side.

Setup: container iCloud.com.luiz.PandaApp, PUBLIC database. Two CKQuerySubscriptions, options: [.firesOnRecordCreation], simple equality predicates (guardianRecordName == %@, requesterRecordName == %@).

1. Visible NotificationInfo (your point #3). Set alertBody, shouldBadge = true, and category; did not set shouldSendContentAvailable. Subscription save still fails:

CKError code 12; CKInternalErrorDomain 2006 "BadSyntax"; ServerErrorDescription: "attempting to create a subscription in a production container." Server log: RequestUUID 9BD2E50A-60DF-4DDA-86EF-B91E27192F33 (Op 46EA29B4FF3AFC28), SubscriptionCreate / PUBLIC / USER_ERROR / BAD_REQUEST, ~65–82 ms (20 May 2026 ~15:07 UTC). 2) CKModifySubscriptionsOperation instead of CKDatabase.save(_:). Same failure:

Server logs (21 May 2026 ~04:12 UTC): RequestUUID 3276D248-EBCA-4D33-8C47-9E491AD249F3 (Op FCC08756EB6CA504) and RequestUUID 33D892A3-480B-48BE-8935-F7149FB2F622 (Op 92294938173AE34D), both SubscriptionCreate / PUBLIC / USER_ERROR / BAD_REQUEST. (Note: the per-subscription error surfaces via perSubscriptionSaveBlock; the overall modifySubscriptionsResultBlock reported success, so the client looked successful while the server rejected the save.) Additional facts:

An earlier test with NSPredicate(value: true) failed with the identical error — so it isn't the predicate. CKRecord saves to this same PUBLIC database succeed routinely (we create GuardianRequest/GuardianResponse records); only SubscriptionCreate fails — so this isn't iCloud sign-in or record-level write permission. Reproduced on iOS 26.4.x and on a second Apple ID on iOS 18.6.x, so it's distinct from the iOS 26.4 silent-push regression (Thread 820562). Re point #2: I reviewed Schema → Security Roles — [FILL IN what you found]. Predicate, NotificationInfo (silent and visible), and the save API have all been varied with no change; the rejection is identical at the gateway.

Questions: (1) Is this the known CKError 12 / "production container" server-side issue? (2) Is there a server-side remediation or a CloudKit Console action on our side (re-deploy schema, Security Roles change) that would unblock SubscriptionCreate for this container's PUBLIC database? (3) If a server-side fix is required, should I file a TSI/Feedback referencing these RequestUUIDs?

Thank you!

Quick follow-up on point #2 (Security Roles): checked Schema → Security Roles. GuardianRequest and GuardianResponse grant Read via _world, Create via _icloud, Write via _creator — a standard public-DB config. The Read permission query subscriptions need is present, so Security Roles don't appear to be the cause.