In-app storage/sync strategy for shared objects

Question

rogersmj OP

Created Jan ’23

Replies 3

Boosts 0

Participants 3

I'm new to iOS development and am trying to formulate a strategy/design for the data layer of my application.

I have objects (basically lists, so they're objects that contain N sub-objects) that can be shared among users. The users need to be able to make changes to these lists and the changes should be synced to a cloud data store. They will be stored/represented as JSON documents (think MongoDB). One list may have at most a hundred-ish items on it, but will more often have on the order of a few tens of items.

The app needs to work offline, and when a connection is restored, sync the changes that have accumulated since the connection was interrupted.

For my backend, I desire to use something like FireBase or AppWrite to enable easy future cross-platform compatibility (in other words, I don't want to use CloudKit because I think it will not be as straightforward to leverage on other platforms), and to give me a base for user registration/account management among other things. One user may at most have a handful (less than a dozen) lists, most of the time.

So, all that said...I'm trying to figure out the right "local" storage strategy for these objects in iOS/Swift.

It's unlikely that the total data would ever amount to more than a few hundred KB, so maybe files (one JSON file per list)? In addition to the structured data, there will be metadata/ancillary data that needs to be cached/stored with the lists (like images pulled from the web based on a URL on a list item).

Core Data? I'm not going to be dealing with huge datasets, nor is there any relationship between the lists -- just between the lists and users, and of course the items in a list. So I'm not sure if Core Data is worth it.

I'm just completely new to iOS development and am struggling to determine the right approach here, so any advice would be appreciated.

Boost

Answer 1

Claude31 OP

Jan ’23

It's unlikely that the total data would ever amount to more than a few hundred KB, so maybe files (one JSON file per list)

So each file (a List) will be a few to a few tens kB ? That's not an issue. When you save a photo, it is much larger file.

So saving lists as JSON files and saving the files URs in UserDefaults should be appropriate.

0

Answer 2

deeje OP

Jan ’23

How important is user privacy? How important is security? How are you planning to pay for cloud services like FireBase or AppWrite?

I choose CloudKit (and CoreData), time and again, because, user data is private and secure by default, the capability to share between users is built in on top of that privacy and security, and users pay for their own cloud storage, not me.

In 2019, Apple introduced a sync system between the CloudKit and CoreData, called NSPersistentCloudKitContainer, which might server you well.

If you want more control, check out CloudCore. And for Android, check out cloudkit_flutter.

fwiw

0

Answer 3

rogersmj OP

Jan ’23

Thanks for the replies. Security is not too much of a concern -- there is zero PII or sensitive information in these list objects. The photos would not need to be synced -- the data in the list is enough to fetch/generate a photo on each device, it can just be stored locally after being retrieved/created once using the list data.

The fact that CloudKit means users are paying for their own cloud storage is a good point though. But that's not going to translate across platforms -- if I launch a web and Android app, unless those users are iCloud subscribers, I'm still going to have to come up with a cloud storage backend, and then I've got to integrate and maintain two storage systems, right? And if I do that, how would a user of the Android app who does not have an iCloud account share one of these lists with an iCloud/iOS user? If you're planning to go cross-platform and not requiring an iCloud account, it would seem this approach is just going to add a lot of complexity.

0