Don't Ask for Permissions Up Front: Runtime Permission Prompts for Vibe Projects

The short version: permission is not about asking for more, it is about asking at the right moment

Almost every app, and many web apps, asks users for permissions at some point: notifications, location, camera, photos, microphone, contacts. Ask the wrong way, and a single tap on "Don't Allow" can disable that feature forever. Worse, on mobile systems the official permission dialog often gets only one real chance: after a user declines, the system may stop showing it, and the only way back is for the user to open Settings manually.

So permission requests are not a small question of "how to word a popup." They are a design question: at what moment, for what reason, and in what order do you ask? This guide covers exactly that: when users are most willing to say yes, how to recover gracefully after a no, and how each permission type should be handled differently.

First, a boundary note, so this guide does not overlap with earlier ones. This guide covers user-facing runtime permission prompts: notifications, location, camera, and other system permissions, and when to ask users for them. The earlier agent permission contract guide is a different topic: which files an AI agent may touch and which commands it may run. That sets rules for agents, not requests to users. The earlier settings and preferences guide covers the switches themselves. This guide covers the timing and wording of asking, which complements it. The login and permissions guide covers account-system permissions. This guide covers device and system-level permission requests.

Why asking for everything up front gets refused most

Many apps fire three or four permission dialogs the moment they open: notifications, location, photos, contacts, all at once. Users have just arrived. They do not know what the app does yet, or what they get in return. Their first instinct is to refuse everything. That is not stinginess. It is common sense: before trust exists, any request looks suspicious.

The second reason is that the official chance is often only once. On iOS and Android, once a system permission dialog is declined, the app cannot keep showing it indefinitely. Some systems stop showing the official dialog entirely, leaving the app to build its own guide page telling users to open Settings manually. That path converts far worse than the first official dialog. So the timing of the first ask almost decides the final grant rate for that permission. Wasting the first chance before users understand the situation is the most expensive design mistake in this area.

The third reason is that permissions drag each other down. A user who just declined one permission is already annoyed. A second and third dialog right after will be declined at even higher rates. Asking for permissions is not "ask for several at once to save time." It is "ask for one at a time, and only ask the next one after the first went well." Order and pacing are part of the design.

Three rules for golden timing: when needed, when the benefit is clear, when users can afford it

Rule one: ask when users just tapped the feature that needs the permission. This is the most basic and most effective rule. Users tap "Scan code," and you ask for camera permission: instantly clear. Users tap "Stores near me," and you ask for location permission: instantly clear. Ask for location permission the moment the app opens, before users tapped anything, and they will only think: why do you want my location? Timing itself is an explanation. With the right timing, the copy can be short. With the wrong timing, no copy length helps.

Rule two: before asking, say in one sentence what users get, not what the app gets. "Allow notifications so we can tell you the moment your order ships" puts the benefit on the user. "We need notification permission to send messages" puts the need on the app. Both ask for the same permission, but they feel completely different. Benefits must be specific: name the scenario and the moment, not "a better experience."

Rule three: only ask when users can afford to be interrupted. Users rushing through a task, filling in a form, or handling something urgent do not want a permission dialog. Their thought is "let me finish this." Any interruption in that state gets refused. Wait until they finish what they are doing and are relatively idle, and the success rate rises noticeably. Timing is not only "at which feature step," but also "in what state the user is in."

Pre-prompts: explain in your own interface first, then show the system dialog

A pre-prompt is a practical technique: before the official system dialog, use your own screen to explain in a sentence or two why the permission is needed and what happens after granting it. Users tap "Got it," and only then does the system dialog appear. This has two benefits. First, the explanation can be more specific and more tied to the scenario than the system dialog allows. Second, if users tap "Not now" on the pre-prompt, the app has not yet spent its one official chance and can try again at a better moment later.

Pre-prompts have two red lines. First, do not make a pre-prompt look like a system dialog. Some apps deliberately copy the system dialog's appearance to trick users into tapping "Allow," only for users to discover it was just a pre-prompt and a real system dialog follows. Users feel deceived. A pre-prompt should look like your own interface, with buttons that say "Next" or "Got it," never impersonating the system. Second, do not cram a privacy policy into a pre-prompt. Its job is to explain "why" and "what you get" in a sentence or two. The full privacy policy belongs in Settings for people who want it.

Not every permission needs a pre-prompt. For camera or location where tapping a feature makes the need instantly obvious, the system dialog alone is usually enough. For notifications, contacts, or background location, where users may not immediately understand why, a pre-prompt is worth it. The test is simple: if you think a user's first reaction to the system dialog might be "why do you need this," add a pre-prompt. If the first reaction is "of course," ask directly.

Permission by permission: each type has its own temperament

Notifications are the most abused and most refused permission. Users who decline notifications are usually not refusing one particular notification. They are refusing "being interrupted." Before asking, think hard: are your notifications really worth interrupting someone? Order status, payment confirmation, and security alerts are worth it. "You may like" and "Today's picks" marketing messages are not worth spending a one-time official chance on. When asking, name the kinds and frequency, such as "only when your order status changes," not a vague "allow notifications."

Location needs two versions explained separately: only while using the app, or always in the background. If only while using, ask for "while using." Only ask for "always" when background use is genuinely needed, such as run tracking or navigation. Never ask for "always" just to save effort. Users seeing the word "always" become instantly more cautious. If background location is truly needed, explain the exact scenario and when it stops, for example "records your route from run start to run end, then stops automatically."

Camera and photos now have gentler options on modern systems: pick only a few photos, or take one photo without granting the whole library. Use minimal grants whenever possible instead of asking for the entire library. Users are highly sensitive about photos, and the phrase "read all photos" alone is enough to trigger a refusal. When asking, say clearly whether it is "only the photos you pick" or "ongoing access." The difference is large. Do not blur it.

Microphone and contacts are the most sensitive categories. For microphone, explain when recording happens, how long it lasts, and where recordings live. For contacts, be even more careful: many features do not need contacts permission at all. Share links, manual entry, and QR-code friend adding can replace it. If contacts access is unavoidable, say whether it reads "only contacts you actively pick" or "matches your whole address book." Those two have completely different privacy costs. Before asking for contacts, ask yourself: is there a way to do this without contacts permission? If there is, use it first.

After a refusal: do not nag, give users a way back home

After users decline, the worst response is asking again on the next launch, and again after that. Repeated asking only increases annoyance and can drive uninstalls. The right response is to accept the refusal, keep the feature working in a degraded way, and leave a clear path for users to come back later if they change their minds.

Degraded mode means: without notifications, do not rely only on push. Use in-app badges and order-page status instead. Without location, do not let "stores near me" simply fail. Let users type an address or pick a city manually. Degraded does not mean "nothing works without permission." It means "works, just with a bit more effort." Users who experience the degraded version's benefits are more likely to go back and grant the permission later.

The way back must be specific. Do not just write "please enable it in Settings." Users do not know where to go. Put an entry on the relevant feature screen, and when tapped, show the exact path, such as "Settings, then Apps, then your app, then Permissions, then Location," plus a button that opens the system settings page directly. The path must be accurate for the system version. A wrong path is worse than no path. The entry's copy should promise a benefit, not complain: "Turn on location to see stores near you right away," not "You declined permission, so this feature does not work."

Timing matters here too. After a refusal, do not chase users the moment they reopen the app. Wait until they use the relevant feature again, then re-explain with a pre-prompt. By then they have experienced the feature's context and are more likely to accept. If they decline a second time, accept it and stay on the degraded path long-term. Do not chase a third time. The gain from a third ask is far smaller than the cost of annoying users.

Copywriting: good versus bad, side by side

Good and bad permission copy often differ by a single sentence. Consider these pairs. Bad: "We need access to your location to provide better service." Good: "Allow location so we can show stores within 3 kilometers of you." The bad version's subject is "we need," and its benefit is the empty phrase "better service." The good version's subject is what users get, specific down to "within 3 kilometers."

Another pair. Bad: "Please allow notifications, or you will miss important messages." Good: "We will notify you when your order ships and arrives. We do not send marketing messages." The bad version threatens users. The good version gives reassurance: it names the notification kinds and promises what will not be sent. Users are not afraid of notifications themselves. They are afraid of notification spam. Promising "no marketing messages" removes exactly that fear.

One more, about photos. Bad: "Photo access is needed to upload images." Good: "Only the photos you pick will be used. Your whole library will not be read." The good version's power lies in "only" and "will not." They draw the boundary. When users grant permission, the question in their mind is exactly about boundaries: how much will you take? The clearer the boundary, the braver users feel about granting.

One general rule for copy: do not use evasive words for the button. Some apps label the button "OK," "Go," or "Try it now," so users only discover it is a permission request after tapping. That feels like a trap. Label buttons plainly: "Allow notifications," "Allow location while using." Plain is not clumsy. It is respectful.

Web apps need permission manners too

Everything above is often framed for mobile apps, but web apps have the same problem: browser notifications, geolocation, camera, and microphone all trigger browser-level prompts. Browser prompts are equally easy to waste: once users click "Block" or "Never ask again," the site struggles to ask a second time.

Web has one extra wrinkle: users may not realize they are using an "app" at all. They are just looking at a web page. A sudden "Allow this site to access your location?" prompt makes many users close the tab entirely. So the web must follow "ask when needed" even more strictly: ask for location only after users click "Find stores near me," ask for camera and microphone only after they click "Start video call." Never ask the moment the page finishes loading. Page load is when trust is lowest.

Web has one advantage: the page content itself can serve as the pre-prompt. Next to the "Find stores near me" button, a small line can say: "Location permission is needed, only for this search." Users read the explanation before clicking, so the system dialog does not feel abrupt. Writing the explanation next to the feature is more natural on the web than building a separate pre-prompt screen.

A pre-launch checklist: ten items, tick them one by one

Here is a checklist to run before shipping. First, is each permission asked when users just tapped the feature that needs it, and does the app fire several dialogs the moment it opens? Second, does each permission have one sentence explaining what users get, specific and free of empty phrases like "a better experience"? Third, do permissions that need a pre-prompt have one, and do permissions that do not need one avoid the extra step?

Fourth, does any pre-prompt impersonate a system dialog, and are button labels plain? Fifth, is location split between "while using" and "always," and does background location explain its start and stop? Sixth, do photos use minimal grants, so picking a few photos does not require the whole library? Seventh, are contacts truly necessary, and is there an alternative that avoids contacts permission?

Eighth, after a refusal, does the feature degrade gracefully instead of failing outright? Ninth, is the path back through Settings written accurately, with a button that opens system settings directly? Tenth, walk through the app as a first-time user and count: how many times were you asked for permissions, and how many times did any ask feel unexplained? The fewer the asks, and the fewer the unexplained ones, the better the design.

Permission requests, in the end, are negotiations of trust. Trust is not won with clever copy. It is built piece by piece through timing, boundaries, and graceful degradation: the right timing makes users feel understood, clear boundaries make users feel you are restrained, and decent service after a refusal makes users feel respected. Get those three right and grant rates rise on their own. Get them wrong and even the prettiest copy only postpones the refusal a little.