Hacker News new | past | comments | ask | show | jobs | submit login
The right way to ask users for iOS permissions (techcrunch.com)
204 points by pwrfid on April 4, 2014 | hide | past | favorite | 58 comments

This is the only way that permissions should be implemented by any mobile platform. Without it, users are forced to decide at install time whether the payoff of having the app installed is worth the associated risk of granting ALL permissions the app requests. It's a hard choice to make before you've even installed the app.

Jeff Atwood describes the app-installation-headaches nicely here: http://blog.codinghorror.com/app-pocalypse-now/

No kidding. Not to mention that a lot of Android developers have the mentality to request every permission they could possibly conceive of using in the future so that the user doesn't reject a potential future update for asking for more permissions. So every single app you install nowadays seems to want access to everything and there's no way to prevent it short of canceling the app installation.

I don't really blame them either. Android will not automatically update apps that ask for additional permissions.

I suspect that a lot of users end up never updating apps like this. It makes a lot of sense for the developer to request everything that he might want upfront.

I'm probably in the minority here, but if I try to install an app and it requests any permission that I think is inappropriate for what I want to do with said app, then the app is not installed. Peroid.

And yes, I also decline to update apps that demand additional permissions. Requesting more permissions up front will not help you with this, at least not with me.

My 2c.

root your phone and install: https://github.com/M66B/XPrivacy

I just don't care as long as it's not sending texts or emails on its own. I can't see the point in caring so much.

Facebook is probably the worst offender there - but what else is new.

Yep. I would like to see it written into the rules (Android as well) that any permission that is not the core purpose of the app should be given on a "first touch" basis. Because Words With Friends does not need my GPS location ever.

Uh...unless it's connecting up with nearby players?

That's not core, though. It should be turned on when the user clicks "Nearby Games" or whatever triggers the feature.

Why only mobile platforms? This should be in desktop OS-es too.

In principle, yes. In practice, backwards compatibility makes this hard.

Apple's approach is still flawed, since if a user ever decides "No", it is next to impossible for mere mortals to figure out how to undo it.

Makes me wish Android could request some permissions at runtime.

It's painful to have a bunch of permissions in the manifest that aren't used by 100% of users, but 100% of them have to allow them if they want to install the app.

This is exactly why I have yet to install the Facebook app. I want some of its features, but not others; if I could reject certain permissions, I'd have installed it by now.

Run Cyanogenmod which includes Privacy Guard and you'll get exactly what you want.

Once upon a time I would have. But these days, I'm just sticking with the stock firmware. I haven't even rooted it! (gasp) I can live without the Facebook app.

root + https://github.com/M66B/XPrivacy is simply amazing.

This is fantastic and I wish everything did this. As an android user, I'm often at a loss as to why an app needs a certain permission, and there's simply no easy way to figure out the answer. An initial dialog that explains the feature before it is used/enabled seems like the perfect solution.

One common reason an app needs permissions is because of 3rd party metric libraries and 3rd party ad libraries. At least for games that's the #1 reason they ask for permissions the game itself doesn't need.

While I hate it my game dev friends retort that they see no negative repercussions... as in their install rates don't change perceptibly based on permissions requested. A few geeks like me might refuse to install but we're such a tiny percent of their customer base that it's not worth it for them to find alternative libraries or write their own.

You can take your privacy back by rooting and using: https://github.com/M66B/XPrivacy

Really interesting to see the iterations from obviously awful through acceptable all the way to obvious in retrospect but takes a non-obvious amount of thought and design.

This is great, more developers should think this way. When I worked on Google+ Developer Relations this summer there was no way to do incremental permissions, but it has since been added and makes Sign-In With Google way less scary for a lot of use cases.

Android needs this desperately. One of my apps has ~15% of users never updating because I added an additional permission and when you do that you can't auto-update. I wish I could just ask for it at runtime, since it's a Camera permission and I added picture-taking to my app. I'm sure 100% of users would say yes at that time.

I find I'm often surprised by the permissions an app is requesting, which turns me away from the app.

I'm an Android user, but I prefer the unix philosophy, I just want an app to do one thing and to do it well. It's hard to find apps that do that I find.

Examples that have turned me away from apps before: a filesystem viewer doesn't really need the ability to control my wifi. An ebook reader doesn't really need access to my contact list.

Part of me worries that an app could use this in a bad way as well. If an app asks a user for a permission, and the user says no, the current expectation is that they won't be asked again. However, with this pattern, the app could bother the user until they finally gave up and granted permissions. Of course, this could also backfire and cause the user to uninstall the app.

What do you mean by "this pattern"? The article lists several iterations.

With the double dialog approach, you definitely have a point. Google Maps on iOS nags me every time I open it to give it location permissions.

However, tying it to an explicit action like the end of the article means it only appears when the user tries to do something that obviously requires that permission. There's no unprompted nagging involved.

Sorry, you're right. After reading the article, the double dialog approach was the one which stuck in my mind as having a potential for abuse. The example at the end, the on demand dialog, is what I would prefer that all applications do. Unfortunately I do not believe it is possible on Android.

I've never seen an app ask for the same permission more than once. I'm pretty sure that if the user declines it the first time, all subsequent times will be automatically declined without prompting the user.

Facebook Messenger does it every time you go to the App, it's very annoying. It definitely makes me use it less. I don't think Apps should be aware if they have had permissions denied, functions should just quietly return nothing/false data.

Example: http://i.imgur.com/S4MmKo3.png

Older versions of Messenger even complained if you allowed it to send push notifications, but disabled the notification sound.

This isn't the iOS prompt, however, which can only appear once.

Google Location Services does it every time you turn on GPS on a Kitkat android phone, if you've turned their location services permission off.

That's my point. Today, if you deny a permission, you don't expect to be asked about it again. However, if this pattern of using your own dialog before the iOS dialog takes hold, I could see it being abused. The developer could continue to show their dialog as often as they'd like. Only if you said yes, would they proceed to show you the iOS dialog.

It kind of reminds me of the story I read somewhere where app developers were showing their own dialog asking you to rate their app. Only if you chose a high rating would they actually forward you to the respective app store to actually leave a review/rating. If you gave a poor rating, they would simply "eat" the response without sending you to the store.

> It kind of reminds me of the story I read somewhere where app developers were showing their own dialog asking you to rate their app. Only if you chose a high rating would they actually forward you to the respective app store to actually leave a review/rating. If you gave a poor rating, they would simply "eat" the response without sending you to the store.

A notable recent occurrence of this was Dungeon Keeper:


I'm fortunate enough to understand (I think!) what apps are doing; I've played a few games that ask for ratings in return for in-game bonuses, and I usually click the button that takes me to the app store, don't rate anything and jump back into the game.

With the double dialog approach the first dialog could repeatedly nag. They'd have to know to accept the first dialog and decline the second, and even then the first dialog would have to be explicitly programmed to stop nagging if the permissions are denied. For example, Google Maps on iOS tells me I've denied it location access every single time I open it.

Any specific reason to not allow a navigation app to have location access? Without the current location, you'd have to enter the current location manually.

Google Maps on the iPad is just a mapping facility for me and not a navigational tool.

I share the same frustration and instead deleted the app and used the website instead. Google does not need to know my home location.

The same app also asks me to logon with my Google account - persistently. There is no option to say 'stop fucking asking'. The Google Maps for iOS team is obviously a bunch of brogrammers without kids, cos if they weren't they'd realise that a common use case for an iPad is a family shared device. Hence, I don't want to login with my account, and I don't really want anyone else from my family to either.

To annoy me further the app already knows my google account name. How? I thought these iOS apps were sandboxed?

Sorry rant over. It pisses me off that I have to make a decision between privacy and convenience. Such is life.

Multiple apps published on a single ios dev account can optionally be configured with a shared keychain, that's probably how they pick up your account info.

I feel like on HN I could convincingly pretend it's something to do with distrusting Google with my data. In reality it's user incompetence.

Back in iOS6 I added a passcode to changing location service permissions on a whim of security. I promptly forgot it. Upgrading to iOS7 has added extra security measures that makes it impossible to extract the passcode from backups :(

One of my apps accesses a persons' contacts. The approach I took to this was to notify the user ahead of time that I would be asking for permission to use the app, and that we would never use the contacts for anything but in app convenience. It feels great and is very informative. Only thing is the code is a bit wiry, but I'm working on that.

I'm convinced this is the best way to do it. I was testing one of those apps that repeats what you say and they did something like this. They popped up a dialog that said, "We are going to ask for access to the Microphone. We need this so we can make the animal repeat after you." When you tapped "OK" the permission dialog popped up. Apple should really let the developer put some information like that on their permission dialog.

> Apple should really let the developer put some information like that on their permission dialog.

They do :)

See all of the NS.*UsageDescription keys listed here:


They don't on iOS.

Yes, they do. Many apps use them (including the one in the linked article, which shows customized usage descriptions in their screenshots). The documentation I linked applies to both Cocoa and Cocoa Touch, and you can see whether OS X or iOS or both supports each key based on the Platform column on the right.

That's a great approach - specifically reassuring the user that you're not going to do anything malicious with their contacts. 95% of the time, if an app requests access to my contacts, I will deny it fearing that it's going to spam them text messages like "Dav- is using ShittyFooBarApp – Click here to join them! http://spammy.co/ad9s8hu".

Very intuitive. People just need a context for permissions to make sense. I feel like this is similar to anything online. Don't ask for something right away until someone understands what the benefit of doing so entails. These rules hold true in sales, pitching, etc.

I'd be interested if anybody also analyzed the permissions for social accounts (Facebook, Twitter).

Our experience at Theneeds is kind of strange in this regard. We have the "classical" initial join page with social buttons, and we ask for permissions when the user tap one of them. Surprisingly, we realized that many users click on Facebook icon, but next they "Don't allow" permissions. This forced us to implement a web fallback to still be able to authenticate the users (without forcing them to go to the iphone settings).

Seems like a better workaround for the time being. I know from personal experience that I tend to either: a) somewhat trust the app I'm using, so I just blindly accept to get it out of the way, or b) don't trust the app at all since it's completely new to me, so I tap to deny immediately.

If you can make your users feel more comfortable about the legitimacy of your app and help them to feel more at ease with giving away those permissions, then you're doing a good job.

Pretty good article, and I've definitely noticed that it works better when you ask people at the time of usage vs on first open.

for anyone who wants apps to request permissions or the ability to deny permissions I highly recommend rooting your phone then installing XPrivacy; https://github.com/M66B/XPrivacy

Super helpful. Thanks for writing.

A modal "do-what-I-want/pester-you-later" dialog is not the right way. The right way for Vegetable Knight or what-not to ask for permissions is to give the option to say "no, and don't ever ask again," and enforce that at the system level.

Most annoying persmission is Geo-Location for apps that don't really need it.

The answer at install is always no:

"SuperApp would like to send you push-notifications"

640k ought to be enough for anyone.

Absolutes are usually bad advice. Some apps effectively use push. Many don't. With iOS' limited background modes, despite advancements in 7, sometimes you need to get the user's attention, and push is the means.

Fantastic post. This is a major problem with Android, when oftenly users are asked to grant permissions that apparently have nothing to do with the app.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact