Camera permissions and trust

iOS permission requests are a trust moment. Camera requests are the highest-stakes trust moment in the mobile ecosystem — camera access feels personal in a way that notification access or even location access doesn't.

For an app that literally cannot function without camera access, a denial is terminal. The user can't use the product. They'll either re-enable it in Settings (rare) or uninstall.

Camera denial rates across iOS apps typically run 15–30%, depending on the category and the quality of the permission ask. For productivity apps, rates tend toward the lower end — users install them with intention. But 15% is still 15% of installs that never activate.

Here's how we designed the permission ask to earn rather than request.

### The problem with immediate permission requests

The default pattern — present the iOS permission dialog on first app launch — is the worst pattern. You're asking for camera access before the user has experienced any value from the app. They have no reason to trust you with their camera. The denial rate on this pattern is high.

The research on this is clear: permission requests work best when they're contextual (the user is already doing something that requires the permission), comprehensible (they understand why you need it), and anticipated (they've been primed for the ask).

### Our three-step permission pattern

Step 1: The pre-permission screen

Before triggering the iOS system dialog, we show our own screen that explains:

• What camera access is for (scanning whiteboards)
• What it's not for (we don't store photos, we don't have access when the app is closed)
• One sentence on why it's essential (without camera access, BoardSnap can't function)

This screen has two buttons: "Allow Camera Access" (which triggers the iOS dialog) and "How it works" (which opens a 3-screen explanation of the data flow).

Critically: we never trigger the iOS system dialog from a cold state. We always pass through this pre-screen first.

Step 2: The iOS permission dialog

This is the one Apple controls. We can't change the text, but the NSCameraUsageDescription string in Info.plist is ours to write. Ours says: "BoardSnap uses the camera to scan whiteboards in meetings. Your photos are processed privately and never stored on our servers."

Straight, plain, privacy-forward.

Step 3: Graceful denial handling

If the user denies: no guilt, no lecture, no dark patterns. A single screen that says "Camera access is required to scan whiteboards. You can enable it in Settings → BoardSnap → Camera" with a direct "Open Settings" button.

We don't re-trigger the permission dialog. That's not allowed by iOS and it destroys trust. We wait for the user to re-enable it.

### The numbers

With this pattern, our camera permission denial rate in beta was approximately 6%. Compared to the 15–30% industry range, that's significant — though our beta population was self-selected toward technical users, so the real-world number will likely be somewhat higher.

The "How it works" option on the pre-screen was clicked by 22% of users before allowing. Those users had a 2% denial rate — much lower than users who went straight through. The explanation built enough trust to make the ask easy.

### The broader principle

Every permission is a trust transaction. You're asking users to extend access they're not required to give. The way to earn it is:

• Ask at the moment the permission is contextually relevant, not at launch
• Explain clearly what you're using it for and what you're not
• Make the privacy case proactively — don't wait for them to wonder
• Handle denials gracefully — no shame, clear instructions to re-enable

Camera permission isn't something you demand. It's something you earn.