When should your app ask for camera, location and notification permission?
A denied permission can break the main job of a work app: no camera, no photo evidence; no location, no proof of delivery. This guide shows how to time each request to the moment the user needs it and what to do when someone says no.
When should an app ask for permissions?
At the moment of need. Ask for the camera when the user taps Add photo, for location when they confirm a delivery or start a site visit, and for notifications after they have something worth being notified about, such as their first assigned job.
A short primer screen before the system prompt helps when the reason is not obvious. It should say what the user gets in their own terms ("Photos are stamped with time and place so the inspection record holds up in an audit") and offer a clear button that triggers the real prompt.
Asking at launch fails for a simple reason: the user has no idea yet why the app wants access. Many tap Don't Allow by reflex, and recovering from that means sending them to system settings, which few people do in the middle of a job.
Which permissions does a work app really need?
Most practical B2B apps need two or three permissions at most. Map each to the feature that depends on it and to what still works without it.
| Permission | Typical use in a work app | Moment of need | Fallback after denial |
|---|---|---|---|
| Camera | Photo evidence, scanning, defect capture | First tap on Add photo or Scan | Pick from photo library, or add a note |
| Location | Proof of delivery, site check-in, geotagged photos | Confirming a delivery or starting a visit | Manual address entry, flagged as unverified |
| Notifications | New jobs, approvals, schedule changes | After the first assignment or approval request | In-app inbox and email digest |
| Photos library | Attaching existing images | First tap on Attach from library | Camera capture instead |
| Tracking (ATT) | Ad measurement across other companies' apps | Only if you truly need it | Privacy-preserving attribution |
Apple's App Tracking Transparency rules, in place since iOS 14.5, require permission before tracking a user across other companies' apps and websites. Most work apps do not need it: product analytics inside your own app is not cross-app tracking, and campaign measurement can rely on privacy-preserving attribution. The analytics and attribution guide covers that set-up. If you do not need the prompt, do not show it; it adds a refusal moment with no benefit to the user.
How do you time and word a permission request?
- List the features that need each permission and pick the first one a new user is likely to reach.
- Place the request on the tap that starts that feature, not on the screen before it.
- Add a primer only when the purpose is not obvious. Tapping a camera icon explains itself; a background location request for delivery proof does not.
- Write the purpose string in job terms. "HaulDock uses your location to confirm where each delivery was dropped off" beats "This app needs your location."
- Build the denial path first. The task should still finish, with a clear note on what is missing.
- Offer a later re-ask from context, for example a banner on the delivery screen that opens settings, never a nagging loop.
- Check the platform rules. Apple's App Review Guidelines cover how apps collect data and request access; read the data collection sections before submission.
On company-managed phones, ask the customer's IT team how devices are configured before a rollout. Some settings are controlled centrally, which changes what your users will see. The managed distribution guide explains how company devices receive apps.
What do well-timed permission prompts look like?
The weak flow fires the notification alert on the first launch screen, before the user knows what the app does. The strong flows below tie each prompt to a task: LineSide QA asks for the camera when an operator logs a defect, HaulDock asks for location when a driver confirms a drop-off, and CrewBoard asks for notifications after the first shift is assigned. All are fictional.
Welcome to CrewBoard
Schedules for every crew.
Notifications may include alerts, sounds and icon badges.
Your first shift
Get a ping when your shift or site changes?
Log defect · Line 3
Photos are attached to the non-conformance report for this line.
Confirm drop-off
No permission prompt before the first tap on a feature.
Camera when the user taps Add photo, location when they confirm a delivery, notifications after their first assignment. Never all three on launch.
What permission mistakes hurt activation and trust?
- Stacking prompts on launch. Three refusals in ten seconds can leave the app unable to do its job.
- Vague purpose strings. "Needed for app functionality" invites a denial.
- Requesting "always" location when "while using" will do. Drivers and their employers notice, and it raises privacy questions in company reviews.
- Dead ends after a denial. If the job cannot finish without a permission, users will abandon the task, not change settings.
- Asking for tracking you do not use. An unnecessary prompt costs trust and gains nothing.
- Forgetting company buyers. Security reviewers will ask what you collect and why; a clear permission table helps the company purchasing conversation.
Trade-off: a primer screen adds a tap. Use it where the purpose is unclear or the permission is critical, and skip it where the button already explains the request.
What should you measure for permissions?
| Metric | Question it answers | Where to find it |
|---|---|---|
| Grant rate per prompt | Do users accept at this moment? | Your events: prompt shown, granted, denied |
| Task completion after denial | Does the fallback still let users finish? | Your events on the dependent task |
| Activation by permission state | Is a denial blocking first value? | Product analytics, split by permission |
| Settings re-enable rate | Does the contextual re-ask work? | Permission state checked on app open |
| Support tickets about access | Are users confused by a request? | Help desk tags |
Next: define the first result these permissions support in the activation guide, and see how onboarding sequences them in onboarding.
Frequently asked questions
Should an app ask for all permissions at launch?
No. Ask for each permission when the user starts the feature that needs it, so the reason is obvious.
What is a permission primer?
A screen shown before the system prompt that explains, in the user's terms, what they get by allowing access. Its button triggers the real prompt.
Do B2B apps need App Tracking Transparency?
Only if they track users across other companies' apps or websites. Most work apps can measure campaigns with privacy-preserving attribution and skip the prompt.
What happens if a user denies camera access?
The app should still let them finish the task, for example by attaching a photo from the library or adding a note, and offer a contextual way to enable the camera later.
When should a work app ask for notifications?
After the user has something worth being notified about, such as a first assigned job, a pending approval or a changed shift.
Should a driver app request always-on location?
Only if a core feature truly needs it. While-in-use location covers proof of delivery in most cases and raises fewer privacy concerns.
Can I change the text of the system permission prompt?
You supply the purpose string, but the alert's design and buttons belong to the operating system. Control the timing and the screen before it.
Sources & further reading
Regulator rules, platform policies and local data change. These sources let you check the facts on this page, last checked October 6, 2026.