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?
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.
