Camera and microphone permission App Review checklist
Camera and microphone access turns a private space into app input. Review readiness depends on obvious capture intent, clear off states, and no hidden background behavior.
Request camera or microphone permission only when the user starts a capture-related task. Apple AVFoundation documentation says users must explicitly grant each app permission to access the camera and microphone. AppReviewReady interpretation: prove when capture starts, when it stops, what is stored, and what the app does when access is denied.
Tie capture to a visible action
The user should see why the app wants the camera or microphone before the system prompt appears: scan a code, take a profile photo, record a note, join a call, capture evidence, or create media.
Avoid permission prompts during onboarding unless capture is the app's immediate first task. A prompt that appears before context feels like data collection rather than feature enablement.
Make purpose strings specific
- Camera text should name the feature, not say only that access is required.
- Microphone text should explain recording, calls, voice input, or audio analysis separately.
- If camera and microphone are both needed, the UI should make that combined capture obvious.
- Screenshots and previews should not imply background listening or recording beyond the feature.
- Denied states should keep non-capture features usable where possible.
Test start, pause, mute, and stop states
Reviewers and users need to understand whether the app is actively capturing. Test camera preview hidden, microphone muted, app backgrounded, call ended, upload canceled, and recording deleted states.
AppReviewReady interpretation: a mute button should mean what users think it means. If audio is still being analyzed for levels, noise suppression, or transcription, make the product behavior and privacy disclosure consistent.
Document what happens to captured media
- Record whether images, video, audio, transcripts, thumbnails, or derived features leave the device.
- Verify privacy labels and policy cover collection, linkage, retention, and sharing.
- Test failed upload, canceled capture, deleted draft, and account deletion behavior.
- Check whether third-party SDKs can access captured media or metadata.
- Confirm sensitive categories such as health, child, workplace, or finance capture get stricter review.
Give review a safe capture route
Use fictional sample content and avoid asking the reviewer to record private information. A capture app should be testable without exposing a real person, customer, or confidential room.
Also verify that capture permissions are not requested by inactive SDK paths. Video chat, scanning, analytics, support recording, and creator tools should each have separate trigger conditions so a disabled feature cannot still cause a camera or microphone prompt.
If recording can continue while another screen is visible, add an in-app indicator and an obvious stop route. The system indicator helps, but the product still needs to explain the active capture state in its own workflow.
Camera/microphone review path: Capture feature: [scan, call, recording] Permissions requested: [camera, microphone] How to trigger: [steps] What is stored/uploaded: [summary] Mute/off behavior: [expected] Denied fallback: [behavior]
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 capture readiness
Review camera, microphone, storage, privacy, and fallback behavior before submission.
Open the tool