How to Create Better User Permission Requests in iOS Apps

Design iOS UX

A quick way to ruin a user's experience is to mishandle the way your app requests permissions. These permissions, like access to location, the camera and camera roll, push notifications, and calendar are often needed for an app's core functionality. Without the approval and access to these system services, the app won't work as it's meant to, making it less valuable to users. That will also cause confusion for users, and runs the risk of losing them entirely.

When it comes to user permissions in iOS apps, Savvy Apps focuses on three key elements: timing, context, and messaging. This approach ensures that we successfully navigate users through the complicated, unintuitive permissions process. Here's an in-depth look at how these three factors can make or break a permission request.

Timing is Everything for App Permission Requests

Don't bombard users with a slew of permission requests the moment the app launches for the first time. This approach, a common mistake, can be overwhelming. When faced with multiple dialogue requests in a row, especially during launch, people tend to get frustrated and might even just tap “Don’t Allow” for everything. Many apps also try to do all of the permission requests as part of the onboarding process. A better way of setting up a user-friendly flow into a permission request is by taking the user through a walkthrough or tutorial, introducing each of the features, and guiding the user through the corresponding requests one at a time.

We've found the best time to hit the user with a permission request dialogue is when it's absolutely needed. This approach helps the user understand what value your app promises instead of interrupting the onboarding flow with alerts. For example, Peach does a great job of waiting until the user is about to use a particular feature for the first time before asking for permission. It ties the requests to access the device's photos, camera, and microphone to the moment the user actually attempts to post a photo or video.

TimeShot, a customer we have in private beta, has a similar permission request approach in that it waits until the user is about to add a profile photo before requesting access to the device's camera and photos. What TimeShot does differently is that it places both permissions requests on the same overlay using a library called PermissionScope. Using this library, the user isn't bombarded with multiple screens. This streamlines the process for the user, getting multiple permissions out of the way more quickly. It also employs contextual copy and visual cues as the user allows or denies the requests.

Try to pair the feature your user is using for the first time with the corresponding permission request. It doesn't make much sense to ask a user for access to the camera roll when they're trying to locate their nearest gas station. Periscope, for example, requests permission to send notifications just after the user selects their first few people to follow. It utilizes some pretty concise and informative context messaging as well.

Provide Context for Your App’s Feature

Once you've identified the best times to prompt your users for permissions, you need to further prime users by providing additional context. This context explains what you're about to ask for, why you're asking for it, and explains the benefits for the user to approve the request. For example, our customer Leap explains exactly why the user should permit the app to use their calendar.

Leap uses your iOS calendar to find open times to meet with your matches. It works best when your calendar is up to date. No one else can see your calendar.

Also keep in mind that some audiences will need more convincing to approve the request than others. For example, there’s a big difference between a financial app that may store personal information and a social app geared toward teenagers. Those using the financial app may need additional messaging that explains how their information will be kept private and secure, while those installing the social app for the first time may not care. Leap as a dating app is also upfront about who can see a user's calendar, addressing what most dating app users would probably consider a key concern.

Think About Tone, Language, and Messaging

Timing and context are crucial for priming the user, but the way you communicate the request is just as important. Jakob Nielsen’s 10 Usability Heuristics suggest that one of the fundamentals of usability is using language that matches the user’s language and wording that your target audience is familiar with. Your permission request should follow your audience's common conversational conventions, pacing, and flow. The tone and wording you use in your permission request should also mirror the tone and wording you use throughout the app. This should be based off the extensive user research you conducted in the early stages of app creation. If your app is informal and fun, make your permission request the same. Quartz does that really well. The user permissions have the exact same informal tone in the same text conversation that the user will interact with throughout the app.

The way you talk to and interact with your users is important to building and gaining trust from them. Tone, language, and messaging is how you show users that the app is meant for them and will meet all their expectations. Properly styled permission requests go beyond just convincing a user to approve access to a series of dialogues. They take the user a step closer to making that user feel like the app matches their own digital identity or lifestyle. Connecting with users in this way is integral to the success of an app, something we talk about more in depth in our article about what app design looks like in 2016.

What if My User Denies the Permission Request?

The reason we place so much emphasis on making sure our timing, context, and messaging is on point for permission requests is because it's much more difficult to guide the user through the manual approval of these integral settings. If the user declines access, we can't prompt them with a permission request again. Oftentimes if a user declines permission requests, they become frustrated when the app doesn't work as they expect and delete it from their device.

While iOS does not currently provide a way to re-prompt a permission request once denied, we can instruct users that we need a service enabled and how to go about doing so. Also, it’s now possible to deep link to an app’s permissions settings. Instagram and other apps do this to try to simplify the manual approval process for users. Instead of just opening an overlay that describes all the steps the user must take to go into their settings, find the app, and toggle the appropriate switches on, Instagram provides a shortcut to the app in the device's settings. This way the user's task is shortened and simplified considerably. Still, it's not ideal.

TimeShot, mentioned above, again uses PermissionScope to add another layer of reliability to permissions. If a user disables the camera or camera roll permissions, PermissionScope catches that change and prompts the user to re-enable it. It's simple to add and helps prevent any edge cases where users only experience part of the app's full functionality.

Concluding Note

Many iOS apps today rely on at least one system service, meaning the average app user is confronted with at least one permission request every time they download an app. We expect that eventually this approval behavior will become almost second nature to users. At the same time, people are more aware than ever, especially within certain demographics, about how their personal information is used. Until there's an easier way to guide users through a complex process that requires explicit approval, focus on these three key considerations to make sure you give users every chance to connect and engage with your app.

Megan is a tea-loving user experience designer focused on making apps simple and intuitive to use. She has a knack for naming pets and identifying UX patterns.

You made it this far so...