An app opens and immediately throws up three permission dialogs — location, notifications, contacts — before the user has done anything or seen any reason to say yes. Most people tap “deny” on reflex, and here is the part that makes it costly: on both mobile platforms, a denial is often effectively permanent, because the system stops showing the dialog after a rejection or two. Getting runtime permissions right is less about the API, which is simple, and more about context and timing, because a permission you ask for badly is a permission you may never get another chance at.
A denial is expensive and often final
The stakes are higher than they first appear. When a user denies a permission, you do not simply get to ask again later at a better moment. After a rejection — on Android, after a couple; on iOS, often after the first — the system will no longer show your permission dialog at all. Requesting again silently does nothing, and the only path left is to send the user into the operating system’s settings screen to flip the toggle manually, which almost nobody does.
This changes how you should think about the request. It is not a low-stakes prompt you can fire whenever and retry if it fails; it is close to a one-shot, and a careless denial permanently disables a feature for that user. That reframing is the whole reason timing and context matter so much — you are spending a scarce, mostly-non-refundable opportunity, so you want to spend it at the moment the user is most likely to say yes.
Ask in context, at the moment of need
The single most effective principle is to request a permission at the exact moment the user is trying to do the thing that needs it, not at launch. Ask for camera access when they tap the camera button. Ask for location when they tap “find restaurants near me.” Ask for notifications after they have used the app enough to understand what you would notify them about. At that moment the request makes obvious sense — they just asked for the thing — so they grant it, because the permission and their intent line up.
Requesting up front, before the user has expressed any related intent, is the opposite: the request has no context, so the safe answer is no. The difference in grant rates between “asked at launch” and “asked when the feature is used” is large, and it costs nothing to move the request — it is the same API call, made at a better time. If you do only one thing, move every permission request from app startup to the point of first use.
Explain before you ask, when it is not obvious
For permissions whose purpose is not self-evident from the action, explain why before triggering the system dialog. This is the “pre-permission” pattern: show your own brief screen or prompt that says what you need and what the user gets for granting it, and only then, if they agree, fire the real system dialog. The advantage is that your own prompt costs nothing if declined — the system dialog is untouched, so you have not spent your one shot — whereas triggering the real dialog on someone likely to refuse burns the opportunity.
The reason this works is that the system dialog itself is bare — it says “App wants to access your location” with no room for your reasoning. Your pre-prompt is where the persuasion happens: a sentence of genuine benefit, shown at a relevant moment, so that by the time the real dialog appears the user has already decided yes. Use it for anything where the need is not blindingly obvious from context, and skip it where the action already makes the reason clear.
Handle “no” as a normal state, not an error
However well you ask, some users will decline, and your app must work anyway. A denied permission is not an error condition or a dead end — it is a normal state your app should be designed to handle gracefully. If location is denied, let the user type their city — and note that continuous location is one of the largest battery drains there is, so a user who declines it may be doing their battery a favor. If contacts are denied, let them enter details by hand. If notifications are denied, the app still works; they just do not get notified. Never block the user or crash because a permission was refused, because plenty of people will refuse and they are still your users.
This connects to a broader design instinct: the same graceful-degradation thinking that keeps a service running when a dependency dies applies to a denied permission — the feature that needed it degrades, and everything else carries on. What you must not do is nag, re-prompting on every screen or blocking access until they relent, which reads as hostile and gets apps uninstalled. Ask well once, at the right moment, with context; accept the answer; and make sure a “no” leaves a usable app.
The short version
Treat every permission request as a scarce, mostly one-time opportunity, because a denial is usually permanent. Never ask at launch; ask at the exact moment the user does the thing that needs it, when intent and permission align. For non-obvious permissions, explain the benefit in your own prompt first, so you only trigger the real system dialog for users likely to say yes. And design the whole app to work when the answer is no, degrading the specific feature rather than breaking. The API for requesting a permission is a few lines; everything that determines whether you actually get it is timing, context, and respect for the user’s answer.