Calendar and Reminders permission App Review checklist
Calendar and reminder data reveals where people go, who they meet, and what they plan. The permission level should match whether the app creates, reads, or edits those records.
Request only the Calendar or Reminders access level the feature needs. Apple EventKit documentation covers access to calendar and reminders data, including different request flows for events and reminders. AppReviewReady interpretation: a scheduling app should justify whether it creates events, reads calendars, edits existing events, or only hands off to the system.
Choose create, read, or edit scope
A booking app may only need to create an event. A calendar assistant may need to read conflicts. A task manager may need reminders access. These are different privacy cases and should not share one generic permission justification.
Write a short permission statement for each workflow: create event, check availability, sync schedule, import reminders, or update existing entries. Then remove any permission that is not tied to a workflow.
Avoid full access when a narrower path works
- Use a system event composer or write-only flow when the app only creates a user-approved event.
- Read access should be justified by availability, conflict detection, or calendar management.
- Reminder access should be separate from calendar access in copy and tests.
- Denied access should still allow manual scheduling, export, or copyable details where practical.
- Imported event titles, attendees, notes, and locations should be handled as sensitive data.
Treat event fields as private context
Calendar entries can expose health appointments, schools, clients, locations, religious events, travel, or legal matters. Avoid uploading broad calendar history when the app only needs a short availability window.
AppReviewReady interpretation: privacy labels should account for event titles, attendees, locations, notes, reminder text, and analytics derived from scheduling behavior. A 'calendar connected' badge is not a disclosure.
Test scheduling edge states
- Run with no calendars, multiple calendars, read-only calendars, and denied permission.
- Create an event, edit it externally, then return to the app.
- Test time zones, daylight saving changes, recurring events, and deleted calendars.
- Verify reminder due dates, lists, completion, and deletion sync correctly.
- Confirm account deletion removes server-side schedule copies where promised.
Give review a scheduling route
A reviewer should be able to test with a sample event. Do not require their personal calendar to contain a sensitive or specific entry.
For team scheduling products, separate availability computation from event storage. A server may need free/busy windows without retaining full event titles, locations, attendees, or notes, and the product copy should reflect that narrower design.
If the app writes events to shared calendars, test organizer, attendee, and read-only calendar states. Users should understand whether the app will invite other people, create alerts, or modify an existing event.
Calendar/Reminders review path: Feature: [booking, reminder sync] Access requested: [write-only, full, reminders] How to trigger: [steps] Data read/uploaded: [fields] Denied fallback: [manual scheduling] Sync or 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 scheduling privacy
Review calendar access, reminder access, privacy labels, and fallback states before submission.
Open the tool