This depends on how the app implements notifications, and which mechanism is used to disable them. I know FCM/Android, not APNS/iOS, so here's a breakdown:
1. The app registers a push token with their backend. This can happen without granting notification permissions, and without notifying the user. So the backend is free to start sending push messages immediately after registration, which is typically done on the first app launch.
2. The controls available in Android's per-app notification settings have nothing to do with push messaging. These allow the user to limit or change how the app displays notifications, regardless of the reason the app is displaying them. Some apps have additional options to disable push messages, but that preference must be communicated to the app's backend to prevent the backend from sending pushes in the first place. Some apps may consider Android's notification settings to determine this preference, but it's extra work to do so.
The concepts of "push messaging" and "notifications" are often used interchangeably, but at least on Android these are separate systems that are tied together with client code. The push messages may also contain notification data, and the official FCM client will display these automatically, so this confusion is understandable.
I’m no expert but in my experience developing mobile applications & push notifications, I’ve only registered a device for notifications (and subsequently sent notifications) if the user opted in. Based on my own experience, I would say if you didn’t enable notifications for a particular service or app, they don’t get sent.
Dunno how it is now but it used to be that Apple would tell you which push tokens (recipients) were rejected (app uninstalled, push disabled for your app, or you stored a bad token to begin with) and you were supposed to stop sending to them, with the implication that Apple would get upset with you if you kept sending to rejecting tokens for too long.
This depends on how the app implements notifications, and which mechanism is used to disable them. I know FCM/Android, not APNS/iOS, so here's a breakdown:
1. The app registers a push token with their backend. This can happen without granting notification permissions, and without notifying the user. So the backend is free to start sending push messages immediately after registration, which is typically done on the first app launch.
2. The controls available in Android's per-app notification settings have nothing to do with push messaging. These allow the user to limit or change how the app displays notifications, regardless of the reason the app is displaying them. Some apps have additional options to disable push messages, but that preference must be communicated to the app's backend to prevent the backend from sending pushes in the first place. Some apps may consider Android's notification settings to determine this preference, but it's extra work to do so.
The concepts of "push messaging" and "notifications" are often used interchangeably, but at least on Android these are separate systems that are tied together with client code. The push messages may also contain notification data, and the official FCM client will display these automatically, so this confusion is understandable.
I’m no expert but in my experience developing mobile applications & push notifications, I’ve only registered a device for notifications (and subsequently sent notifications) if the user opted in. Based on my own experience, I would say if you didn’t enable notifications for a particular service or app, they don’t get sent.
The app developer will still send them to Apple / Google though so the data will still be available to snoop on.
Dunno how it is now but it used to be that Apple would tell you which push tokens (recipients) were rejected (app uninstalled, push disabled for your app, or you stored a bad token to begin with) and you were supposed to stop sending to them, with the implication that Apple would get upset with you if you kept sending to rejecting tokens for too long.