Permissions

The Popup That Ends Sessions

A user taps "Scan receipt". A grey system dialog jumps up asking for camera access.

No explanation. No context. Many users tap Deny on reflex.

That single moment can break the whole expense workflow, because the OCR engine never receives an image to read.

Permission design is therefore part of your product design, not an engineering detail.

What Just-in-Time Means

Just-in-time disclosure means you explain why the camera is needed immediately before the system prompt appears.

The explanation sits as close to the action as possible.

The user is already thinking "I want to upload this receipt". Your message simply confirms that the camera serves that exact goal.

Timing does most of the work here. The same sentence shown at signup would land as noise.

The Pre-Permission Screen

A pre-permission screen is your own screen, shown before the operating system dialog.

You control its words, tone and visuals. The system dialog gives you almost none of that.

It also gives you a safe rehearsal. If the user is not ready, they can back out without a hard denial recorded on the device.

Keep it to one purpose: camera access is required to digitise the receipt.

Framing Beats Asking

Framing is how you connect a technical requirement to the user's goal.

"Allow camera access" is a technical requirement. "Point your camera at the receipt and we will pull out the amounts for you" is a goal.

Same permission. Very different feeling.

Good framing names the benefit, the moment and the data being handled.

Reducing Friction At The Start

Friction is anything that makes the next step feel heavier than the reward.

An unexplained permission request is pure friction. The user pays a cost in attention and trust before receiving anything.

Contextual triggers reduce that cost by placing the request inside a task the user already chose.

The first interaction often decides whether the rest of the journey happens at all.

Feeding The OCR Engine

OCR means optical character recognition: software that reads text out of an image.

It cannot infer an amount it has never seen. Without camera access, there is no image and no extracted data.

So permission design is upstream of accuracy, automation and every report built on that data.

A denied prompt is not a small annoyance. It is a total breakdown of the automated expense workflow.

Putting It Into Practice

Trigger the request from a real user action, never at launch.

Explain the purpose in your own screen first, in one plain sentence about the receipt.

Let the system dialog follow immediately, while the reason is still on screen.

Design this moment as carefully as the scanning screen itself. It decides whether scanning ever begins.

Just-in-time disclosure explains why camera access is needed immediately before the system permission prompt.

• True
• False

Answer: True

This timing keeps the reason connected to the user’s current goal. Showing the same explanation at signup would be less relevant and may feel like noise.

A _____ is controlled by the product team, while a _____ is controlled by the operating system.

Answer: A pre-permission screen is controlled by the product team, while a system dialog is controlled by the operating system.

The product team controls the words, tone, and visuals of the pre-permission screen. The operating system controls the system dialog, which provides much less customization.

A user denies camera access while trying to scan a receipt. Why can this stop the automated expense workflow?

• OCR has no receipt image to read
• The receipt automatically becomes a PDF
• The system dialog starts scanning in the background
• The app receives the image without permission

Answer: OCR has no receipt image to read

OCR reads text from an image. If camera access is denied, the app receives no receipt image, so OCR cannot extract amounts or other receipt data.