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 == %@). 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.