CloudKit bugs as of May 2026
This post continues where the previous one left off. We deployed direct silent CloudKit notifications in Tact in late 2024. They proved to be too unreliable to use in a messaging app like Tact: notifications arrived late or not at all. To be fair, this is within the bounds of the Apple SDK contract, which does say that the delivery of silent notifications is on a best-effort basis, and you can expect a lower service level than with visible notifications.
Since Tact is a messaging app where users do expect to be notified of new messages reasonably fast, Tact in May 2026 switched to visible notifications delivered from CloudKit. Those do work reliably and fast, but the user experience is not as fast as it could be. CloudKit has several bugs in this area, and the bugs compound.
So this is simply an inventory of open bugs filed to Apple around the area of CloudKit, notifications, and the related developer experience, as of May 2026.
FB22867206: Notification service entitlement request page not available
Notification Service Entitlements allow iOS Notification Service Extension to suppress displaying a received notification. This would be a handy capability to have in Tact, and let us work around many of the other bugs. As a developer, you cannot do this by default, you have to apply for a special entitlement. The application page appears to be broken or nonexistent.
The page redirects to this link: https://developer.apple.com/contact/request/notification-service
Accessing the link redirects me to sign in with my Apple account. After I sign in, I am redirected to https://developer.apple.com/unauthorized/ that has text “Your account can’t access this page. There may be certain requirements to view this content. If you’re a member of a developer program, make sure your Account Holder has agreed the latest license agreement.” Screenshot of the page attached.
All my Apple Developer accounts are in good standing and have agreed to the latest license agreement.
FB22866852: CloudKit sends duplicate CKDatabaseSubscription notifications for child record changes
I am seeing duplicate CloudKit database subscription push notifications for a single logical record creation. This happens in both private and shared databases.
Tact’s CloudKit record structure is that the root CloudKit record (possibly shared with other users) is Chat, which can contain Message children, and each Message child can further contain a number of Reaction. Now, when you add a Reaction to a Message with user A, then user B sometimes receives this sequence of events:
Received remote notification
Push #2 CloudKit notification type: 4, subscription: private-database-visible-subscription
Database notification scope: private
Change fetch #3 scheduled because: push #2; scopes: private
Change fetch #3 starting
Loaded database token for private, has token: true
Stored database token for private, has token: true
Database changes for private: changed 1, deleted 0, purged 0
Fetching zone changes for 1 private zones
Loaded zone token for Chats/__defaultOwner__, has token: true
Stored zone token for Chats/__defaultOwner__, has token: true
Zone changes for private: changed 2, deleted 0
Changed records for private by type: Message: 1, Reaction: 1
Changed record IDs for private: Reaction:41AE3D75-CECF-4DE3-8623-BE0AED17A1F7, Message:4F4E8BE7-3247-4721-B673-619D8930D9E3
Upserted reaction 41AE3D75-CECF-4DE3-8623-BE0AED17A1F7
Upserted message 4F4E8BE7-3247-4721-B673-619D8930D9E3
Change fetch #3 finished
Received remote notification
Push #3 CloudKit notification type: 4, subscription: private-database-visible-subscription
Database notification scope: private
Change fetch #4 scheduled because: push #3; scopes: private
Change fetch #4 starting
Loaded database token for private, has token: true
Stored database token for private, has token: true
Database changes for private: changed 1, deleted 0, purged 0
Fetching zone changes for 1 private zones
Loaded zone token for Chats/__defaultOwner__, has token: true
Stored zone token for Chats/__defaultOwner__, has token: true
Zone changes for private: changed 0, deleted 0
Changed records for private: none
Change fetch #4 finished
When I add a reaction, I expect to receive only database change notification. Even if several records are modified because of this, they could be coalesced, with only a single database notification sent. Instead, you receive two database notifications, and must somehow deal with that.
These log lines come from the example app that I created to confirm this bug. The bug cleanly reproduces for me as of May 2026 with platform (OS and tools) version 26.5.
FB22867218: Unable to create CKQuerySubscription in shared CloudKit database
Observed: I cannot create CKQuerySubscription in shared CloudKit database. In my app, I work with record structures that can either be owned by myself, living in private CloudKit database, or shared to me by others, living in shared CloudKit database. In my app, these records should behave mostly the same, and I would like to receive similar notifications about them.
Expected: I should be able to create CKQuerySubscription in shared database exactly as I do in private database.
Not having CKQuerySubscription available in shared database means I must rely on database change notifications in shared database to generate notifications, which are less accurate and sometimes generate me redundant notifications (FB22866852). I also cannot suppress the redundant notifications on the UI side (FB22867206).
Being able to create CKQuerySubscriptions in shared CKDatabase would alleviate some of the other bugs. I doubt this will ever happen, because CloudKit seems to be architected in a way where this is technically difficult. So I should be able to work around this, but the other bugs show why this also is problematic today.
FB22867222: Cannot manage subscriptions or do anything else in private CloudKit database in CloudKit console when developer account has Advanced Data Protection enabled
How to reproduce:
- Enable Advanced Data Protection on the Apple account that you use for Apple development.
- Go to CloudKit Console
- Try to access records in a private or shared database.
Expected: you can access records.
Observed: private and shared database display an error, “Failed to access iCloud data. Please sign in again.” (screenshot attached)
Signing in again has no effect and I end up in the same state.
I have icloud.com access enabled on my iCloud account.
FB22867235: Creating a production CloudKit subscription requires deploying schema changes with no visible indication to developer
How to reproduce:
- Create a new subscription in debug version of your CloudKit app against development environment.
- Try to work with the subscription in development CloudKit environment. This works as expected.
- Deploy your app into a production environment (e.g TestFlight) and run the same code there.
Expected: subscription should work the same way as it did in deveopment environment.
Observed: you get this error:
error=CKSubscriptionError(code: 12, localizedDescription: "Error saving record subscription with id PrivateReactions-v1 to server: attempting to create a subscription in a production container", retryAfterSeconds: 0.0, errorDump: "<CKError 0xad4844390: \134"Invalid Arguments\134" (12/2006); server message = \134"attempting to create a subscription in a production container\134"; op = 81412ECB4A4DD294; uuid = DA9E1B02-ADA6-4E9D-A5EA-50162F1311EF; container ID = \134"iCloud.com.justtact.Tact\134">")
Known workaround: deploy CloudKit schema from development to production. The schema UI in CloudKit Console does not indicate that there are subscription changes or any other changes to the schema, but it seems that deployment is actually needed to remove this error in production environment. After I deploy schema changes and wait for a little while, the error disappears in production CloudKit environment.