Asking your users for permission to use their location or send them notifications is a process that has to be done both on iOS and recent versions of Android. This guide explains:
- Why the opt-in is needed in the first place
- How it works on iOS and how it will change on iOS11
- How it works on Android
- How to ask for permission without surprising your users and in the end getting a higher opt-in rate.
Why should you explain to your users why they need to opt-in
Mobile devices are able to collect a lot of data about their surroundings. This information includes the location of the device. However, nowadays’ mobile operations limit what apps can do with this information. The most important reason to do so is to protect the privacy of the user. Therefore, it is important to explain to the user why granting permission to the app, will be beneficial to the user.
Notifications can distract a user, even when he is not using his mobile device at that time. Therefore, this functionality is also locked behind a permission. This is why it’s equally important for this permission to explain what benefit it would bring. Otherwise, users won’t know what they say yes to.
FOR PLOT PROJECTS CUSTOMERS:
The Plot Projects SDK requires two permissions. It needs permission to send notifications and it needs permission to use the location of the device. The SDK functionality will be limited a lot when the “Always” location permission isn’t granted. The library can no longer run in the background to update geofences and send notifications. The “When in use” permission gives quite extensive functionality while the app is in use, but that doesn’t cut it for us. Therefore, it is import to get the user to the “Always” permission. Without the notification permission you can still run Plot Projects data campaigns (like Attribution Campaigns).
iOS opt-in dialog
iOS makes a distinction between the location permission “When the app is in use” and the “Always” permission. The “When in use” authorization only grants the app access to the location of the device when the app is in the foreground, or when continuing a session started in the foreground. When continuing a foreground session, a clear notice is shown to the user that the app continues to use the location. When the “Always” permission is granted, the app always has access to the location, for example to do geofencing or listen to significant location changes. The “Always” permission unlocks more use cases, but if your app doesn’t need those, then asking for the “When in use” is enough.
You can request the permission for the always authorization with the following method:
The permission for when in use can be requested with this method:
It is required to specify a rationale why the permission is requested. You can do so in the plist file of your app. If the rationale is missing, the permission authorization dialog isn’t shown.
It is possible to ask the user to upgrade from the “When In Use” authorization to the “Always” permission using these methods. When the user answers negative to these opt-in requests, the dialogs won’t be shown again in the future for this app.
FOR PLOT PROJECTS CUSTOMERS:
The Plot Projects SDK will ask by default for the permissions straight when it starts. You can disable this functionality by setting the “automaticallyAskLocationPermission” and the “automaticallyAskNotificationPermission” properties to false in the plotconfig.json. This allows you to pick a better time to ask for these permissions.
In iOS 11, Apple will change the look of the location services permission dialogs. When asking for the “Always” permission, while having no location permission yet, it will now also show the “When In Use” option.
Our expectation is that this new way of asking for permissions might decrease the opt-in rate for the “Always” permission. We here at Plot Projects need this permission to send location based push messages.
But when asking for the “When in use” permission first, it is still possible to upgrade this later to the “Always” permission with another permission request. If you’re asking for the “Always” permission straight away, the user gets the option to pick the “Only While Using the App” as well. If the user decides just to grant the “When In Use” authorization at that point, then you cannot upgrade via an opt-in dialog again later. In that case you cannot request the dialog again. Therefore, by splitting this in two questions, chances are higher you end up with the “Always” permission.
You can change the rationale message that is shown on this new opt-in dialog by specifying in your app’s plist file the NSLocationAlwaysAndWhenInUseUsageDescription and NSLocationWhenInUseUsageDescription keys with string values explaining to the user why the app needs this.
However, it is still possible for the user to change their mind via the iOS Settings app. If they allowed it at first, they could still revoke their authorization later. If they denied it, they could still allow it via the iOS Settings at a later point if they change their mind .
Starting from Marshmallow, Android has a runtime permission system too. For certain actions, for example accessing the location of the device, the user has to opt-in first.
You can request permissions with the ActivityCompat.requestPermissions() method. If the user decides to deny you the permission, then you can, in contrast to iOS, ask again later by calling the method again. When it isn’t the first time you ask, the option “Ask never again” is added to the dialog. If the user chooses that option, the only way to change the permission later is for a user to go to the Android Settings app.
For all the operating system versions before Android Marshmallow, the user has to confirm all the permissions when installing the app. It isn’t possible to opt-out from a specific permission. Read more about permissions on Android in the blogpost Dangerous Permissions on Android Marshmallow.
FOR PLOT PROJECTS CUSTOMERS:
The Plot Projects SDK will ask by default for the location services permission straight when it starts, just like on iOS. You can disable this functionality by setting the “automaticallyAskLocationPermission” property to false in the plotconfig.json. This allows you to pick a better time to ask for this permission.
Opt-in priming: How to increase your permission opt-in rate with an explain screen
When you show the permission screen straight as the app just appears on the screen for the first time, the user probably will be overwhelmed. Why does this app, which I haven’t had the chance to try, want to use my location and show me notifications? Then a higher number of persons may choose for “Deny”. What can you do about this?
To increase the percentage of users allowing location services and notifications, we can prime (or prepare) users for the dialogs. We can create screens explaining why enabling location services or allowing receiving notifications benefit the user. On this screen users can find two buttons. One button to allow location services, the other one to ignore the request.
Another advantage of asking this yourself is that you have another chance to do so if the user decides to not allow your request. If the user says no in your priming dialog, you can decide not to show him the permission dialog at all at this stage and try again later when the user has a better feeling of the value of your app. If the user says no the permission dialog on iOS, or selects the “never again” option on Android, there is no way you can ask him for a permission again and your only option would be to guide the user to the settings screen. The chances of that being successful are very low.
When your app requires the “Always” location permission, it’s especially important to prime your user. To make it as smooth as possible for your user, you could do it in several steps. You could first ask your users for the “When In Use” permission. If the user decides to give this permission, only then or at a later time should you show another priming screen to explain the benefit the “Always” authorization brings. This way you prevent users from selecting the “When in use” option at the first dialog, without having a proper chance to explain what the app does.
Now you know why the location services plugin is hidden behind an opt-in and how to show the opt-in dialog on both iOS and Android, including what will change in iOS11. We hope that the tips and best practices we’ve shared with you will help you improve your opt-in rates, and make sure your users get the most out of your app.