Previously working CKQuerySubscription fails to fire CKNotification. Forced reindexing restores expected behavior.

Number:rdar://30483448 Date Originated:2/12/2017
Status:Open Resolved:
Product:iOS + SDK (CloudKit) Product Version:na
Classification:Serious Bug Reproducible:no
This CloudKit app uses CKQuerySubscriptions to be notified of server changes and update the on device data store.

During user testing, the Production database had been firing the expected CKNotifications,  the app received and processed these notifications to fetch changed data.  At some point the notifications were no longer fired.  The app also uses CKFetchNotificationChangesOperation to fetch notifications when the app becomes Active.  The expected CKNotifications were not included in this queue, giving a clue that the Apple Push Service was not at fault.

Using the steps in QA1917 and the 'CloudKit Catalog' sample, I verified the container was working using both the development and production database. (really... why do I NOW have to live with the 'items' model in our database forever!!!)

On intuition, I then removed the field indexes referred to by the CKQuerySubscriptions predicate and deployed this to the Production database. Then added the indexes back to the fields and again deployed.

After this forced re-indexing, the CKNotifications immediately began working as expected.

Troubleshooting - QA1917:

This leaves me with the theory that CloudKit indexing can fail in some way. Since our app architecture relies on CKQuerySubscriptions to keep the device updated of database changes, this is a critical bug with no acceptable (performent) work around.  Future planned features include a social network news feed that includes immediate updating of new posts.  This will not be possible if indexing continues to prevent notifications to fail to fire.

Steps to Reproduce:
Thus far, there are no clues on how to reproduce or how frequently this may occur.

Expected Results:
Proper firing of CKNotifications in response to the modify/update/delete of a model object referred to by a CKSubscription Predicate.

Actual Results: 
CKNotifications are not fired, even when the CKSubscription predicate is reasoned through that it evaluates to true.

iPhone 5s, iPad Pro 12.9, iPhone 7 Plus, iPhone 6+

Version & Build:
iOS 10.2 & iOS 10.2.1

Additional Notes:
App architecture notes:
I am concerned that our unique use of CloudKit may stress the indexing system in a way it fundamentally can not handle.  The following notes are here to illustrate this

- All app data is in the public database
- All models use one or more CKReference fields that point to a Person model.  Each of these CKReference fields are indexed.
- A single user action can cause the creation or update of 14 objects in 3 model types, necessitating the indexes to be updated for 3 fields. As a social app, this needs to scale to millions of users, with thousands of simultaneous user actions.
- In responce to a common user activity, the CKQuerySubscriptions are deleted and new CKQuerySubscriptions with updated predicates are saved to CloudKit.
- The App aims to persist a minimal view of the expansive public model object graph on device.  The CKQuerySubscriptions represent a query to be notified of any modify/update/delete of these locally persisted model objects.


In my case I had to delete the subscription from the Development environment, push that delete to Production, recreate the exact same subscription in Development and push that to production. Then it worked again.

By peterbkramer at March 9, 2019, 11:58 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!