CKQuerySubscription on public database never triggers APNS push in Production environment

Question

Created 1d

Replies 4

Boosts 0

Participants 3

Hi everyone,

I have a SwiftUI app using CKQuerySubscription on the public database for social notifications (friend requests, recommendations, etc.). Push notifications work perfectly in the Development environment but never fire in Production (TestFlight).

Setup:

iOS 26.4, Xcode 26, Swift 6
Container: public database, CKQuerySubscription with .firesOnRecordCreation
5 subscriptions verified via CKDatabase.allSubscriptions()
registerForRemoteNotifications() called unconditionally on every launch
Valid APNS device token received in didRegisterForRemoteNotificationsWithDeviceToken
Push Notifications + Background Modes (Remote notifications) capabilities enabled

What works:

All 5 subscriptions create successfully in Production
Records are saved and queryable (in-app CloudKit fetches return them immediately)
APNS production push works — tested via Xcode Push Notifications Console with the same device token, notification appeared instantly
Everything works perfectly in the Development environment (subscriptions fire, push arrives)

What doesn't work:

When a record is created that matches a subscription predicate, no APNS push is ever delivered in Production
Tested with records created from the app (device to device) and from CloudKit Dashboard — neither triggers push
Tried: fresh subscription IDs, minimal NotificationInfo (just alertBody), stripped shouldSendContentAvailable, created an APNs key, toggled Push capability in Xcode, re-deployed schema from dev to prod

Additional finding: One of my record types (CompletionNotification) was returning BAD_REQUEST when creating a subscription in Production, despite working in Development. Re-deploying the development schema to production (which reported "no changes") fixed the subscription creation. This suggests the production environment had inconsistent subscription state for that record type, possibly from the type being auto-created by a record save before formal schema deployment.

I suspect a similar issue may be affecting the subscription-to-APNS pipeline for all my record types — the subscriptions exist and predicates match, but the production environment isn't wiring them to APNS delivery.

Subscription creation code (simplified):

let subscription = CKQuerySubscription(
    recordType: "FriendRequest",
    predicate: NSPredicate(format: "receiverID == %@ AND status == %@", userID, "pending"),
    subscriptionID: "fr-sub-v3",
    options: [.firesOnRecordCreation]
)

let info = CKSubscription.NotificationInfo()
info.titleLocalizationKey = "Friend Request"
info.alertLocalizationKey = "FRIEND_REQUEST_BODY"
info.alertLocalizationArgs = ["senderUsername"]
info.soundName = "default"
info.shouldBadge = true
info.desiredKeys = ["senderUsername", "senderID"]
info.category = "FRIEND_REQUEST"

subscription.notificationInfo = info
try await database.save(subscription)

Has anyone encountered this? Is there a way to "reset" the subscription-to-APNS pipeline for a production container?

I'd really appreciate any guidance on how to resolve and get my push notifications back to normal.

Many thanks,

Dimitar - LaterRex

Boost

Answer 1

Tomato OP

1d

a. Try changing CKQuerySubscription options to [.firesOnRecordCreation, .firesOnRecordUpdate]

b. Try setting the shouldSendContentAvailable property of CKSubscription to true.

0

Answer 2

DTS Engineer OP

Apple

22h

For debugging purpose, would you mind to use CKFetchSubscriptionsOperation to fetch all existing subscriptions, and check if the result includes the subscriptions you created? This helps confirm that the current user has the right subscriptions.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 3

LaterRex OP

17h

Hi Ziqiao, thanks for looking into this!

I've verified using CKFetchSubscriptionsOperation.fetchAllSubscriptionsOperation() on both Development and Production (TestFlight) devices. All 5 subscriptions are present and correctly configured in both environments.

The output is identical between both environments. Here are all 5 subscriptions as returned by CKFetchSubscriptionsOperation:

fr-sub-v3 (FriendRequest)

Predicate: receiverID == [userID] AND status == "pending"
badge=true, sound=default, contentAvail=false
locKey=FRIEND_REQUEST_BODY, locArgs=[senderUsername]
category=FRIEND_REQUEST, desiredKeys=[senderID, senderUsername]

rec-sub-v3 (MediaRecommendation)

Predicate: receiverID == [userID] AND status == "pending"
badge=true, sound=default, contentAvail=false
locKey=RECOMMENDATION_BODY, locArgs=[senderUsername, mediaTitle]
category=RECOMMENDATION, desiredKeys=[mediaTitle, mediaType, senderID, senderUsername]

fs-a-sub-v3 (Friendship)

Predicate: userAID == [userID]
badge=true, sound=default, contentAvail=false
locKey=FRIENDSHIP_ACCEPTED_BODY, locArgs=[userBUsername]
category=FRIENDSHIP_ACCEPTED, desiredKeys=[userBID, userBUsername]

fs-b-sub-v3 (Friendship)

Predicate: userBID == [userID]
badge=true, sound=default, contentAvail=false
locKey=FRIENDSHIP_ACCEPTED_BODY, locArgs=[userAUsername]
category=FRIENDSHIP_ACCEPTED, desiredKeys=[userAID, userAUsername]

comp-sub-v3 (CompletionNotification)

Predicate: recommenderUserID == [userID]
badge=true, sound=default, contentAvail=false
locKey=COMPLETION_BODY, locArgs=[completerUsername, mediaTitle]
category=COMPLETION, desiredKeys=[completerUserID, completerUsername, mediaTitle, mediaType]

I've also confirmed via didReceiveRemoteNotification breadcrumb logging that no push is ever received on the TestFlight device (not even silently). APNS delivery itself works (tested via Xcode Push Notifications Console with the same production device token).

A few basics to get out of the way:

I'm testing with two real Apple IDs on two different devices.
Both devices have notifications turned on
I have about 40 testers running a previous build (that did have notifications working) that are saying they don't receive push now

0

Answer 4

DTS Engineer OP

Apple

6h

Thanks for confirming that the subscriptions are there, which helps rule out the technical issue on the app side.

I believe that the issue is a regression in iOS 26.4, and I just replied the other thread here.

Do you have a feedback report yet? If not, would you mind to file one and share your report ID? You don't need to capture a sysdiagnose for your report, but mentioning the user impact in your report will be great. Thanks again.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

1