Recommended way for testing CloudKit with two separate Apple Developer accounts?

Use the public database.

The private database is restricted to users with the specific AppleID. That applies to an app accessing CloudKit and a device looking at the CloudKit dashboard.

My app will only use the private database in production. I want my testing environment to be as close to production as possible, so that's not really what I want.

I ended up adding my Apple ID to my development team. In the Cloudkit dashboard I was able to login using the other developer id. It kept showing errors though in the dashboard UI. "can not access container" with some generic error.

I stepped away for a couple hours. Now it looks like I'm able to access the containers when I click on them in the sidebar. I'll have to do more thorough testing tomorrow though. Too late to get started on this now.

How is this working for you?

I added a user as an admin to my team but I can not get them to show up in CloudKit Dashboard's permissions. Did it just take a minute for you? Apparently viewing Sandbox data used to be a possibility in the CloudKit dashboard but it doesn't look like it anymore and the publicDB solution is not a solution IMO as it offers way too much variation from building, to testing, to production.

I've nuked my private data so many times at this point and I'd really like to not do that since I actually do enjoy using my app 🙂

---

Looks like since I have an individual account, I can't add to my team. So, I can not find any other way to access two private user databases, which makes testing and building quite the most horrible process, especially when it comes to sharing. Sounds about right.

>the publicDB solution is not a solution IMO as it offers way too much variation from building, to testing, to production.

Not sure what you are referring to here. The public database is rock solid. You deploy from the development environment to the production environment for both public and private.

Well, for example, custom zones aren't supported in the public database (afaik), so that means I can't test and develop sharing between users properly (well, I did through extreme hurdles but I can't test it properly or confidently). I'd also have to change my code pretty dramatically between development and production. Different errors can be thrown from accessing the different databases and there's always human error to account for when handling things manually like that (I'm not sure if you're suggesting I just switch all of my privateDB operations to the publicDB, but that's not really feasible). That's the variability and I just don't think that using the public database is a great solution here because of that

i understand not giving developers access to another users private database, but a sandbox user is what this scenario is meant for and was a part of CloudKit dashboard at one point so I don't think it's out of the realm of possibility.

Yea, adding the Apple id to my dev team works. You have to login to the CloudKit dashboard using this account though. If you login using your normal admin account and think you can switch between users, you can't.

> Well, for example, custom zones aren't supported in the public database (afaik), so that means I can't test and develop sharing between users

I make my own sharing in the public database quite simply (aside - I couldn't get over early bugs in CKShare so I abandoned that effort). Each user is a member of one of many accounts. All members of an account share their records. They query with the predicate:

        predicate =[NSPredicate predicateWithFormat:@"modificationDate>%@ &&  AccountName == %@"
                           ,timeStamp,accountRecordName];

> I'd also have to change my code pretty dramatically between development and production.... I'm not sure if you're suggesting I just switch all of my privateDB operations to the publicDB, but that's not really feasible

I am suggesting exactly that for all things that involve more than one user. And if you do that then I see no need to change any code between development and production. I have found it very feasible to use only the public database for almost everything. There is a privacy issue in that, as developer, I can see things that I would not be able to see if the user was using their Private database. You would need to disclose that you have that access.

> i understand not giving developers access to another users private database, but a sandbox user is what this scenario is meant for and was a part of CloudKit dashboard at one point so I don't think it's out of the realm of possibility.

You are correct, the sandbox is not well designed to test CKSharing. I believe that CKShare was created after CloudKit and the sandbox were designed. And CKShare was shoehorned into the sandbox. bugs and all.

Whoa - technically anyone can query the public database for any of those records, right? Is that not a security issue when the public database in that way? I most certainly can not place user data in an open area like that, no matter how insensitive I may deem it or what I ask them to agree to. I applaud your ability to work around the constraints though!

Man, is that what it has come to to get a properly tested and robust syncing system? Unfortunately just sounds like I hafta sacrifice my account and spend way more time than I should to get things to a place where I'm confident. 😟 Its just frustrating because attempting to do it how Apple intends is rough given the lack of tools.

On a side note, CKShare and the shared system as a whole works really great for me, I'd highly recommend dipping into it again if it's been awhile. I haven't really encountered any bugs (knock on wood) it's just building the robust system that handles CloudKit errors, feedback that's the struggle for me now. Having only a single account and one tied to my personal data blows. All I want is a nice solid syncing system!

>anyone can query the public database for any of those records, right?

You need a security token to access CloudKit. Without that token you can only get access through an app. An app is limited to fetch only what it's code tells it to fetch. There is no way that the code in the app of a person who is not a member of a particular account can query the database and fetch information that is in that particular account. The protection here will not be that the database will refuse entry to a record it will be that the code of the app will not ask for it.

One bug reported in CKShare was that you could not have more than 500 people in a share. I found that to be totally unacceptable - a bug that occurs only when the app become widely used.

Aw man, I think we'll have to agree to disagree here.

Both an app and the OS can be explioted in ways that I don't think you can use a query's request as the trust to selectively access private records from a public pool of others private data. The code shouldn't be guarding the database as there's no way you can confirm that code or the query hasn't been manipulated, and you've got to just trust every device with access to the public database.. which is every device with your app downloaded since you don't even need an iCloud account to access it.

And even turning a blind eye to OS and app level expliots, there's the possibility of simple mistakes like mixed up variables or mixed up queries made by a developer that can expose someone elses records; the former examples granting the possibility of of accessing anyones or all records while the latter makes code fragile (and I don't trust myself quite that much, I'm only human). Of course, this is just my opinion; I don't think we've ever seen a CK public database abused in this way by a bad actor, but I doubt there's widespread usage of storing private data like this either. But long story short and in my opinion it's the database's responsiblity to keep records walled off from those who don't have access.

(Also just searched that CKShare bug, seems like 5000 limit on records connected to a single share which is totally fine for my usage; how annoying though.)

I guess it also comes down to how 'private' the information is. In my case it's not that private. Keep in mind that the public database admits only authorized users - it is not available through web access except through a developer-generated token or from code in the app.

I suspect you will find many databases do not add the level of security that Apple has added with their private/public split.

I'm glad to hear that many of the early bugs in CKShare are gone. Perhaps I will revisit. But a 5000 limit would be an issue for me. And it really bothers me that they don't (or at least didn't) reveal this issue publicly.

To be completely fair, I'm also being paranoid - like I said, I don't think we've seen a bad actor in this fashion ever and like you said, you need to be using a point from within the ecosystem to take advantahe.

I hear ya on that last bit, too! 😐 While I know Apple has been able to scale CK in a multitude of ways, it just puts a doubt in the back of my mind about potentially running into a different stopgap like that.