Photo Library permission App Review checklist
Photo access is not a yes-or-no permission. A review-ready app chooses between picker, add-only, limited library, and broader library access based on the user's task.
Ask for the smallest Photos access that completes the feature. Apple PhotoKit documentation explains that apps can work with limited library access and that apps that only save photos can use add-only access; Apple also provides private picker flows. AppReviewReady interpretation: full library access should be justified by an actual browsing or editing workflow, not by convenience.
Start with the photo task, not the API
Name exactly what the user is trying to do: pick one avatar, upload receipts, create a collage, save an edited image, import a camera roll, or manage albums. Each task implies a different level of access.
If the app only needs selected assets, prefer a picker or limited-library path. If the app only saves output, use the narrow save path. Full-library access should be reserved for features where users intentionally browse or manage their library inside the app.
Test limited, denied, and empty-library states
- Limited access should show selected assets and a route to update the selection.
- Denied access should explain the blocked feature without trapping the user.
- An empty library should not look like a network or account failure.
- Add-only access should not later assume read access exists.
- Photo metadata, location, and edits should match privacy-label answers.
Prompt only after visible user intent
A Photos prompt on first launch is usually weak unless the whole product is a photo-management app. Better review evidence comes from a visible button, preview, or task screen that explains why the user is choosing photos now.
AppReviewReady interpretation: the pre-prompt should describe the product action, not the framework permission. 'Choose screenshots for your report' is more reviewable than 'We need photo access to continue.'
Reconcile Photos access with disclosures
- Compare actual asset, metadata, and upload behavior with App Store privacy labels.
- Verify the privacy policy describes storage, sharing, retention, and deletion for uploaded images.
- Test whether analytics events include filenames, image identifiers, location metadata, or recognized content.
- Check user deletion and account deletion remove server-side copies where promised.
- Retest after adding AI, OCR, moderation, or cloud backup features.
Write reviewer evidence for photo flows
Provide sample steps only when the photo flow is hidden behind account state or paid features. The best review outcome is that the permission's purpose is obvious from the UI itself.
Re-run this checklist after adding OCR, AI classification, face grouping, automatic backup, or moderation. Those features can change the privacy meaning of the same photo picker screen because the app may start deriving or storing new information from selected assets.
Photo permission review path: Task requiring Photos: [avatar/upload/save] Access mode: [picker, limited, add-only, read-write] How to trigger: [steps] Denied behavior: [message/fallback] Data uploaded: [none or fields] Privacy label checked: [date]
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 Photos privacy
Review photo access, privacy labels, fallback states, and reviewer evidence before submission.
Open the tool