Mobile app permission testing checklist for Android and iOS

To test mobile app permissions, run the affected task with access granted, denied and changed later in Settings. Include limited or temporary access where the app and OS support it. Check what happens to the user's work when access changes, then confirm they can recover and complete the task. Record the starting permission state beside every result.

A camera test that passes after tapping Allow can miss a user stranded on a blank screen after denying access. Start with the permission history, then test the task through to its result, including a return from Settings.

What should you agree before testing permissions?

List the features that use protected data or hardware and agree the expected behaviour with the feature owner. “The app handles denial” is too vague to test. For a delivery app, a useful expectation might be: “If location access is denied, the customer can enter an address manually.”

For each feature, write down:

• The trigger: which action should request access, such as opening the camera.
• The fallback: what the user can do if access is unavailable.
• The recovery: how the feature should respond after access changes.
• The saved work: which text, selections or queued items should survive the interruption.

Ask engineering which platform versions and access modes need separate runs. A system photo picker and an app's own gallery can need different tests even when both start from Add photo. Use your mobile device test matrix to assign the relevant configurations, rather than repeating every case on every phone.

Which permission states belong in the checklist?

Run each applicable row against a named feature and build. Record the actual OS labels; the choices won't be identical across permissions or platforms.

Starting state or change	Test action	What should you check?
No choice made yet	Open the feature that needs access	Request appears at the agreed point and explains the feature's need
Request denied	Continue, cancel or use the fallback	No blank dead end; unrelated tasks still work
Access granted	Complete the task	Feature works and its result is saved as expected
Earlier denial	Open the feature again	App handles the current state without a request loop
Granted → denied in Settings	Return to the app and retry	App recognises lost access and handles saved work correctly
Denied → granted in Settings	Return and retry the same task	Feature recovers without requiring an unexplained reinstall
Limited, approximate or temporary access	Use the feature within that choice	App respects the available access and explains any remaining limitation

Copy this run record into your test system. Mark unsupported states as not applicable and explain why.

Feature / expected fallback:
App version and build / distribution channel:
Device / OS version:
Installation history / relevant account and data:
Permission being tested:
State before the test / how verified:

[ ] First request: allow and deny in separate controlled runs.
[ ] Previously denied: retry the feature.
[ ] Granted: revoke in Settings, return and retry.
[ ] Denied: grant in Settings, return and retry.
[ ] Supported limited or temporary choices: test separately.
[ ] Check saved work, cancellation and unrelated tasks.
[ ] Record recovery, evidence and any untested states.

Actions / exact choices:
State after the test:
Expected result / actual result:
Pass, fail or blocked / evidence link:

Which Android behaviours can change the result?

Repeated denial can stop Android showing the system request dialog. A missing prompt therefore needs the earlier choices recorded before it can be diagnosed. Android 11 and later also offer Only this time for camera, microphone and location requests. Its duration depends on app activity and the user's actions; don't assume a fixed timeout for every run.

Revoking permission can terminate the app's process. During a Settings-change test, record whether the app restarted and what happened to the unfinished task. A restart alone isn't proof of an app crash; an empty screen or lost draft still needs investigation against the agreed behaviour. Android's runtime permission guide documents temporary grants and process termination on revocation.

For location features, test the access the feature actually needs. Android distinguishes foreground from background access, and approximate from precise location. A foreground pass doesn't cover a background journey. See the location permission guide.

Photo access also needs its own cases. Android's Selected Photos Access guidance explains how a user can share selected media rather than their whole library, with behaviour depending on the OS, target SDK and implementation. Ask engineering which gallery path the build uses before deciding which choices should appear.

Which iOS cases need separate runs?

iOS remembers the response to a camera or microphone access alert. Opening the feature again doesn't necessarily produce another system prompt. Test the app's response after denial, then change access in Settings and retry. Apple's capture authorisation guide describes those separate camera and microphone decisions.

For apps that use PhotoKit library access, include a limited-library run. Select a small set of test images and check the gallery only offers what the app can access. Then change the selection and return. Apple's Photos privacy guide also explains that the system photo picker can let people choose images without granting the app library access. Don't file a missing library prompt as a defect until you've confirmed which route the feature uses.

Location has a separate authorisation model. Test the access level required by the feature and changes made in Settings. Apple's Core Location guide describes how apps receive authorisation changes, including when a suspended iOS app resumes. Check the feature after returning, rather than stopping the test at the Settings toggle.

How do you keep the test state repeatable?

Before each run, inspect the app's current access in system Settings and record the relevant history. “Fresh install” and “permission never requested” shouldn't be interchangeable labels in a test record: verify the state you need.

Keep first-request tests separate from tests on an existing installation. For the latter, create the draft or start the task before changing access. Resetting everything between attempts can hide the failure you're trying to reproduce.

Use test accounts and harmless photos. If you need engineering to reset permission state, preserve the failing evidence first and record what they changed. Avoid guessing a universal reset procedure for every OS and permission.

What should a permission bug report include?

Describe the whole transition, including the earlier choice. “Camera doesn't open” leaves out whether the user denied the request, revoked access later or returned from Settings after granting it.

Here is a fictional report for a photo attachment flow:

Title: Attachment screen stays blank after camera access is enabled in Settings
Build: 2.8.1 (206), internal test build
Device: iPhone 15, iOS 18.5, physical phone
Starting state: Camera denied earlier; delivery note saved in the form

Steps:
1. Open the delivery form and tap Take photo.
2. Follow the app's link to Settings and enable camera access.
3. Return to the app and tap Take photo again.

Expected: Camera opens; the delivery note remains in the form.
Actual: Blank attachment screen. Back returns to the saved note.
Frequency: 3 failures / 3 attempts with the same setup.
Recovery: Closing and reopening the app allows capture.
Evidence: Recording shows the denied state, Settings change and failed retry.

Review the recording for personal information before sharing it. If the prompt or Settings change isn't visible in the capture, transcribe the exact choice into the steps. The screen recording guide covers the rest of that handoff.

Use the bug report template generator to format the issue for your tracker. Keep the permission history in the reproduction steps so the next tester can reach the same starting point.