Five common design patterns for iOS licensing to users

Small text, the topic is still connected with last week, summary of five kinds of applications in iOS to the user to apply for permission of the practice mode, can refer to. Enter the translation below.

For iOS apps, the user is required to request authorization when it comes to push notifications, access to photos or call cameras, geographic location, and so on. The application will take place in the app's run, not as Android did when it was installed and asked users if they agreed to the app calling certain system features. But Android is also moving closer to iOS today.

For the product designer, the biggest problem here is that iOS gives you only one chance to ask for authorization – once those impatient and rational users (most of them) refuse authorization for whatever reason, the result is either the inability to use critical functionality, Either you need to quit the app to reset the authorization to the system settings and then back to the app. So, how do you make sure that users get a one-time authorization when they first use the product? This is a challenging and somewhat interesting topic.

We have summed up the market on the common five kinds of design patterns, for everyone according to the actual situation of their products for reference.

　　1. Ask directly, then pray

Many apps will be able to ask for permission in the process of first use. It is the simplest implementation, but the most likely to be rejected (except for products that are big enough to be trusted by the user without reason), and if the user decides to authorize it, it must perform the setup process mentioned above, because the frame is the only chance to decide.

Some of the more complex apps will execute a series of authorization requests at the first load, first requiring the camera to be called, then asking if the location is allowed, and finally giving you permission to receive notification. In some cases, this simple and crude approach is also available, as mentioned earlier, when the user has enough knowledge and trust in the product. But for most products, you can't assume that even for those big names, you won't be able to 100% to ensure that users don't look wrong or have a habitual click refusal.

　　2. Inducing users

In essence, it is still a "direct question" model, but this type of app will induce the user to click "Allow" through some minor tricks when asking. The cost of implementation is not much higher than the first, but the chance of gaining authorization increases. Look at Lyft's approach:

　　3. Ask two times to prepare the user

You can also use the workaround to somehow break through the "Ask only once" limitation, such as displaying a custom "fake" dialog before a real System dialog box appears.

As shown in the figure above, the dialog box in the Zo is a completely custom UI element, and the user clicks OK before a real iOS authorization request is made. There are two benefits to this approach:

-If a user refuses authorization in a "fake" application, you will not waste the only "real" system licensing opportunity, just close the dialog box, and you can still ask for authorization in this way when the user needs to use the relevant functionality again in the future.

-"fake" dialogs are freely available in form, such as adding more teaching content or guiding elements.

The two-question scenario can be controlled according to the actual situation, such as Shazam, which combines the first opportunity with the content of the boot page before entering the actual app.

　　4. When the user to use the relevant functions and then ask

Another common pattern that is more situational is to wait until the user actually uses the functionality associated with the system to ask for authorization, for example, when the user clicks the "Current position" button, asks if the current location is allowed, or if the user is allowed to call the system camera when they enter the camera interface.

The advantage of this model is that the user is more likely to expect something to happen in the actual functional context, so the likelihood of authorization is higher.

　　5. List mode

If the app is more complex and the functionality involves more system licensing, then the list pattern is more aggressive than the one-after frame. For example, the periscope, shown in the following illustration, does this by showing the required authorization in the form of a manifest, making it feel like some sort of formal task flow, and a user clicks on a task to eject an authorization request, agreeing to authorize the task to complete.

　　If the user refuses to authorize?

No matter how hard you try, it is possible for users to refuse authorization. In this case, some apps will simply tell the user how to turn on the authorization in the iOS Setup step-by-step.

However, starting with iOS 8, app can provide deep-link in its own interface to bring users directly to the system Setup interface. The following illustration shows that once the user refuses to authorize in the Shazam, they can still click the "Go to Settings" button, one key to enter the system settings, to reopen the authorization.

Of course, this is not a model for directing the user to authorization, but it is at least a good remedy compared to the previous one.