2 Replies
      Latest reply on Sep 9, 2019 4:09 AM by alienspaces
      alienspaces Level 1 Level 1 (10 points)

        I'm experimenting with using Core Data for CloudKit as the main store for my app. It's a brilliant bit of technology that can save you a ton of time. It's great that the background syncing just happens. And that's great today, but I've been thinking about usage scenarios that will only occur in the future, and I have some questions for the Core Data team.

         

        A brief explanation of my apps data model so you understand the issue I'll have. I don't think this issue will be unique to me however, far from it. My app's data model represents something a lot like the file system on macOS. It's a tree structure and at the very root of that tree are system owned directories. Without these directories present, users can't add their own directories and content. So there's this dependency. The reason the system owned directories are stored in Core Data and not hard-coded somewhere is to allow users to move and hide them etc. Plus user content needs to be related to them, and I want to implement CloudKit sharing of them too.

         

        Now let's say I have a user that only owns an iPhone. They download my app and use it for a year, generating 10,000+ managed objects all stored as CKRecords up in the cloud. They then decide to buy an iPad and install my app on it. The CloudKit backed store is loaded on their device and an initial sync occurs. What gets downloaded first during this sync? Can we control what gets downloaded first? Is there some priority we can set? If my system directories aren't downloaded first, I'm very concerned that my users will end up having to wait an extended period of time before they can actually use the app. Even without system directories, if you look at an app like the Apple Notes app, users would expect to see the list of top level folders first. (I'm assuming Notes uses CloudKit API directly.)

         

        Is Core Data for CloudKit a good fit, or can it cater for the above scenario I've described? It doesn't really matter what your data model looks like, I think a lot of develops will come to this same scenario sooner or later. I've wondered whether storing the system folders in CloudKit is a better approach, because I can fetch them on-demand before I even begin a Core Data for CloudKit load/initial sync. But then I'll have to manage the relationships across this bridge manually, and lose some of CD4CKs awesomeness. Even if I do this, my users will still have 10,000s of CKRecords that will need to be synced down to a new install, so what can we expect to happen in this scenario? Will my users discover that their existing content simply appears in the new app like the pieces of a puzzle being filled in randomly?

         

        Some enlightenment would be great. Thanks.

        • Re: CD4CK Syncing after long-term usage concerns
          nocsi Level 1 Level 1 (0 points)

          Sad nobody responded.

           

          What I ended up doing was creating several Core Data configurations:

          * Cache

          * Cloud

          * Local

           

          Cloud of course has the syncing enabled on it. So in your scenario, users can start off on Local and have it sync against the Cloud configuration in the background. Are you actually storing the entire file contents within Core Data? If so, you might want to move to a model of storing just a URI to an iCloud document, after-which a user accessing it can trigger a separate iCloud sync.

           

          I'm also fairly sure I saw documentation that there is a hard restraint on cloudkit record sizes as well.

            • Re: CD4CK Syncing after long-term usage concerns
              alienspaces Level 1 Level 1 (10 points)

              If I'm reading between the lines, after looking at Persistent History Tracking, I think the content will be downloaded in the order it was created. Although the single article, Consuming Relevent Store Changes,  I read in the developer docs assumes some familiarity with the technology, which I have none, it doesn't actually mention iCloud or CloudKit. I still have to watch the WWDC video that introduces Persistent History Tracking, so I'm hoping What's New in Core Data 2017, answers a lot of questions, (although I don't have my hopes up considering it's pre-Core Data for CloudKit), because the Persistent History section in the documentation, is just an API reference with zero actual explanation of the technology.

               

              When I said my data model represents something like the macOS file system, I was implying it was an analogy. My app doesn't really have concrete directories or files. It's the tree structure I was trying to explain.

               

              My situation is slighly more complex than you might imagine, because of the seed data I need to populate the cloud store with. If you want to seed your cloud store with data it's a non-trivial exercise that I go ito some detail with in this post.. NSPersistentCloudKitContainer: How to know initial sync between CloudKit has happened?

               

              Records sizes aren't an issue for me. Good luck!