Contacts permission App Review checklist
Contacts access is high-trust because it exposes other people, not only the user. Review readiness starts by proving the app does not need the whole address book when one selected contact would do.
Use a contact picker or limited contact selection when possible, and request broader Contacts access only for features that truly need ongoing address-book integration. Apple Contacts documentation says apps request permission to read and write contact data. AppReviewReady interpretation: build a field-level ledger so the app can explain why it needs names, emails, phone numbers, birthdays, notes, or organization fields.
Decide whether the app needs the address book
A referral, invite, emergency contact, address autofill, or CRM import feature may need contact data, but the scope varies. Many features only need one chosen person, not continuous access to all contacts.
Write the minimum fields needed for the feature. If the app only sends an invitation, it probably needs a phone or email field selected by the user, not every note and birthday stored in Contacts.
Prefer user-selected contact flows
- A picker flow makes the user's selection explicit and easier to justify.
- Full access should have a clear benefit such as sync, deduplication, caller identity, or address-book management.
- Bulk invite flows need throttling, preview, and anti-spam controls.
- Denied access should allow manual entry where practical.
- Deleted or changed contacts should not leave stale private data on the server.
Protect non-user data
Contacts often contain information about people who never installed the app. Treat upload, hashing, matching, enrichment, and sharing as privacy-sensitive behaviors even if the current user approved access.
AppReviewReady interpretation: if the server receives contact data, the privacy label and policy should describe collection, linkage, purpose, and deletion. Do not describe the feature as local-only if contact matching happens remotely.
Test contact edge cases
- Run with no contacts, one contact, many contacts, duplicate contacts, and contacts missing email or phone.
- Deny permission and verify manual entry or a useful explanation.
- Grant permission, import a contact, then revoke permission from Settings.
- Delete an imported contact inside the app and verify server cleanup where promised.
- Test child, workplace, finance, and health contexts with stricter sharing assumptions.
Prepare a Contacts review route
Reviewers should be able to verify the feature with fictional contacts. Do not depend on their real address book containing a specific record.
If invitations or referrals are involved, test the outbound message before submission. The copy should identify the sender, avoid spam-like urgency, and avoid sending repeated messages to the same contact without explicit user action.
For matching features, document whether contacts are hashed, uploaded, retained, or discarded. A claim that matching is private should be backed by the actual server and analytics behavior, not only by local UI copy.
Contacts permission review path: Feature requiring contacts: [invite/import] Access mode: [picker, full read/write] Fields used: [name, phone, email] Server upload: [yes/no] Denied fallback: [manual entry] Deletion behavior: [how to remove]
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 Contacts privacy
Review contact fields, upload behavior, invite controls, and privacy disclosures before submission.
Open the tool