Guideline 5.1.1
Guideline 5.1.1(iv) - Privacy: Permission Prompt UI Encourages or Delays Access
Our Take
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.
Resolution Guide
**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.
**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.
**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:
- Camera: `AVCaptureDevice.requestAccess(for: .video)`
- Location: `CLLocationManager.requestWhenInUseAuthorization()` / `requestAlwaysAuthorization()`
- Photos: `PHPhotoLibrary.requestAuthorization(for:)`
- Contacts: `CNContactStore().requestAccess(for:)`
**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").
**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.
**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.
**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."
Example Rejection Email
Consider Appealing
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
// 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
}
}
}
// 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
}
}
}
}
}
What changed: 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.
// 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
}
// 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.
What changed: 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.
Community Solutions · 0
Sign in to share your solution.
More Guideline 5 (Legal) rejections
- Guideline 5 - Legal: Remove Watermark Feature
- Guideline 5.1.1 - Data Collection and Storage: Incomplete Privacy Manifest
- Guideline 5.1.1 - Data Collection and Storage: Missing Purpose Strings
- Guideline 5.1.1 - Data Collection and Storage: Privacy Manifest Missing
- Guideline 5.1.1 - Data Collection and Storage: Privacy Nutrition Label Mismatch
- Guideline 5.1.1 - Data Collection and Storage: Privacy Policy