CloudKit and iCloud sync App Review checklist
CloudKit makes sync feel native when it works, but review often starts in a device state with no data, no iCloud, stale records, or a sharing edge case.
Design CloudKit sync around real account states: signed into iCloud, signed out, quota full, offline, first device, second device, shared record, conflict, and deletion. Apple CloudKit documentation describes moving data between apps and iCloud containers. AppReviewReady interpretation: a sync app needs an iCloud state matrix, not just a successful developer-device test.
Decide what belongs in CloudKit
List records, files, settings, user-generated content, shared objects, and derived data. Then decide whether each belongs in a private database, public database, shared database, local-only storage, or your own backend.
Do not use CloudKit as a vague backup promise. Users and reviewers need to know whether data syncs across devices, shares with other iCloud users, or remains only on one device.
Build an iCloud state matrix
- iCloud signed in and empty account.
- iCloud signed out or restricted.
- Network offline and later recovered.
- Quota full, permission error, or container misconfiguration.
- Same record edited on two devices before sync completes.
- Shared record accepted, revoked, or deleted by another user.
Explain where synced data lives
CloudKit data lives in iCloud containers and can involve private, public, or shared scopes. The app's privacy policy and UI should explain sync behavior in plain language, especially if other users can access shared records.
AppReviewReady interpretation: do not label data as local-only if it is synced through iCloud. Also do not promise team collaboration if records are private to one Apple Account.
Test sync and conflict recovery
- Create data on device A, open device B, and verify expected sync.
- Edit the same record on both devices while offline, then reconnect.
- Delete a record, reinstall the app, and confirm expected recovery or deletion.
- Share a record, revoke access, and verify the recipient state.
- Test account deletion and export expectations against CloudKit data behavior.
Prepare CloudKit review evidence
Review Notes are useful when sync value is invisible on a single device. Provide a sample path that demonstrates the feature without requiring the reviewer to own multiple configured devices.
Also document what happens when iCloud data and your own backend disagree. Support should know which source of truth wins and how users recover missing or duplicated records.
For shared records, verify notifications and emails do not reveal private titles or content to people who lost access. Sharing revocation should be reflected in every surface.
Quota or container errors should explain recovery without blaming the user.
If sync is optional, the app should work locally and explain what will not roam.
Retest migration when record schemas or zones change between app versions.
CloudKit review path: Data synced: [records] Container/database: [private, shared, public] iCloud-off behavior: [message] Conflict behavior: [merge/winner] Sharing behavior: [if any] Sample data: [steps] Deletion behavior: [summary]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check iCloud sync readiness
Review CloudKit containers, sync states, sharing, privacy, and conflict handling.
Open the tool