AppReviewX Log in

Test what happens when users deny permissions

A test script for denied, later-revoked and 'ask again' permission states on Android and iOS.

updated ·3 min read

In this guide

Most testers tap "Allow" because they want to see the app work. Real users deny, change their mind, or revoke later in system settings. If your app has never been run in those states, this is where crashes and dead-end screens hide.

Permission behavior differs by platform and OS version. The Android points below follow Android's runtime-permission guide (see sources); for iOS, check Apple's current developer documentation for your target versions.

The states to cover

For each permission your app asks for (camera, location, notifications, contacts, microphone, photos), test these states:

  1. Not asked yet. First use of the feature.
  2. Allowed. The normal path, as a baseline.
  3. Denied once. The user tapped "Don't allow" and the app can usually ask again later.
  4. Denied with no further prompt. On Android, the guide says that if the user taps Deny more than once, the system dialog no longer appears and the denial counts as permanent, so the only way back is system settings. Rules and wording on iOS and on other versions differ; check the official documentation.
  5. Allowed, then revoked. The user turns it off in system settings while the app is in use or in the background. On Android 11 and newer, location, camera and microphone also offer "Only this time"; the guide says that if a one-time permission is revoked, the app's process terminates.
  6. Limited access. Some platforms offer partial grants, such as approximate location or selected photos.
  7. Unused for months. On Android 11 and newer, the system can automatically reset the sensitive runtime permissions of apps targeting API 30 or higher that go unused for a few months.

Test script

For every permission:

  1. Install fresh and reach the feature that needs it.
  2. Deny. Note what the screen shows.
  3. Try the feature again. Note whether the app asks again, explains, or sends the user to settings.
  4. Deny in a way that stops further prompts, if the platform allows it. Repeat the feature.
  5. Go to system settings and allow it. Return to the app. Does the feature work without restarting?
  6. Revoke it in settings while the app is open. Return. Does the app crash, freeze or show an error?
  7. Revoke it, force-close the app, reopen.

What good looks like

  • No crash, no blank screen, no endless spinner.
  • A short message says what the feature needs and why, in plain words.
  • The rest of the app still works.
  • When only settings can fix it, the message says so plainly and may offer a way to the settings page. Android's guide advises against nagging users or trying to talk them out of their decision.
  • After the user allows it in settings, the feature recovers by itself.

Common failures

  • The app asks again immediately after a denial, in a loop.
  • The code assumes a permission is still granted because it was granted earlier.
  • A feature shows an empty screen with no explanation.
  • A denied notification permission silently breaks a setup step (on Android 13 and newer, notifications need a runtime permission too).
  • The explanation is shown before any reason exists, at first launch.

What to ask testers

Give testers a short task: "Deny the camera permission, then try to scan. Tell me what you saw and whether you knew what to do next." Their confusion is your result.

AppReviewX gives you private, structured feedback from testers on real devices, including the "what happened when you denied it" answers you cannot get alone. See how AppReviewX works.