As a user, I am very against: "No More Push Notification Permissions"
As long as I can select, I'll allow Push Notification only for one or two applications that I really want to interrupt me (e.g. some messaging client that I want to depend on -- even other messaging clients should keep quiet until I want to "chat"). All other apps should be forbidden by default to notify me of anything.
You could still disable them via the notification centre settings in Settings.app.
I think what the OP is saying is not to remove the permissions settings totally, but just to have it 'default to on'.
The way it works now is so many people have been burned by stupid apps sending useless crap that when the app launches and ask if they want to receive notifications - they just immediately say no.
I understand the problem of spam in notifications, but my question is, what's wrong with deleting an app that spams you, or not installing it in the first place if you don't trust their use of push notifications?
Why don't we err in favor of the user instead of the developer? It's bad enough that they cannot get apps from anywhere but the App Store, give them a break.
The problem is not with spammy applications, but with others that you don't need notifications at all. I don't know, new Google's Hangouts, I don't want to receive notifications, but I don't want to delete it, because I may use it sometime.
Also, you're thinking as a developer. As a developer that cares on the user, so you probably are thinking that your app will have internal notification settings, about frequency and which to notify, but in the real world it's not a standard, sadly.
I don't agree Push shouldn't need access and "– if a user doesn’t like their notificaitons, they know they can delete the app". There is some apps that I like to use, but don't want to allow to wake me at 3AM because they think something is important. The app can still work without being allowed to send pushes.
The thing is, a lot of apps can't work without push, or work a lot worse without push, and I think users aren't well equipped to decide in a few seconds.
I think you can always find a case for more granular control. Say, if iOS enabled you to control the camera access or the microphone access for each app, we could find some class of users which might benefit from it. The question is, at what price?
False analogy. The camera and microphone aren't readily available to non-running apps, whereas push notifications are. Push notifications can also interrupt other running applications.
Allowing them globally is a far greater burden on users than asking once when the app opens the first time. If your app cannot work without push it needs to fail gracefully, end of story.
I don't think it's a false analogy. I didn't not try to argue that the burden is equal, just that granular control can always come with benefits. For some apps, "failing gracefully" means not delivering a large part of the app's value, and that's a shame.
I believe that there are better ways to solve this problem, and that educating users to delete apps, and thereby educating developers to be conservative with their notifications is part of the solution.
One man's "not delivering a large part of the app's value" is another's "not pestering me outside of the hour in the evening I want to use it".
Anecdotally, there is not one single app that I have which I would like to give me push notifications, although a few I use daily would like to. You would force me and others like me to delete them? I'd switch to Android immediately.
There's already a solution for the problem. It's to inform users that your app has more functionality with push notifications on. Not asking Apple to impose policy on their users that restricts their already limited freedom with the device. What we are discussing is a UI failure on your part, not an iOS failure.
"Educating developers to be conservative" is not going to happen. You're thinking of your own app delivering value but forgetting sociopathic actors like Path who feel free to send your entire contacts list to themselves.
> The thing is, a lot of apps can't work without push, or work a lot worse without push, and I think users aren't well equipped to decide in a few seconds.
Umm, No. For me, it's an easy choice. If it's productivity app, push please. If it's a game, nope. I couldn't care less if my friend need me to visit her farm in the middle of the day, while I might enjoy the game when I'm in the john.
I even wish the local notification follow the push notification rules.
I think you're making generalised, quick calls because you've been burned by spam, which I get. Doesn't mean there aren't a ton of apps out there that would provide value with notifications but are hard to assess.
Do you have an example of such app? We keep coming up with examples of bad push notifications, yet cannot come up with examples of good ones. Genuinely curious.
Seems like a legitimate use then. How have you gathered stats to let you think that your users are vastly refusing push notifications for you to request it in iOS 7?
I use MixPanel to track permissions conversions, and they're at roughly 60%. So 40% of users assume they're going to get spammed, even though they're not.
> So 40% of users assume they're going to get spammed
That is your assumption. Not your customers'. They probably just don't need another push notification if they also got the email confirmation that the item has been shipped. Or they just prefer to not be disturbed unless it's really important matters.
Update: just had a look at your app. I understand why people don't want push notifications from it. It's not the type of app that really needs attentions like chat, phone call, meetings, email, or tasks. I'll probably use it once. or a few more times if I'm happy with the tiles first time around.
> If users feel spammed, deleting the app is a few taps away.
Are you seriously prefer people delete your app after using it once rather than have it around in case they forgot you exist? "Which app you get that pictures from again? PhotoCeramic?"
- Push notifications the question is asked up front, good enough. Later on you can ask them to turn it on for benefits, that means notifications have to be worth it. This is the only way to control spammy abusers of notifications.
- I agree 30% is high for physical goods but you'll have to raise prices on iOS. We are sharecroppers on a platform that we didn't build, they built it, it is the new normal. It's either feudal or sharecropping but that is what platforms can do and will. Smart competitors would lower their take (Play!, Amazon, Windows, BB) but they won't because it is greed and that is the new norm, just following the Apple script. Until there is competition here on the fees/take noone will budge.
- Profile photos are available in plenty of places, gravatar, facebook, g+, etc. Maybe there is a startup that wants to aggregate all these and you can easily call that service. Doesn't need to be in the OS level. It would be great if profile photos had some common standard but everyone is building walled gardens and not sharing.
Author here. Of course it occurred to me, but the problem is that users often can't predict if they want notifications or not, or how critical notifications are to the product. I'll give you a real world example from another permissions process - location.
One of the apps I work on is a neighborhood market place. It's all about seeing what people are selling around you, and requires location. The name of the app is roughly 'neighborhood', the marketing materials call it out in big letters, the permissions message clearly explains why the app needs location access. Still, people reflexively see a permissions dialogue and deny. Then the app doesn't work, and they contact support asking why.
Yeah, I did that. You need to tell users to navigate several levels of their settings app, which is a pain. Most people never touch their settings are and are put off by having to deal with it.
If you built an app knowing it NEEDS push notifications on a platform where it's optional for the user to enable/disable, you failed as a developer. The application should be able to function either way. Users deny getting their location? Ask them to input a location instead.
It's also very easy to look up the user's rough location by asking a server and doing a geoip lookup for the client ip. Much less precise (city-level accuracy), but more privacy-friendly and usually good enough to base location-aware functionality on. Works well as a fallback - which as a dev you need anyway as GPS is often not available, even with the player's permission.
An interesting drawback to the location-by-IP-address approach is that for cellular devices, IP addresses can be supremely inaccurate. For example, I have a Verizon device whose IP address places me way off in the West coast of the US even though I purchased it and reside on the East coast, 3000 miles away. The approach is pretty solid for LAN/WiFi, though.
One of the reasons Apple doesn't want to get involved in the whole physical product payments area is there are a number of additional regulatory and liability issues.
But I don't think you have to be lumbered with PayPal - there are lots of great options for taking payment for physical products through apps. Stripe even have an out of the box UI layer for iOS to handle credit card payments, and they'll only charge you 2.5%.
I admit some providers (like Stripe) are currently geographically restricted, but that's going to change in the short to mid-term. Going forward there's lots of potential outside of Apple.
>But I don't think you have to be lumbered with PayPal - there are lots of great options for taking payment for physical products through apps. Stripe even have an out of the box UI layer for iOS to handle credit card payments, and they'll only charge you 2.5%.
US only (and UK recently IIRC), so mostly useless for an international business.
Yeah. I'm not saying that Apple is the only option, but surely an Apple option is theoretically better than Stripe. Entering credit card details on a phone keyboard isn't great, no matter how well executed.
Even when having the option of using Stripe, I'm not sure I'd take it over PayPal today.
The only thing I want is great credential/auth handling, in the device. Maybe biometrics on the phone, too. 4-digit passcodes are a failure, since it's possible to try an unlimited number (bypassing the delete-on-10-failures), even with physical possession required.
If I got a bonus, it would be the ability to select overrides for internal apple apps (Mail sucks, Chrome > Safari, a phone client which supports SIP and crypto, a messages app which supports crypto) so other apps would use it, too.
Extra super bonus is iCloud inside the firewall/self hosted on OSX.
I'd wager to say that I do. I'll give you a concrete example. People order goods, and I want to send them a "Your order has shipped!" notification. People who paid for something want to know that it has shipped and is on route to them. When I give them a push notifications permissions dialogue, they assume I'm going to bomb them with promotional material. I'm not, and they're missing out on a better experience.
One workaround is to better explain what notifications are for, but I've thrown days of work at designing better notifications permissions funnels. Lovely graphics, succinct messages that explain exactly what you're going to get, and it helps a little, but not enough. People are so negatively impressed by notifications, they often almost reflexively deny permissions.
And you think allowing all pushes will fix this? I assume it will only make it worse. Not for your app, but by all the other apps that will send a million pushes.
I understand, and that's why it's tragic. I and my audience needs to suffer because other developers abuse the system. I'm calling into question whether there is not a better way.
It only does the popup after you try to activate them, yes? Why not allow the user to turn them on with a button and not use them until then? "Hey this app is a lot better with push notifications, tap this to turn them on. A dialog will appear, tap 'Allow' to get notices etc. etc."
You said elsewhere that ~40% of users assume your app will spam them, but you don't know it's not ~40% of users simply don't want push notifications even from "benevolent" applications.
If you want people to approve notifications don't just throw up a permission dialog at startup, let them use your app for a bit, and when they make an action that will cause notifications to be needed ask them then after telling them why you want to use push.
Saying "you can just delete the app" seems to be missing the point somewhat. There are many games that I enjoy playing, but I don't want them sending me a message about having a free coin while I'm trying to sleep.
I've done all of that, and it solves some of the problem, but still falls short. Ultimately, my experience is that users just aren't well equipped to decide if notifications are worth it or not. My notifications are silent (no sound), and relevant ("Your order has shipped!"), but people wouldn't know it. When they see a request for push notifications, they assume they're going to get free coin promotions, which is a shame.
I disagree. As someone who's gone back and forth between platforms several times, I much prefer the iOS system. It's more button taps for me, yes, but I find it clearer and I'm more likely to check what it's asking for. It's also more granular... I can allow access to my camera, but not to contacts for example. Android, by contrast, gives me a long list of "stuff" to accept and I have to allow access to all of it. Admittedly it has got a bit easier to check that list in the latest version of the Play Store, but it's still not ideal.
My favourite system for requesting permissions is actually Facebook's, which lies somewhere between these two - give me the full list, but let me "turn off" certain items if I want.
I think that most users aren't that well equipped to make these kind of decisions. How could they know how critical contacts or location permissions are to the product? I think users need to make a trust/don't trust call on each app, and Android does this well.
I think the iOS model works a little better because you can defer requesting permissions until you actually need them. That way the user can get a better understanding of what the app is going to do with those permissions.
A game has a feature that lets you find people playing the same game nearby you. So in the app you click a button saying "Find players nearby", then the apple dialog pops up, asking for GPS permissions. The user is way more likely to understand why the app is asking for your location.
Contrast that with the android model, where you accept the permissions at the beginning, it may not be immediately obvious as to why the app wants your location, so you'll just deny it.
Also, with the Android model, it's all or nothing, and developers can assume that if an app is installed, it has all of the requested permissions. Whereas with iPhone, the developers is forced to cater for situations where not all the permissions are allowed.
The solution to this would be to put an explanation on why your apps needs access to, e.g, the contacts in your app description. Users shouldn't blindly trust you. If you provide a reason why you need all your permissions, the user are well better "equipped" to make those decisions.
The difference is that it enables your trust/don't trust decision. An app that requires access to your location and contacts has to be more trustworthy than an app that doesn't.
"Categories" in Push notifications would help. The same as with most mailinglists. Let me check on/off what I'd like to receive and what I don't want so see. E.g. 'yes' for new functions, status and progress of the App and my order, 'no' for commercial offers and stuff.
The problem with push notifications is that they drain a lot of battery. I enabled push notifications only for the applications that I really care about, like Mailbox or Facebook Messages. I just don't want other trivial applications to drain my battery.
That's just not true (on iOS). Your phone has one connection to the (apple) server, the amount of messages send has very little influence. Only apps that run in the background (mostly location and voice) can drain your battery when not running.
As long as I can select, I'll allow Push Notification only for one or two applications that I really want to interrupt me (e.g. some messaging client that I want to depend on -- even other messaging clients should keep quiet until I want to "chat"). All other apps should be forbidden by default to notify me of anything.