CloudKit CKShare: storage ownership, quota accounting and shared-zone failures

I am evaluating the storage architecture for a native iOS family-organising application using CloudKit. The design is preliminary, and I am seeking clarification before native testing and production deployment.

Proposed test scenario

  • Apple Account A owns a custom record zone in its private CloudKit database.
  • Account A creates a root CKRecord and CKShare.
  • Independent Apple Account B accepts the share with read/write permissions.
  • Account B accesses and updates shared records through sharedCloudDatabase.
  • Both accounts initially have separate iCloud storage allocations.

1. Storage ownership and quota accounting

Apple's documentation appears to describe shared CloudKit storage using different terminology.

The native sharedCloudDatabase documentation references the application's iCloud storage quota, while CKError.Code.quotaExceeded describes a shared-zone write failing when the zone owner's iCloud storage is full.

For records, shares, metadata and CKAssets created or modified by Account B in Account A's shared zone:

  • Whose iCloud storage allocation is consumed?
  • Is any additional storage counted against Account B?
  • Does any usage count against a developer-level CloudKit quota or generate operator charges?

2. Storage exhaustion and error behaviour

If Account A reaches its iCloud storage limit while Account B has available storage, should B's writes to A's shared zone fail with quotaExceeded?

Conversely, if B's storage is full but A has capacity, should B still be able to modify A's shared records?

How should the application distinguish quota failures affecting B's private database from failures affecting A's shared zone?

Does behaviour change when both accounts use the same Apple Family iCloud storage pool or when an account downgrades its storage plan?

3. Current CloudKit limits and costs

Could Apple clarify or identify authoritative documentation for:

  • Current native CloudKit storage, request and data-transfer allowances.
  • Whether 400 records/shares per operation and 2 MB per request remain current guidelines.
  • How change fetches, retries and partial failures are accounted for.
  • Any differences between CloudKit development and production environments.
  • Whether private/shared CloudKit usage can result in developer-billed charges.
  • Where developers can verify the applicable allowances for their own containers before production deployment.

I have not yet reproduced a quota-exceeded scenario in a focused Xcode project. I am seeking architectural clarification to design appropriate storage limits, recovery behaviour and native verification tests.

Links to authoritative Apple documentation or clarification from an Apple frameworks engineer would be greatly appreciated.

Conceptually, when account A shares a record in its private database to account B, it is like that A exposes a view of the record to B and allows B the access. The view becomes the record in B's shared database, and all the modifications B makes go to A's private database. There is only one copy of the record, plus some meta data for the management purpose.

With this picture, you know that:

  • The storage is counted against the quota of A, not of B.
  • B only holds some metadata for management purpose, which is pretty small.
  • Data in the private / shared database counts against the quota of the user, the data owner, not of the developer.

I don't think the "guideline" of "400 records/shares per operation and 2 MB per request" is right. When you do a CloudKit query that has a big result set, CloudKit returns records by batches, with the moreComing flag being true if there are more records to come. The batch size is several hundred, but with the moreComing flag, that's not a limit. Also, the maximum request payload size (not including assets), if you meant that, is 20MB, not 2M.

Regarding the quota and rate manangement, I don't have any information ready to share.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.