Mobile App Permissions Best Practices: What’s New?

Mobile app permissions protect all of the sensitive information stored on a given device. These permissions should only ask for access to information that is necessary for the app to function properly. With that in mind, both Google and Apple each have best practices around app permissions. These guidelines let users decide which permissions they want to allow or revoke.

We take an in-depth look at how they each tackle mobile app permissions.

Android

Android Mobile App Permissions At a Glance

Prior to the release of Android 6.0, the operating system asked for all app permissions at installation. If users wanted to install and use a given application, they had to grant these permissions right away. While this provided developers instant access to a lot of useful information, it removed control over what permissions users granted.

In previous versions of Android, permissions were divided into several groups, based on how critical they were for using the app. Since these permissions were very common and couldn’t cause any harm, the system didn’t explicitly ask for them. Some, like access to the internet, were even granted without asking the user.

Later versions of Android brought drastic improvements around mobile app permissions.

In Android 10 for example, users could grant location access only while using the application. Android 11 introduced even more options for users like granting a single access to their location.

From Android 11 on, users have all four permission options available: allow once, only when using, deny, and allow always. All of these can be revoked in Settings at any given time. In this way, users now have more control over permissions than ever before.

While these updates are all improvements for users, they’re a bit limiting for developers — especially when an app is “invisible”.

Let’s look at an example. Google Maps shows traffic congestion to users so they can more efficiently plan out their trips. If a user has limited their location permission, Google Maps won’t always have access to their location. The app won’t be able to alert them to traffic conditions or road closures.

While this gives the user peace of mind, it changes the user experience of the app and the benefits it promises.

Android Mobile App Permissions Best Practices

If a developer needs access to something, the good practice is to first check whether they are allowed to have access. Ever since Android 6.0, a developer should know to do that. When a developer needs access to certain permissions, the operating system is the one that asks the user for permission.

Only Ask For Permission When Necessary

The best practice is to ask permission only when it is necessary and to ask only for the given permission. For example, if the user opens Viber, the app should not ask permission to access the camera straight away. Rather, it should only ask when it actually needs access like the first time the user tries to send a photo. This makes it obvious to the user why the app needs access to the camera and photos.

If the app asks to access the camera right away with no explanation as to why, it might seem irrelevant.

Explain Why You’re Asking For Permission

Another best practice is to utilize pop-up boxes that explain to the user why a particular permission is needed. These are helpful because permissions (and their effects) are not always obvious to the user.

For example, let’s say an app needs permission to connect to a device via Bluetooth. In this instance, granting permission allows for finding the user’s location. But it might be used for other things as well. That’s why the explanation box is needed.

However, the user doesn’t have much control over how the permission would be used afterward. That’s why the option “allow only once” is a good choice. It basically restricts the app from abusing the permission. If they’re using the latest version of Android, their personal information is safe and they have complete control.

Pros and Cons for Developers

The main drawback of these new permissions is that they lead to some limitations as to what can be developed.

For example, a user downloads a coupon app that alerts them to discounts at stores nearby. They pass by a store but they aren’t using the app at that moment. Since they only grant location access while using the app, it can’t show them coupons for that particular store. The developer has no way around this and it’s essentially impossible for this app to function as it’s intended.

While it’s technically possible to work around this issue, doing so disqualifies the app from the Google Play store. Google does allow exceptions to the rule in some cases.

Take RideSpot for example.

RideSpot’s main function is tracking users’ bike rides. Since users can’t actively use the app while riding a bike, the app still has access to location. This is true even if they’ve limited access to it. And since this is part of the app’s main functionality, it is allowed by the Google Play store.

There are no specific advantages for the developer, according to the new permissions requirements. The process becomes just a little bit more difficult from a technical point of view. The code is almost the same, with small changes between Android 6.0 and Android 11. The difference comes in what can theoretically be developed and what can be actually uploaded to the Google Play store.

Let’s imagine a developer wants to build a feature that displays advertisements based on location. While the developer is writing the code, nothing technical stops them from adding the feature. But during reviews, Google rejects the app from the store.

That’s the biggest con for developers, but it’s not technical in nature. There is no straightforward definition of what is a “good enough” use case scenario. The person who reviews the app for the Google Play store makes a subjective decision.

Consequently, if a developer follows permissions best practices, there shouldn’t be any difficulties with the development process. But there can still be some limitations as to what can be uploaded to the Google Play store.

Pros and Cons for Users

With the new permissions practices, the user has to go through extra steps before granting permission. This can be a bit tedious in terms of how often they’re asked for permission. Thus, the user experience might suffer.

But users also have a lot of control over what is accessed and the peace of mind that it’s safe. At the same time, the app can still get enough information to do its job.

Pop-up explanation text boxes are a special case because they can be both an advantage and a disadvantage. The drawback is that they make the process a bit longer by requiring one more action from the user. It can also be difficult to provide a detailed and readable interface of these boxes to the users.

At the same time, this is an advantage because it explains to the user why this permission is necessary.

iOS

iOS Mobile App Permissions At a Glance

Generally, the most commonly used app permissions are the ones for location, camera, microphone, contacts, pictures, calendar, and push notifications. Rarely used app permissions include the ones for Bluetooth and access to health data (e.g. user’s pulse). The user can always go to settings where they can easily access the permissions and stop them at any time.

iOS apps ask for permissions either right away at startup or the first time a user accesses a specific feature. This has always been the case with iOS. If a user installs Facebook but never uploads photos, they’ll never be asked for camera or photo gallery permissions.

The latest version, iOS 14, has an even stricter policy on photos. First, the operating system needs to provide an explanation of why it needs access when asking for access to the camera. Secondly, the user has an option to choose that only certain selected photos be accessed by the app.

The operating system occasionally asks if they want to expand access to their photo gallery. It gives the user the option to select new photos from their full gallery and add them to the limited gallery. An example of this can be seen in the Building Brave app that we developed.

In iOS 14, there are new permissions practices for location as well.

Basically, it’s divided into two types:

• Precise location: the user’s location within several meters, according to GPS
• General location: the user’s approximate location, according to the Wi-Fi signal

Furthermore, the user has complete control over:

• Which app has access to their location
• When the app has access to their location
• Which iOS system apps like Maps and Siri have access to their location

iOS 14 also introduces a brand new permission model: Local Network.

There are a lot of devices that use Local Network for file sharing, playing games, video streaming, and music streaming. Local Network should also provide an explanation as to why the app is trying to access the local network. Developers create a string for that in the code, while the user can grant or deny access to the local network.

Another fairly new permission is HomeKit — a home automation system by iOS. It is used by third-party devices like light bulbs and thermostats. Many manufacturers have apps that make setup of the device easier. These apps also require certain permissions in order to configure and control the device.

Each version of iOS presents new permission features. But that doesn’t cause any issues since most users are using the latest version of the operating system anyway. Devices up to 4 years old get updates to iOS 14. Users that aren’t using the latest version are still safe because older versions use the old permissions practices.

iOS Mobile App Permissions Best Practices

iOS best practices dictate to not ask for access to everything when the user opens the app for the first time. Yet some apps, like Voice Memo, require this practice. According to Apple, it’s bad practice for the user to open the app and immediately be asked to grant permissions.

It’s best for permissions to be prompted by the user.

This includes (but isn’t limited to) choosing an option, clicking a button, and uploading a photo. It’s bad practice for a gaming app to immediately begin searching for other players on the local network at startup. Instead, it would be better to have a button that says something like “find a game/player.” Only when the user clicks on it is a dialog box triggered.

Pros and Cons for Developers

There are a couple of advantages of the new iOS permissions for the developer. For example, say they need access to the camera and the operating system shows the dialog box to the user. The developer only needs to set such a string in the project, describing what this permission is like. They should also occasionally check whether the user has revoked permissions.

Some of the drawbacks for the developer are that the user can always revoke permissions. The developer can’t always be sure that they have access to the permissions. When developing something that requires specific permissions, the developer must ensure that the code asks for permissions only when needed.

Pros and Cons for Users

The biggest, most important advantage for users is that they have complete control over the permissions and their personal information. On the con spectrum, it can be observed that the pop-up explanation boxes can disrupt the user experience. Many users want to just use the app, they don’t care that much about messages and dialog boxes.

Furthermore, the UI of each app is different which causes further drawbacks to the user experience. When a dialog box appears, it is designed similar to the operating system which differs greatly from that of the app. There is no way for the developer to show a system dialog box within the design system of the app itself. It will always follow the design scheme of the operating system.

Android vs. iOS Mobile App Permissions

While Android and iOS now have similar approaches to permissions, there have historically been differences between the two.

In general, iOS has always been more focused on the user than Android when managing mobile app permissions. They give more control to the user, and not so much to the developer. Currently, however, the latest versions of Android and iOS have almost the same permissions practices.

Over the years, Android adapted its permissions model to more closely match Apple. In the beginning, Android asked for permissions immediately at app installation. Users were asked to grant permission to multiple things without knowing what they were agreeing to or why. It was not the best practice.

Some users would not install the app, while others would install it without reading it all. These are two extreme cases.

Today, both iOS and Android only ask for permissions when they are needed. Some apps that have access to more sensitive information (local network, photos, contacts) even follow up with users later. If the app or feature is rarely used, they ask if the user would like to continue granting access to it.

Since both iOS and Android now have similar permissions models, it is up to developers to follow the best practices. They should avoid requesting unnecessary permissions and minimize the number of times they ask for in-app permissions. It shows respect to the users by not distracting them, acting unethically, and making it easy for them to understand permissions. If treated with respect, users will respond in the same way.