Mobile App Permissions Guide: What to Request and Why It Matters
I was sitting on a train once—half awake, coffee in hand—watching someone next to me download a new app. They hit “Allow” on everything without reading a word. Camera. Microphone. Contacts. Location. The whole lot. They didn’t look reckless… just busy. Which is exactly why permissions matter.
If you’re building a mobile app for your business (or trying to fix one that’s already out in the wild), permissions are one of those unglamorous details that can quietly make or break trust. Not because your app is evil. Because people are tired. And the moment your app feels nosy, they’re gone.
I’ve been on the other side of this—shipping features, chasing deadlines, thinking “We’ll tidy permissions later.” Later has a way of turning into never. And then you’re staring at one-star reviews that say “Why does a booking app need my contacts?” and you can’t even argue with them.
Permissions are a trust contract (whether you like it or not)
On iOS and Android, permissions are how your app asks to use device features—camera, location, photos, Bluetooth, notifications, and so on. Users can manage app permissions in their device settings, and they do. Sometimes out of caution, sometimes because they’re annoyed, sometimes because their mate told them to “turn everything off.”
The tricky bit is that permissions aren’t just technical switches. They’re emotional. They’re the moment a user decides whether you’re a helpful tool or a bit of a creep.
And yes, some permissions can create real security and privacy risks if granted without scrutiny. Even if you’re not doing anything shady, the combination of access you request can make your app a bigger target—or simply make people uncomfortable. You don’t want to be the app that accidentally trains customers to ignore privacy warnings.
So here’s the mindset I’ve learned to stick to: request the minimum permissions needed, request them at the moment they’re needed, and explain in plain English why you’re asking. That’s it. That’s the whole game.
What to request (and what to avoid) for most business apps
Not every app is the same, but most business apps fall into a few common buckets: bookings, ecommerce, loyalty, delivery, field service, internal tools, content apps. The permissions you need are usually predictable. The permissions you think you need are often… optimistic.
Below are the big ones—how they’re used, what users worry about, and how to ask without sounding like you’re trying to nick their data.
Notifications
When to request: only after the user has done something that makes notifications genuinely useful—placed an order, booked an appointment, started a delivery, followed a topic.
Why it matters: Notifications aren’t “privacy sensitive” in the same way as location, but they’re sensitive in a different way: they can ruin someone’s day. If you ask for push notifications on first launch, you’re basically saying, “Trust me, I’ll behave,” before you’ve shown any evidence.
Good reasons: order updates, appointment reminders, security alerts, delivery tracking. Weak reasons: “news and offers” before the user even knows if they like you.
How to explain: “We’ll send delivery updates and let you know if anything changes. No spam.” And then… don’t spam.
Location (precise vs approximate)
When to request: right when the user taps something like “Find stores near me” or “Use my location for delivery.” Not at sign-up. Not because it might be handy later.
Why it matters: Location is one of the permissions that sets off alarm bells. People associate it with tracking. Sometimes they’re right. Even if you only use it to show nearby services, the fear is understandable.
Good reasons: delivery address suggestions, nearby branches, local service availability, route optimisation for drivers. Be careful with: background location. If you need it, you’ll need a very clear reason—like live driver tracking during an active job.
Practical tip: If approximate location works, use it. If you only need location once, request it once. And always have a manual fallback—postcode entry, address search, “choose on map.” People feel calmer when they’re not forced.
Camera
When to request: when the user taps “Scan QR code,” “Take photo,” or “Upload document.”
Why it matters: Camera access feels intimate. It shouldn’t, but it does. Users imagine the camera turning on at random moments (yes, I know that’s not how it works—try telling your mum that).
Good reasons: scanning barcodes/QR codes, uploading receipts, identity verification, damage photos for insurance, profile photo. Avoid:
Practical tip: If your feature can use the system picker (choose an existing photo) without full photo library access, do that. It’s cleaner. Less scary. Less review drama.
Photos / Media Library
When to request: when the user chooses “Upload from photos.”
Why it matters: People worry you’ll slurp their entire camera roll. And sometimes apps really do ask for broad access when they only need one image.
Good reasons: uploading images for listings, support tickets, profile pictures, before/after photos. Better approach:
Practical tip: Design your upload flow so the user can pick a single image without granting full library permissions. It’s a small UX detail that screams “we respect you.”
Microphone
When to request: when the user starts a voice feature—voice notes, calling, in-app recordings.
Why it matters: Microphone access is one of those permissions that can trigger instant suspicion. People think “listening.” Again, not always fair, but it’s reality.
Good reasons: voice messaging, audio recordings, in-app calls. Weak reasons:
Practical tip: If you have a call feature, be explicit: “We need microphone access so you can speak during calls.” Keep it simple.
Contacts
When to request: almost never. And if you do, only when the user taps “Invite from contacts” or “Find friends.”
Why it matters: Contacts permissions are a trust minefield. Users worry you’ll upload their whole address book. They worry you’ll message people. They worry you’ll be weird.
Alternative: let users type numbers/emails manually, share an invite link, or use a referral code. Nine times out of ten, that’s enough.
If you truly need it: explain exactly what you access, what you store (if anything), and what you don’t do. And be prepared for many users to say no.
Bluetooth (and Nearby Devices)
When to request: when pairing with a device is the whole point—POS hardware, wearables, beacons, smart locks, printers.
Why it matters: Bluetooth permissions can feel random in a business app. Users don’t always connect it to “printing receipts” or “connecting to the card reader.” They just see another scary pop-up.
Practical tip: Put a short screen before the system prompt: “Next we’ll connect to your card reader via Bluetooth.” Then request. That one extra step saves a lot of confusion.
Calendar
When to request: when the user taps “Add to calendar.”
Why it matters: Calendar access can be reasonable, but asking for it at onboarding is odd. People don’t want an app rummaging through their schedule.
Better approach: use the system “add event” flow where possible, so the user stays in control. Most users just want the appointment saved—not a full sync relationship.
Storage / Files
When to request: when downloading invoices, saving reports, uploading documents.
Why it matters: It’s less emotional than location, but still sensitive. People worry about apps reading files they didn’t choose.
Practical tip: Use the system file picker so the user selects exactly what they want to upload. Don’t request broad file access unless your app is genuinely a file manager (and if it is, well… you already know the deal).
Timing is everything (and “on launch” is usually wrong)
The fastest way to get a user to hit “Don’t Allow” is to ask for permissions before they understand the benefit. It’s like asking for someone’s house keys on the first date. Even if you’re perfectly nice… it’s a lot.
Instead, tie each permission to a clear moment of value. Let them browse first. Let them build confidence. Then ask when the feature is right there, waiting.
If you’re improving an existing app, check your permission prompts. Are you asking for three things in a row on first open? Because I’ve done that. It felt “efficient” at the time. It was not efficient. It was a permission panic attack.
Explain it like a human (because the system prompt isn’t your friend)
Apple and Google show the official permission dialog, and it’s… fine. But it’s not warm. It’s not specific to your business. And it doesn’t always tell the user what you actually plan to do.
A simple pre-permission screen can help. One sentence. Maybe two. No legal waffle. Just: what you need, why you need it, and what the user gets out of it.
- Bad: “Allow access to location to improve user experience.” (What does that even mean?)
- Better: “We use your location to show stores near you. You can also search by postcode.”
And if the user says no? Don’t punish them. Don’t lock them out of the entire app because they won’t share their precise GPS coordinates. Offer alternatives. People notice when you respect a “no.”
Security, privacy, and the boring stuff that saves you later
Permissions are one part of the picture. The other part is what your app does after it gets access. If you’re collecting data, store as little as possible. Keep it for as short a time as possible. Make sure it’s encrypted where it should be. Limit who on your team can see it.
This isn’t me trying to be dramatic. It’s just that permission-heavy apps become more sensitive by default. If something goes wrong—lost device, compromised account, leaky analytics—you want the blast radius to be small.
Also: document your permissions. Keep a simple list of what you request and why. It helps with App Store reviews, internal conversations, and that inevitable moment when someone says, “Why do we have microphone access again?” and everyone goes quiet.
If you operate in regulated spaces—health, finance, kids’ apps—be extra cautious. You probably already know that. But it’s worth saying: the more sensitive the context, the more your permission choices become part of your brand.
A quick permission sanity check (the one I wish I’d used earlier)
When you’re deciding whether to request a permission, ask yourself:
- Does the core app still work if the user says no? If not, are you sure this is the right feature?
- Can we ask later? Later is nearly always better than now.
- Is there a manual fallback? Search, type, upload via picker, choose on map.
- Will a normal person understand the benefit in five seconds? If you have to explain it twice, rethink it.
- Are we requesting more access than we need? Precise vs approximate. Full library vs single photo. Background vs while-in-use.
It’s not a perfect checklist. But it catches the “we asked for this because it was easier” decisions—the ones that come back to haunt you.
Mobile app permissions aren’t just a box to tick on the way to launch. They’re a small moment where your app shows its character. Ask for too much, too soon, too vaguely—and people feel it.
Ask for just enough, at the right time, with a clear reason… and the whole app feels calmer. Like it’s on their side. Which, if you’re building something for your business, is kind of the point.
Most users won’t remember the exact permissions they granted. But they’ll remember how your app made them feel when it asked.