Obtaining App Permissions the Right Way and Humanizing the Process

Remember all those times you discovered a new app, took the efforts to download it from the App/Play Store and opened the app, only to be greeted by a bunch of annoying back-to-back permissions prompts? We’ve all been there.

Yes, I understand that apps these days need multiple permissions to do things the smart way, engage users and perform core use-cases. And then there are apps like Uber and Snapchat that run with location or camera access permissions at their core, forcing users to grant them even if it was denied initially.

iOS allows an app to throw a permissions prompt within the app only once. On Android, attempts are not restricted but after the first attempt, a ‘Never Ask Again’ checkbox shows up.

Once this chance is lost, requesting the user to manually grant permissions via Settings makes it a tedious process and has had minimal conversion. Save this chance. Use the right context, copy and triggers before prompting. Do Permissions the right way.


Permissions while Onboarding

This is one of the most commonly implemented methods across iOS and Android. Android classifies Notifications and a couple of other permissions as normal, thus toggling them on by default during the app install. But on iOS, all permissions need to be manually approved – I picked a couple of popular apps that request for permissions during onboarding:

Permissions Prompt on User Onboarding across LinkedIn, Any.do and Meetup

LinkedIn and Meetup wait for the user to login and once successfully authenticated, notification access prompts up while the feed loads in the background, neatly utilising loading time. On the other hand, Any.do prompts for notifications access instantly on app open, blocking content on the welcome screen and the social login buttons.

If you had a visitor ring your store’s doorbell, would you first let them inside to experience the store or ask them to answer a series of questions at the doorstep?

Multiple other apps (Soundcloud, Ola, WeChat, PhonePe) greet users with prompts like Any.do, leading to friction in the login process, poor visibility of onboarding content, thus restricting a user from experiencing the app on his/her first visit. One or all of this eventually could lead to a frustrated user who drops off the app without even getting to experience it.

Paytm’s Prompts on Onboarding. (👾GIF)

Paytm’s prompts for 3 notifications back to back are further overlapped by the Login Modal, leading to 5 notification prompts in total.

All of this before a user can enter their credentials or understand what is happening in the background. 🤷‍


Permissions when needed

Across multiple applications, permissions like location access, contacts, microphone etc are put to use only after the user carries out certain events or lands on a specific screen – for the first time.

For example:

  • A cinema booking app needs access to your contacts to share the booking confirmation code with your friends only after the user makes their first ticket purchase.
  • A bank’s app needs access to your location only when you try to find branches/ATMs nearby for the first time.

And so on. If the permission prompt is thrown after the right action, the user understands the context real-time and is tempted to grant the permission instantly.

Non-Core Permissions across Zomato, Freecharge and Zeta

View SMS permission on Android is used to auto-fill the confirmation code sent via SMS. Zomato prompts for this only when the user arrives at the login screen and has requested for the code while FreeCharge’s prompt happens right after opening the app, even before the user reaches the mobile number screen.

On the Zeta app, location permission is a non-core feature that is used only when a user tries to discover/make payments to stores nearby. Instead of the request being done when the user lands into the appropriate screen, it shows up during a new user’s signup process, blocking the text fields that I’m expected to fill. Ugh.


Humanizing Permissions and Copy

Across most permissions, iOS allows apps to display a custom line of text in the permissions prompt. If this is utilised well, the user is first informed about the need for it leading to higher chances of granting it. Keep your copy dead simple, ELI5.

It’s super interesting how Whale, a Q&A app saves up the notification prompt request until the user views an influencer’s answer for the first time. Further, it uses context on a custom prompt with the name of the person.

Simple language, custom context and informs the user how they’d be benefited. Why would anybody not grant this?


Educating with Custom Prompts and Background Area

Since there’s only one attempt to directly request for permissions, multiple apps use custom prompts to educate users before the system prompt is thrown to them. Since custom prompts do not have design limitations and can include images, videos and text, they help in educating users much better in certain use cases.

Lyft on iOS uses a custom prompt first, followed by the system prompt, Ola directly goes with the system prompt. Myntra on Android uses a custom prompt to explain what their permissions are used for and once accepted, the system prompts are shown.

However, a commonly discussed point around this is that using custom prompts leads to two prompts per permission request and might not be the best way to educate the user, especially when your app requires 2+ permissions.

A few apps circumvent this by utilising the background area to convey text, visuals and explanations as the system prompts are being displayed. Couple of examples from MakemyTrip/iOS and OLX/Android below:

MakeMyTrip uses the background area to educate users while the permission prompts are being displayed. OLX has an animated location asset in the background area when the location prompt is shown.

Across multiple companies, business and growth teams make use of notification permissions to engage users with targeted push notifications and is thus considered a critical one. Considering the critical role it plays, it’s only obvious to handle it the right way and request for it at the right time.

Other permissions that are not a part of an app’s core functionality or business decisions, but only used to enhance experiences have to be requested for only when needed with appropriate copy, unless you’d want to use them for syncing data in the background even if the feature is never used.

Remember, you get only one chance to throw that prompt. Do it right.

If you’re a dev and/or want to know more about all the permissions that Android and iOS allow an app to access: Normal and Dangerous Permissions on Android, Access to Personal Data on iOS:Page 62.


Prodgasm is a collective of product experiences that make users go 😍 or 💩. Visit http://prodgasm.com to view or submit your own. To be notified on more posts like this, scroll down and follow the Prodgasm publication.

Thanks for reading through 🙌🏼. If you found this post useful, please applaud using the 👏 button and share it through your circles.