CloudKit - Public and Private database - messaging platform

3
votes

I'm trying to Google this for last 2 hours and found practically nothing useful. Let's say I want to create a messaging application with contacts on CloudKit platform.

You use a public database for Users. Let's say you can search people on the platform via e-mail address. So the e-mail is a public information stored in Users record type. However this user also has secret information that only accepted contacts can see. You invite him to be your contact which saves into Public database and sends a notification of some sort.

What now? How do you share a secret information about User, such as phone number, or, let's say, all of his contacts. CKShare doesn't seem to solve this kind of problem. Also, if I message the other person privately, where does this record get saved? Into a public database? Eh.

Sure I can save it all in a public database but how is that secure? Can't somebody then get the data if the app can? I read about encrypting the data but that sounds to me like a lot of work and confusion and don't even know how could you share the keys on demand.

2
iosicloudcloudkit
The public database is exactly that; a database that is accessible to everyone. The private database is actually a file in the users's own iCloud store (it isn't visible in their iCloud Drive, however). CKShare allows a user to make a specific record in their private database visible to another user. It may well be that CloudKit is not the datatstore you are looking for - Paulw11

2 Answers

7
votes

In my view, Apple really goofed up by calling it a "Public" database because it's not actually public.

Your CloudKit data in the Public database can only be accessed in a few ways:

  • Authorized Users: App Store Connect users can be granted access to make calls to your container via Apple's CloudKit APIs. Usually this is only your Apple ID and maybe that of a colleague.
  • Web Servers: you can make calls to the Public DB if you have a server-to-server key installed.
  • Web Pages: JavaScript code can make calls to the DB from certain domains specified by you in the CloudKit Dashboard.

So don't think of it as making it available to anyone anywhere. That would be a ridiculous architecture for Apple to implement as the default. Apple's Public database just means it can be accessed through authorized channels to any user that installs your app.

With that out of the way, you can store all that information you describe in your Public database. For a messaging app, people are going to need to look up other people and potentially communicate with anyone in the system. So all the data has to be in the same place.

CKShare wasn't really designed to support shared data like this. It's more for sharing a specific document with a set of people. Records shared via CKShare should be viewed as shared temporarily. If a user deletes your app or removes the share, all the participants immediately lose access. If you want data to live on (like in a chat room) then you need to make it user-independent by storing it in the Public database and granting users access to it.

I recommend creating your own User recordType since Apple's default Users recordType can't be queried (except by ID/recordName). So if you added an email field on to the Users recordType, you wouldn't be able to look up users by email. Instead, create your own User type and you'll be able to search by email all you want.

I hope that helps. I'd move forward with your Public database implementation. You will have to manage sharing and subscribing to records manually, but it's the same amount of work as using CKShare (but a lot more flexible). Good luck!

1
votes

Your right you store the public information in the public database.

And your secret private information in your private database. When you make a contact that you want to share more data with you can use a CKShare linked to an individual to share your secret private information.

It is a little confusing cause your imagining your contact list and secret information is held in a database on your device, only it isn't. It is all held remotely as permissions to see secret private data held in other people's private databases.

In the meantime you need to save the links to the shared private information your friends have agreed to share with you in your private database. Late last year I build an app that uses this sort of scheme. Within it you can take a photo, it is stored in your private database, you send a link to the ckshare of said photo to a list of users, who are then able to access it. The photo in case is the secret private information.