When using the public database for content hosting or feature flags, you don’t want any random iCloud user to have the rights to publish or edit content on your behalf or to change the feature flags that control your app’s behavior for all of your users, that would be really bad.
That’s where CloudKit’s security roles come in. You can think of them as Unix access control groups for record types. They allow you to restrict the types of operations that users belonging to a given group (security role) can perform on any given record type, and you can then assign security roles to specific users.
[…]
The creator role means “the user who has created this record”. So it’s possible to allow any authenticated user to create a record of a given type in the public database, but not read or write to any record other than the ones that they have created themselves.
[…]
But the most interesting thing about security roles for content hosting and similar applications is that we can define our own security roles and assign them to specific users.
So can we actually use CloudKit’s public database to store user-specific and/or sensitive data without it being widely available? So it’s more like a traditional database an app can build functionality on?
Can anyone confirm this?
If that’s the case, I’ve totally misunderstood the public database for years. I have always considered it suitable only for sample data and other data meant to be broadly accessible without auth.
yep correct! That’s the conclusion I also came to when working more with CloudKit a while ago. You can definitely have data in the public database that’s only readable by the user who created it.
The main distinction for me is, who owns the data
Private db: user owns data, I as developer literally have no way to access it. Also it’s counted towards the user’s iCloud storage quota
Public db: I as developer own the data, and my app has storage quota not tied to any user
CloudKit iCloud iOS iOS 26 Mac macOS Tahoe 26
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。