Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
The way iOS handles notifications has been bothering me for a while now. I am not 100% sure I have a correct understanding of how it all works, so please, if you (especially developers) can step in, that'd be great. But assuming my understanding is correct, I'll go into explaining how it works and what I think the problem is.

Apps can have push notifications, which are sent to your device remotely from the app provider via the Apple Push Notification Service. An app like Facebook might send a push notification if someone comments on your status. In order for an app to send push notifications, it must have permission from you. There is a system dialog asking for this permission. You are not prompted again after this; your decision is final.

Apps can also have local notifications. These aren't sent remotely but scheduled locally. A 3rd party Alarm app might schedule a notification to act as your alarm alert. Local notifications don't need permission.

The way the display of both types of notification can be configured is via the Settings > Notifications screen. Here you can choose to hide them completely (no alerts, badges, noises), or make them visible again, or alter the way they display, etc.

Here's the problem though. I'm pretty sure these settings are to configure how the notification is displayed, if you're getting notifications in the first place.

If you disable push notifications:

a) The app can still schedule local notifications.
b) No amount of fiddling with notification settings will enable push notifications again.

I think this is all a bit confusing. If you decline push notifications for a new app, but a little while later you decide you like the app and want push notifications, aren't you sort of stuck? Now, there is a work around I haven't mentioned. If you remove an app and then wait a day before reinstalling it (or advance your system clock by a day), you'll be prompted with the push notification permission dialog. But I don't think this is very user friendly. For one thing, this isn't stressed in the permission dialog.

I also think it's a bit confusing that push notifications require permission but local notifications don't. I might be wrong, but I think when the average user sees the push notification permission dialog, they think it's simply asking if they want any sort of notification. But currently, if you select no, you can of still receive local notifications and notification display settings are not necessarily all set to off.

I think there are a few thoughts, ideas and solutions to all this, some of which may be complementary, some should be taken on their own:

1) Stress the importance of the permission dialog.
2) A push notification toggle in the each app's Notification settings so your decision can be changed later.
3) Make the permission dialog applicable to both types of notification, i.e. you decline both types or accept both types. Does the user really need to know how any of the app's notifications are delivered to them? Ideally the app should provide clear options to enabled/disabled certain individual notifications it can send.
4) Get rid of the permission dialog completely. It's 2014, these phones are designed to be connected, and what are the privacy concerns? Obviously allow the notification visibility to be configured as normal through the OS. And ideally an app might let you turn them off properly. But they will always have permission to send them in future, without you having to play around with a permission toggle.

Hope I made myself clear! If I'm making any sort of sense then I might send this to Apple, but I'd like to discuss here first.
 

Merkie

macrumors 68020
Oct 23, 2008
2,119
734
I think your understanding of (push) notifications is incorrect.
The way iOS handles notifications has been bothering me for a while now. I am not 100% sure I have a correct understanding of how it all works, so please, if you (especially developers) can step in, that'd be great. But assuming my understanding is correct, I'll go into explaining how it works and what I think the problem is.

Apps can have push notifications, which are sent to your device remotely from the app provider via the Apple Push Notification Service. An app like Facebook might send a push notification if someone comments on your status. In order for an app to send push notifications, it must have permission from you. There is a system dialog asking for this permission. You are not prompted again after this; your decision is final.
This is not true. You can enable notifications by going into Settings > Notifications.

Apps can also have local notifications. These aren't sent remotely but scheduled locally. A 3rd party Alarm app might schedule a notification to act as your alarm alert. Local notifications don't need permission.
Not true either. Notifications for an app are either enabled or not, it doesn't matter whether they are push notifications or local notifications.

The way the display of both types of notification can be configured is via the Settings > Notifications screen. Here you can choose to hide them completely (no alerts, badges, noises), or make them visible again, or alter the way they display, etc.

Here's the problem though. I'm pretty sure these settings are to configure how the notification is displayed, if you're getting notifications in the first place.

If you disable push notifications:

a) The app can still schedule local notifications.
No.
b) No amount of fiddling with notification settings will enable push notifications again.
Again, no. Just enable notifications in the Settings app and you'll receive notifications.

I think this is all a bit confusing. If you decline push notifications for a new app, but a little while later you decide you like the app and want push notifications, aren't you sort of stuck? Now, there is a work around I haven't mentioned. If you remove an app and then wait a day before reinstalling it (or advance your system clock by a day), you'll be prompted with the push notification permission dialog. But I don't think this is very user friendly. For one thing, this isn't stressed in the permission dialog.

I also think it's a bit confusing that push notifications require permission but local notifications don't. I might be wrong, but I think when the average user sees the push notification permission dialog, they think it's simply asking if they want any sort of notification. But currently, if you select no, you can of still receive local notifications and notification display settings are not necessarily all set to off.

I think there are a few thoughts, ideas and solutions to all this, some of which may be complementary, some should be taken on their own:

1) Stress the importance of the permission dialog.
2) A push notification toggle in the each app's Notification settings so your decision can be changed later.
3) Make the permission dialog applicable to both types of notification, i.e. you decline both types or accept both types. Does the user really need to know how any of the app's notifications are delivered to them? Ideally the app should provide clear options to enabled/disabled certain individual notifications it can send.
4) Get rid of the permission dialog completely. It's 2014, these phones are designed to be connected, and what are the privacy concerns? Obviously allow the notification visibility to be configured as normal through the OS. And ideally an app might let you turn them off properly. But they will always have permission to send them in future, without you having to play around with a permission toggle.

Hope I made myself clear! If I'm making any sort of sense then I might send this to Apple, but I'd like to discuss here first.
This is all very much incorrect. Notice how the Notifications section in the Settings app shows "Notifications" and not "Push notifications". You either enable notifications or you don't, it's not possible to distinguish between local and push notifications.
 

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
I think your understanding of (push) notifications is incorrect.This is not true. You can enable notifications by going into Settings > Notifications.

Where? I incorrectly referred to Settings > Notifications earlier. It's actually Settings > Notification Centre. I don't see any option to enable push notifications, only to change how notifications (both push and local) appear.

Not true either. Notifications for an app are either enabled or not, it doesn't matter whether they are push notifications or local notifications.
Local notifications don't require permission, source: http://stackoverflow.com/questions/16048837/do-local-notifications-need-user-permission-on-ios

This is all very much incorrect. Notice how the Notifications section in the Settings app shows "Notifications" and not "Push notifications". You either enable notifications or you don't, it's not possible to distinguish between local and push notifications.

Yes, I know these settings control both local and push notifications. However my whole problem is that they only control the way they are displayed. You can't control whether you receive Push notifications from here, unless you can show me how exactly. so e.g. if an app is capable of both push and local notifications, but i declined permission for push notifications, then these settings really only control how local notifications appear. yes, technically it controls how push notifications appear too, but i'll never get any push notifications because it doesn't have permission.

Source on the dialog only appearing once: http://stackoverflow.com/questions/...able-push-notifications-after-initial-decline

Source on method to allow push after initially declining: http://stackoverflow.com/questions/2438400/reset-push-notification-settings-for-app

user experience: https://forums.macrumors.com/threads/1329923/
 
Last edited:

C DM

macrumors Sandy Bridge
Oct 17, 2011
51,392
19,458
Is that really how it still works now in iOS 7 where that initial dialog is the only place where you get to make a choice and you can't change it later? That doesn't really seem right on any level.
 

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
Is that really how it still works now in iOS 7 where that initial dialog is the only place where you get to make a choice and you can't change it later? That doesn't really seem right on any level.

Pretty sure this is still the case. Tbh I have gone mainly from others experiences and developers input, it's not something that has really affected me, but knowing this problem is there really bothers me for some reason. For a long time I have been declining push on new apps I'm just trying out. It bothers me that I might have to do an uninstall/wait a day workaround if I decide I want push later. And I'm concerned for unexperienced users who will be caught out by this.

The only thing I have casually tested this on is the Gmail app. I never use it, and I probably didn't allow push when I installed it. Yesterday I tried enabling all the notification settings (alert, badge, sound, notification centre, lock screen) but didn't get any notification when I got a new email. But it's hard to be sure there weren't just general problems with notifications at that time.

To test it properly you need to find an app you can easily trigger push notifications with, install it, allow push, ensure notification display options are on, check you get a notification, then uninstall, wait a day/advance clock, reinstall, don't allow push, make sure all notification display options are on, check if you get a notification...

Maybe when I have the energy!
 

matttye

macrumors 601
Mar 25, 2009
4,957
32
Lincoln, England
The logical conclusion is that if you change the alert type from "none" to "badges" or "banners," it will enable notifications.

Edit:

Sorry, just read your post #5.

I tried it with Gmail and I too didn't get notifications. I don't usually use Gmail so I'm not sure whether it usually works or not. I'll try installing it again on Sunday and I will actually accept the push notification request, then I'll see if they work.
 
Last edited:

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
The logical conclusion is that if you change the alert type from "none" to "badges" or "banners," it will enable notifications.

Edit:

Sorry, just read your post #5.

Why is that the logical conclusion? It's still messy and confusing, even if that's how it worked. One might assume after denying permission for push notifications that these options were just to control appearance of local notifications (that don't require permission)

The concept of having a banner or alert is separate from that of having a push notification. I might want a sound and nothing else, for example. And if you have allowed push notifications and the app uses them, you can indeed configure them like this. You can turn off banner and alert without turning off push notifications.
 

matttye

macrumors 601
Mar 25, 2009
4,957
32
Lincoln, England
Why is that the logical conclusion? It's still messy and confusing, even if that's how it worked. One might assume after denying permission for push notifications that these options were just to control appearance of local notifications (that don't require permission)

You are making a distinction between local and push notifications but the OS doesn't. Notifications are on or off. They're not half on or half off. They're simply on or off.

When you say no to the push notifications option, the OS sets the option within notification centre's settings to "None" for that app. Changing it to "Badges" or "Banners" is the logical way to enable a notification for that app. It makes perfect sense. I'm not sure why it doesn't seem to be working, but that's definitely how it should work.
 

sflomenb

macrumors 6502a
Jul 22, 2011
915
132
You are making a distinction between local and push notifications but the OS doesn't. Notifications are on or off. They're not half on or half off. They're simply on or off.

When you say no to the push notifications option, the OS sets the option within notification centre's settings to "None" for that app. Changing it to "Badges" or "Banners" is the logical way to enable a notification for that app. It makes perfect sense. I'm not sure why it doesn't seem to be working, but that's definitely how it should work.

Yes, this is how I understand it as well.
 

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
You are making a distinction between local and push notifications but the OS doesn't. Notifications are on or off. They're not half on or half off. They're simply on or off.
I disagree, and have gone to some lengths to explain why. The simple fact is that local notifications don't require user permission, but push notifications do. Therefore it's quite obvious the OS does make a distinction, and that it's quite possible for an app to schedule local notifications if it doesn't have permission to send push notifications.

When you say no to the push notifications option, the OS sets the option within notification centre's settings to "None" for that app. Changing it to "Badges" or "Banners" is the logical way to enable a notification for that app. It makes perfect sense. I'm not sure why it doesn't seem to be working, but that's definitely how it should work.

Let me try explaining one more time to see if you still agree. I know I said I was ready for someone to tell me I was completely wrong, but tbh I don't have great faith in anyone who's replied yet! Sounds egotistical, sorry. Convince me I'm talking nonsense :D

Here goes...

I understand that no distinction is made between local and push notifications in Settings > Notification Centre. All the options here are to control how both types of notification appear, local and push. I completely get that.

But imagine an app, App A, that doesn't do any push notifications. App A only does local notifications (Note: it can schedule local notifications without permission. No dialog is brought up). So, in this case, then, I might say (as futile as it may seem at this point) that the notification display settings for App A in Settings > Notification Centre only really control how local notifications are displayed, including completely hiding them (whether this actually turns them off I'm not sure. I'm completely happy with possibility that something is still going on behind the scenes but nothing is appearing to the user. But I digress...).

Yes, technically the OS makes no distinction on this screen, and yes, technically these settings for App A do control the display of push notifications too, if the app actually gave you push notifications. But the app never does push notifications, so the only possible observable effect is the effect these settings have on local notifications. With me so far?

Next, consider App B. App B does both push and local notifications. When it tried to register push notifications, the user is presented with the following dialog:
"App B" Would Like to Send You Push Notifications.
...
Don't Allow | OK

If the user taps 'Don't Allow' then the app publisher can't send push notifications. What I am saying is that for all intents and purposes, App B is very much like App A, in that it only does local notifications. The options in Settings > Notification Centre can only control the notifications the app actually throws up which can only ever be local notifications.

The crux of my point is that none of the options for each app within Settings > Notification Centre can actually give the app publisher permission to register push notifications for the device. They only control how notifications will appear if they are remotely pushed or locally scheduled to occur in the first place. If push was never allowed, they will never get the push notifications, so these display settings never affect push notifications. That's what I'm saying! Badly designed imo!

The only way for the user to get push notifications after initially declining is to uninstall the app and wait a day/advance the clock, then reinstall. Then the dialog will be shown again, and if the user selects OK, the app can register the device for push notifications. This is not a straightforward thing, it requires security credentials, tokens, registering on external Apple servers etc. This is why they are distinct from local notifications, require permission, etc.

This is based on so many user experiences on the internet

From my first post again, here are a few ideas, either individual or in conjunction with other points, to address the issue

1) Stress the importance of [getting it right on the first time] on the permission dialog.
2) A push notification toggle in the each app's Notification settings so your decision can be changed later.
3) Make the permission dialog applicable to both types of notification, i.e. you decline both types or accept both types. Does the user really need to know how any of the app's notifications are delivered to them? Ideally the app should provide clear options to enabled/disabled certain individual notifications it can send.
4) Get rid of the permission dialog completely. It's 2014, these phones are designed to be connected, and what are the privacy concerns? Obviously allow the notification visibility to be configured as normal through the OS. And ideally an app might let you turn them off properly. But they will always have permission to send them in future, without you having to play around with a permission toggle.
 
Last edited:

matttye

macrumors 601
Mar 25, 2009
4,957
32
Lincoln, England
I disagree, and have gone to some lengths to explain why. The simple fact is that local notifications don't require user permission, but push notifications do. Therefore it's quite obvious the OS does make a distinction, and that it's quite possible for an app to schedule local notifications if it doesn't have permission to send push notifications.



Let me try explaining one more time to see if you still agree. I know I said I was ready for someone to tell me I was completely wrong, but tbh I don't have great faith in anyone who's replied yet! Sounds egotistical, sorry. Convince me I'm talking nonsense :D

Here goes...

I understand that no distinction is made between local and push notifications in Settings > Notification Centre. All the options here are to control how both types of notification appear, local and push. I completely get that.

But imagine an app, App A, that doesn't do any push notifications. App A only does local notifications (Note: it can schedule local notifications without permission. No dialog is brought up). So, in this case, then, I might say (as futile as it may seem at this point) that the notification display settings for App A in Settings > Notification Centre only really control how local notifications are displayed, including completely hiding them (whether this actually turns them off I'm not sure. I'm completely happy with possibility that something is still going on behind the scenes but nothing is appearing to the user. But I digress...).

Yes, technically the OS makes no distinction on this screen, and yes, technically these settings for App A do control the display of push notifications too, if the app actually gave you push notifications. But the app never does push notifications, so the only possible observable effect is the effect these settings have on local notifications. With me so far?

Next, consider App B. App B does both push and local notifications. When it tried to register push notifications, the user is presented with the following dialog:


If the user taps 'Don't Allow' then the app publisher can't send push notifications. What I am saying is that for all intents and purposes, App B is very much like App A, in that it only does local notifications. The options in Settings > Notification Centre can only control the notifications the app actually throws up which can only ever be local notifications.

The crux of my point is that none of the options for each app within Settings > Notification Centre can actually give the app publisher permission to register push notifications for the device. They only control how notifications will appear if they are remotely pushed or locally scheduled to occur in the first place. If push was never allowed, they will never get the push notifications, so these display settings never affect push notifications. That's what I'm saying! Badly designed imo!

The only way for the user to get push notifications after initially declining is to uninstall the app and wait a day/advance the clock, then reinstall. Then the dialog will be shown again, and if the user selects OK, the app can register the device for push notifications. This is not a straightforward thing, it requires security credentials, tokens, registering on external Apple servers etc. This is why they are distinct from local notifications, require permission, etc.

This is based on so many user experiences on the internet

From my first post again, here are a few ideas, either individual or in conjunction with other points, to address the issue

1) Stress the importance of [getting it right on the first time] on the permission dialog.
2) A push notification toggle in the each app's Notification settings so your decision can be changed later.
3) Make the permission dialog applicable to both types of notification, i.e. you decline both types or accept both types. Does the user really need to know how any of the app's notifications are delivered to them? Ideally the app should provide clear options to enabled/disabled certain individual notifications it can send.
4) Get rid of the permission dialog completely. It's 2014, these phones are designed to be connected, and what are the privacy concerns? Obviously allow the notification visibility to be configured as normal through the OS. And ideally an app might let you turn them off properly. But they will always have permission to send them in future, without you having to play around with a permission toggle.

I agree with what you've said in this post.

What I'm saying is that I think the notification centre settings are supposed to enable/disable both push and local notifications, simply because the settings app makes no distinction between push and local notifications. I think you've uncovered a bug in either the push notifications feature or Gmail app. Not sure without further testing.

Edit:

You're wrong on one thing actually, which I've only just noticed. In your App B example above, when the user taps "Don't allow" to the push notification prompt, the OS disables both push and local notifications.

I installed Gmail, tapped 'Don't allow' and then checked the settings app, and the notification option was set to "None."
 
Last edited:

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
"when the user taps "Don't allow" to the push notification prompt, the OS disables both push and local notifications."

No it doesn't, that's why I don't think it is a bug as you say, as I don't think it could possibly work how you think it should. I have declined push for apps and not all the settings are off in Notification Centre settings for the app and I get local notifications.

Just tested this with a new app, Awesome Calendar Lite. Declined push but can still schedule calendar events which trigger a notification without any intervention in Settings > Notification Cebtre.

Besides, the alert style being none for gmail doesn't mean anything. Was notification centre on? Lock screen on? I have seen apps for which push has been declined default to no alert style but notification centre and lock screen on. If I wanted push notifications to only appear in notification centre and lock screen, what would I do in this case? The settings I want are already on! These display settings do not address the fact that the app publisher doesn't have permission for push :)
 
Last edited:

C DM

macrumors Sandy Bridge
Oct 17, 2011
51,392
19,458
What's more or less illogical is that there's no way to turn on push notifications after you declined them to begin with. That is why most would assume that changing the notification settings to banner or alert (from none) would in effect be the same as originally accepting the push notifications, since it's rather hard to imagine not to have any reasonable option to change your mind after that initial prompt.
 

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
Ok I'll feed this back to Apple then, thanks.

edit: Further research has revealed that enabling some of these display settings in Settings > Notifcation Centre can reenable push - possibly. If your app already enables these display options for local notifications after you have said "Don't allow" to push (such as Awesome Calendar Lite mentioned above), you have to turn these settings to off first and then on again. Crazy.
 
Last edited:

GreyOS

macrumors 68040
Original poster
Apr 12, 2012
3,355
1,682
It's good to see in iOS 8, local notifications now have to ask for permission. Also the allow notifications toggle in settings handles both local and remote. That has made things less confusing.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.