# Guideline 5.1.1(iv) - Privacy: Permission Prompt UI Encourages or Delays Access

**Guideline:** 5.1.1 · **Store:** Apple App Store · **Risk:** low · **Difficulty:** easy · **Typical turnaround:** 1-3 hours

Canonical URL: https://appstorereject.com/rejections/apple/5/guideline-511iv-privacy-permission-prompt-ui-encourages-or-delays-access

## Description

Apple rejected your app because the custom UI you show around an OS permission request (microphone, camera, location, contacts, photos, etc.) encourages, pressures, or gates the user into granting access. 

Common triggers: 
1. A pre-permission screen with an action-style button like "Enable Microphone" instead of neutral copy like "Continue" or "Next"
2. An option that lets the user dismiss your custom screen with a "Not Now" / close button so the system prompt is never shown
3. Copy that frames the permission as required to use the app when it isn't. 

Per 5.1.1(iv), apps must not condition functionality on more permissions than are strictly necessary, and must not nudge users toward granting access — the user must always reach the system permission alert after seeing your priming screen, with a neutral path forward.

## Common variations

- Pre-permission screen uses "Enable Microphone" / "Enable Camera" / "Allow Location" as the primary button label
- Pre-permission screen has a "Not Now" or close (X) button that dismisses the screen without ever invoking the system permission alert
- Copy on the priming screen frames the permission as required ("You must enable the microphone to use this app") when the feature is optional
- App blocks all functionality behind a permission that is not required for core use (e.g. forces location access on launch for a feature that doesn't need it)
- Same issue raised against camera, location, contacts, photos, Bluetooth, Face ID, or HealthKit instead of microphone — the rejection text and fix are structurally identical

## Example rejection email

```
Guideline 5.1.1(iv) - Legal - Privacy - Data Collection and Storage

Issue Description

The app encourages or directs users to allow the app to access the microphone. Specifically, the app directs the user to grant permission in the following way(s):

- A custom message appears before the permission request, and to proceed users press a "Enable Microphone" button. Use words like "Continue" or "Next" on the button instead.
- A custom message appears before the permission request, and the user can close the message and delay the permission request with the Not Now button. The user should always proceed to the permission request after the message.

Next Steps

Please revise your app to ensure the user is not encouraged or directed to grant access to the microphone (or camera, location, contacts, photos, etc.). When the user is presented with a permission request, the app should not include any language that requires or encourages the user to allow access.
```

## Resolution steps

## How to Fix: Permission Prompt UI (5.1.1(iv))

1. **Rename the action button to neutral copy** — On any pre-permission ("priming") screen that appears before iOS shows its system permission alert, change the primary CTA from "Enable Microphone" / "Allow Camera" / "Turn On Location" to a neutral verb like **"Continue"**, **"Next"**, or **"Got it"**. The button should describe the *user's progression through the flow*, not the permission outcome.

2. **Remove any "Not Now" / "Skip" / close-X path on the priming screen** — Apple's rule is that once the user reaches your priming screen, the very next thing they see must be the system permission alert. Delete the secondary dismiss button. The user can still decline at the *system* alert (that's the OS's "Don't Allow" button) — what's not allowed is your app having its own "delay this" affordance before the system prompt fires.

3. **Trigger the system alert immediately on the neutral CTA** — The "Continue" button's tap handler should call the relevant request API with no intermediate steps:
   - Microphone: `AVAudioApplication.requestRecordPermission` (iOS 17+) or `AVAudioSession.sharedInstance().requestRecordPermission`
   - Camera: `AVCaptureDevice.requestAccess(for: .video)`
   - Location: `CLLocationManager.requestWhenInUseAuthorization()` / `requestAlwaysAuthorization()`
   - Photos: `PHPhotoLibrary.requestAuthorization(for:)`
   - Contacts: `CNContactStore().requestAccess(for:)`

4. **Drop "required" / "must" language from the priming copy** — Reviewers flag pressuring copy as well as pressuring buttons. Rewrite the body text to *describe what the feature does* ("Recording lets you add voice notes to your entries") rather than *demanding* permission ("You must enable the microphone to continue").

5. **Don't gate unrelated app functionality on the permission** — If the user declines at the system alert, the rest of the app must still work. Only the feature that genuinely needs the permission should be unavailable. Hard-blocking the entire app on a permission denial is an independent 5.1.1 violation.

6. **Apply the same fix to every permission your app requests** — The reviewer cited microphone in the rejection email, but if you have the same priming pattern around camera, location, contacts, photos, Bluetooth, or HealthKit, fix all of them in this submission. A second rejection for the same pattern on a different permission is common.

7. **Reply with screenshots in App Review Notes** — When you resubmit, attach before/after screenshots of the priming screen showing the new neutral CTA and the absence of a dismiss button, plus a short note: "Per 5.1.1(iv) we have updated the microphone priming screen — the action button now reads 'Continue' and the system permission alert is presented immediately. Same change applied to camera and location flows."

## Appeal guidance

Appeals rarely succeed for 5.1.1(iv) — the rule is about the literal UI strings and the presence/absence of a dismiss button, both of which are easy for the reviewer to verify from a screen recording. Only consider an appeal if the reviewer cited a screen that does not actually contain a priming step (e.g. you rely solely on the system alert with no custom screen at all). Otherwise, fix the copy and the dismiss button and resubmit — that's faster than appealing.

## Before / after examples

**Before:** // SwiftUI: priming screen with "Enable Microphone" button + "Not Now"
struct MicPrimingView: View {
    var onDone: (Bool) -> Void

    var body: some View {
        VStack(spacing: 16) {
            Text("You must enable the microphone to use voice notes.")
            Button("Enable Microphone") {
                AVAudioApplication.requestRecordPermission { granted in
                    onDone(granted)
                }
            }
            Button("Not Now") { onDone(false) } // <- dismisses without prompting
        }
    }
}
**After:** // SwiftUI: neutral CTA, no dismiss button, system alert always shown
struct MicPrimingView: View {
    var onDone: (Bool) -> Void

    var body: some View {
        VStack(spacing: 16) {
            Text("Recording lets you add voice notes to your entries.")
            Button("Continue") {
                AVAudioApplication.requestRecordPermission { granted in
                    onDone(granted) // user can still tap "Don't Allow" on the system alert
                }
            }
        }
    }
}
**Why it works:** Replace the imperative button label and remove the in-app dismiss path. The user's only forward action triggers the system permission alert immediately — Apple's rule is that the system prompt must always follow your priming screen.

**Before:** // UIKit: same anti-pattern in a view controller
@IBAction func enableMicTapped(_ sender: UIButton) {
    sender.setTitle("Enable Microphone", for: .normal)
    AVAudioApplication.requestRecordPermission { _ in }
}

@IBAction func notNowTapped(_ sender: UIButton) {
    dismiss(animated: true) // user never sees the system alert
}
**After:** // UIKit: single neutral CTA, system alert fires immediately
@IBAction func continueTapped(_ sender: UIButton) {
    sender.setTitle("Continue", for: .normal)
    AVAudioApplication.requestRecordPermission { granted in
        DispatchQueue.main.async {
            self.handlePermissionResult(granted)
        }
    }
}
// notNowTapped removed; the user can still decline at the system alert.
**Why it works:** Removing the secondary 'Not Now' action removes the delay path that 5.1.1(iv) prohibits. The user retains the ability to deny via the OS alert, which is a system-level affordance Apple explicitly permits.

## Common questions

**Can you appeal a 5.1.1 rejection?**

Appeals rarely succeed for 5.1.1(iv) — the rule is about the literal UI strings and the presence/absence of a dismiss button, both of which are easy for the reviewer to verify from a screen recording. Only consider an appeal if the reviewer cited a screen that does not actually contain a priming step (e.g. you rely solely on the system alert with no custom screen at all). Otherwise, fix the copy and the dismiss button and resubmit — that's faster than appealing.

**How long does this typically take to fix?**

Typical turnaround is 1-3 hours (difficulty: easy). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-511iv-privacy-permission-prompt-ui-encourages-or-delays-access*