How do CloudKit containers handle app transfers?

I’m slightly confused about how are CloudKit containers supposed to handle app transfers. I’m seeing some strange too-permissive security behavior, and I am not sure whether this is a feature or a bug 🙂


Here’s the setup:


I had an app with bundleID com.example.something, talking to a CloudKit container also called com.example.something, all under the same developer account A. All was well.


I then transferred the app from developer account A to developer account B. The bundle ID or anything else about the app did not change, just the ownership. Must now also sign new builds of the app with credentials for account B, as expected. HOWEVER: the CK container also did not change at all, and remained under development account A.


What I am seeing now: the app signed by developer account B can still access the CK container under developer account A. No bundle IDs or CK ID-s changed, so I can sort of understand this, but at the same time, it seems strange.


There is no security risk to my data, as this app only uses "read" operation of the public database. I didn’t try any other operations or private databases.

Is this a bug and could it stop working? Or is this a feature which will remain working? This tells me that under certain conditions, any app can read the CK container of any other app from any developer account, if they know the correct CK container ID to talk to. Is this expected? (Or maybe it only keeps working because they were previously under the same developer account, and the system knows to keep this connection? And if I were try to randomly read any other app’s container, it would fail?) Any docs or guidance from Apple?

Accepted Reply

Ok. That makes sense. See my response below...copied here:


The app can access the CloudKit container (of A) because the App ID and the app's entitlements file contains the CloudKit container (of A). That was done when Developer A created the CloudKit container or used an existing CloudKit container to which they had access. That CloudKit container is still Developer A's. It did not transfer when the app ownership transfered.

Developer A can access that CloudKit container from their dashboard. That may be a security issue.

Developer B cannot access that CloudKit container from their dashboard. That might be an access issue. You can add Developer B to the team (of Developer A) that has access to the container in the dashboard.



And you now wish to move everything to Developer B and terminate Developer A. But the app is pointing to a container of Developer A so I don't think you can terminate Developer A. If you did, you would not be able to monitor CloudKit Dashboard even if Developer B became a member of Developer A's team. And it is unclear if the container would remain 'alive' - i.e. if it exceeded 'free' usage. You might be able to revise the app to point to a different container owned by B. That would require transitioning the data which could be complicated.

Replies

Edit - on rereading your post I see you are referring to the app accessing the CloudKit database not the developer accessing the database through the CloudKit Dashboard. Referring to access to the container through the CloudKit Dashboard - Is it correct that Developer B does not have access to the container but Developer A still does?


-----------------

>What I am seeing now: the app signed by developer account B can still access the CK container under developer account A.


Before I ponder the security issues - Did you mean to say "account A can still access" or "account B can access"?

AFAIK, devs can only transfer apps that aren’t iCloud enabled. No version of the app being transferred can use an iCloud entitlement.


Accepting what you're seeing at face value, the question is - do you own both accounts? Are you, in fact, dev A and dev B?

The app can access the CloudKit container because the App ID and the app's entitlements file contains the CloudKit container. That was done when Developer A created the CloudKit container or used an existing CloudKit container to which they had access. That CloudKit container is still Developer A's. It did not transfer when the app ownership transfered.


Developer A can access that CloudKit container from their dashboard. That may be a security issue.


Developer B cannot access that CloudKit container from their dashboard. That might be an access issue. You can add Developer B to the team (of Developer A) that has access to the container in the dashboard.

"Is it correct that Developer B does not have access to the container but Developer A still does?" correct. Developer A can access the container in CloudKit dashboard. Developer B can not.


For the second one - sorry, what I wrote is ambiguous. I mean: "The app signed by developer account B can still access the CK container owned by developer account A (ownership is manifested by the fact that A can access it in CK dashboard, and B can not)."

Ok. That makes sense. See my response below...copied here:


The app can access the CloudKit container (of A) because the App ID and the app's entitlements file contains the CloudKit container (of A). That was done when Developer A created the CloudKit container or used an existing CloudKit container to which they had access. That CloudKit container is still Developer A's. It did not transfer when the app ownership transfered.

Developer A can access that CloudKit container from their dashboard. That may be a security issue.

Developer B cannot access that CloudKit container from their dashboard. That might be an access issue. You can add Developer B to the team (of Developer A) that has access to the container in the dashboard.



And you now wish to move everything to Developer B and terminate Developer A. But the app is pointing to a container of Developer A so I don't think you can terminate Developer A. If you did, you would not be able to monitor CloudKit Dashboard even if Developer B became a member of Developer A's team. And it is unclear if the container would remain 'alive' - i.e. if it exceeded 'free' usage. You might be able to revise the app to point to a different container owned by B. That would require transitioning the data which could be complicated.

Fair enough. Thank you. Looks like I should migrate all the data to a new container owned by B, and then release a new version of the app talking to that container. The volume of the data is fairly small, and it's doable by hand.


I was really expecting the CloudKit container to be migrated over along with the rest of the app transfer. I can sort of understand why it wasn't (there isn’t really 1:1 mapping or association between apps and containers). I don’t believe I’m the first in the world to encounter this scenario - surely, apps using CloudKit must have been sold and transferred. Really curious what they have done in this case - especially if they use private containers, which the developer cannot migrate just like that. (My case only involves public container and all data is available to me.)

> I was really expecting the CloudKit container to be migrated over along with the rest of the app transfer.


This may be the source of the assertion that:

".....devs can only transfer apps that aren’t iCloud enabled. No version of the app being transferred can use an iCloud entitlement."


It's not so much that 'they can't use' but that 'they can't transfer ownership rights' hence the problems you encounter.

Post not yet marked as solved Up vote reply of PBK Down vote reply of PBK

This answer seems to be out of date. Since June, 2022, apps utilizing iCloud Containers CAN be transferred to a different developer.

https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer