CoreData+CloudKit w/ Large Public Database

Question

What is the recommended architecture for a CoreData+CloudKit iOS App that has a large public database?

Assume the public database contains 10,000+ Locations from which a User would select a few as favorites. Totally impractical to mirror the locations such that they appear in the App's CoreData having been synced from the .public CloudKit database. Presumably one uses the CloudKit API to query the .public database and display some subset of locations for the User to select? (The selected locations can then be stored in the Users .private (or perhaps .shared) database.)

How does one configure CoreData + CloudKit for this scenario? Is there another approach?

340

Posted by

GoZoner

Reply

Add a Comment

Answer 1

Assume the public database contains 10,000+ Locations from which a User would select a few as favorites

How large are these locations?

For example 10k CLLocation objects is a trivially small dataset for CoreData to manage. It could be downloaded in seconds or minutes and queried extremely efficiently in local storage with indexed fields or via Spotlight. Sending out a CKQueryOperation for each search requires network and unnecessarily drains a customers battery.

NSPersistentCloudKitContainer supports millions of records as long as they fit in local storage.

Another approach is to simply ship the locations with your application in a CoreData store that's part of your application bundle and added as a read-only store to the container.

Posted by

Frameworks Engineer

Saying Location was an example; it is a more complicated data structure, associated with a location. However, truth be told, I've not get a definitive size of the entire database. Another aspect is that locations are meant to be crowd-sourced during use of the app. Sounds like it would work to keep the data in the CloudKit .public database AND simply let it sync fully to CoreData in the App on first startup. And then track changes, which would be minor. Is that a viable approach?

—
GoZoner
Potentially. But the Public database has some limitations around the update frequency and handling of deletes. I would review this WWDC presentation and see if you're amenable to those limitations: https://developer.apple.com/videos/play/wwdc2020/10650/

If not it would be worth a feedback report describing how you would like NSPersistentCloudKitContainer to behave.

—
Frameworks Engineer

Add a Comment

Answer 2

Cloudkit is meant for small snippets of data. With that said, keep the database somewhere in the cloud accessible via a web service or local to the device outside of the cloudkit storage and only sync the small changes that represent UI state, user selection or preference.

Posted by

MobileTen

Add a Comment

Answer 3

Assume the public database contains 10,000+ Locations from which a User would select a few as favorites

How large are these locations?

For example 10k CLLocation objects is a trivially small dataset for CoreData to manage. It could be downloaded in seconds or minutes and queried extremely efficiently in local storage with indexed fields or via Spotlight. Sending out a CKQueryOperation for each search requires network and unnecessarily drains a customers battery.

NSPersistentCloudKitContainer supports millions of records as long as they fit in local storage.

Another approach is to simply ship the locations with your application in a CoreData store that's part of your application bundle and added as a read-only store to the container.

Posted by

Frameworks Engineer

Saying Location was an example; it is a more complicated data structure, associated with a location. However, truth be told, I've not get a definitive size of the entire database. Another aspect is that locations are meant to be crowd-sourced during use of the app. Sounds like it would work to keep the data in the CloudKit .public database AND simply let it sync fully to CoreData in the App on first startup. And then track changes, which would be minor. Is that a viable approach?

—
GoZoner
Potentially. But the Public database has some limitations around the update frequency and handling of deletes. I would review this WWDC presentation and see if you're amenable to those limitations: https://developer.apple.com/videos/play/wwdc2020/10650/

If not it would be worth a feedback report describing how you would like NSPersistentCloudKitContainer to behave.

—
Frameworks Engineer

Add a Comment

CoreData+CloudKit w/ Large Public Database

Accepted Reply

Replies