Sounds fine with me?
Apps allowed to receive push notifications
Phone, Messages, Whatsapp, Apple Health, [brand] bank.
That concludes the list.
There is no reason any other app needs to be able to instantly ping me. Most apps are not notifying you because something matters; they are notifying you because they want your attention.
I do not need notifications about streaks, sales, recommendations, delivery updates etc. All that can wait until I choose to open the app. It is not urgent enough to justify interrupting me.
> Cross-sell, upsell, education and discovery can work on push
Push notifications should only be for transactional notifications. I don't want another inbox for junk.
Fascinating how the author openly frames the situation as the sender and receiver’s interests being opposed.
I guess it wasn't always visible, but they were intervening in some for or another since the beginning. At WhatsApp, push delay/suppression/coalescing was something we were always monitoring, and IIRC, it was part of the system since at least when I joined in 2011. If you don't work within the system, your users' messages don't get delivered timely.
And the moment I have some faith and trust an app that I deem important, I get promotional junk as a "notification".
I would really like to have notifications allowed on certain apps like parking, or health etc., but all they seem to do is abuse the trust they are given, meaning I turn them off.
So where I agree with this author is certainly that more power belongs at the user.
Classic
From the author's blog: "I do Revenue Operation, helping Marketing, Sales and Customer Success teams with data, process and technology."
I'm very unclear to me what the thesis of the article actually is. Yes, push notifications run through the vendor's servers. Yes, Apple fucked up hard by modifying the text within them - and I contend that such modification is impossible to perform automatically without unreliability becoming the norm.
The author also appears to believe that "broadcast copy" - otherwise known as Spam by those who like to write slightly more honestly - is a legitimate use of push notifications. It is manifestly not, and any app that tries will at the very least be immediately silenced. I wish I could find the tweet that put this sentiment more entertainingly than I ever could.
If App developers continue to abuse the push notification system in this way, Apple and Google will be forced to take steps to solve what becomes an end-user's problem. Yet another tragedy of the commons.
I've found that live activities on iOS helps with this quite a bit. Let's me keep notifications disabled on parking apps and DoorDash while still getting the tracking info I want in the live activity & dynamic island.
Otherwise, yeah, you just can't trust anyone to be respectful with notifications. Phone & a messages whitelist via focus modes are the only notifications I allow on my phone.
https://www.jacquescorbytuech.com/writing/what-google-yahoo-...
The next post will be highlighting the difference between the actual state of the art techniques being deployed by large tech co’s (LinkedIn and Pinterest, for example) vs what’s available via commercial marketing providers and how most marketers don’t even make the most of the tools they pay for.
> The author also appears to believe that "broadcast copy" - otherwise known as Spam by those who like to write slightly more honestly - is a legitimate use of push notifications. It is manifestly not, and any app that tries will at the very least be immediately silenced.
Cool man, but it might surprise you to find out that people knowingly opt into receiving this stuff and actually consent to it.
And let's not forget focus modes... I have them that narrow greatly my default set of notifications, so I have a 3 tiers of notifications.
It's like the complaint I used to hear all the time: "Slack ruins work for me! OMG I can't work with constant interruptions!!" That is bewildering, because if that's how you feel, you haven't tuned your setup. Slack never interrupts me, yet I am response enough to slack messages. No one has ever complained about my response time. And I'm probably the most-messaged person on our Slack.
Lately they started sending marketing messages through that channel. Now I’m sure it’s possible to turn off the marketing messages. But I bet most people don’t know and won’t change that. It’s super annoying.
is it unironically incomprehensible to you that the owner of the device should in the one who gets to decide what is and isn't spam? it's not email where you can get bombarded with shit from any random server - you can mute or uninstall an app.
When I’m focused, I don’t hear it because it’s too subtle. But when I’m not concentrating on anything, it’s more noticeable and I don’t mind the distraction.
This might not work for everyone (“YMMV” and all), but I’ve personally found it a very effective yet simple solution.
But I digress.
The article's point about leading with the fact rather than the brand point is useful. The notification payload I'm designing already leads with the concrete numbers.
One of the best apps I've bought for android is buzz kill which lets you set rules around notifications. I have cool downs on family chats and social media so it doesn't keep buzzing when things kick off, filter Amazon alerts to only "we're two stops away" and "We've delivered" messages and dismiss the rest.
I have custom buzz patterns and sounds for urgent alerts and rules that batch notifications depending what WiFi I'm on, time outs on things that don't matter after a few hours etc.
My notifications list is now way smaller and far more relevant.
Also quickest way to sort out notifications is to take your phone off silent. Hearing everything coming in, you see more when it you can then decide if the notification should make noise, or exist at all on a per app basis.
"now here's a list of how to get around that!"
I still get notifications (SMS, email, calendar, etc) but nothing pushed
So good for me.
But there's some really scary stuff in here happening to other people that I'm not even aware of.
The fact that they do not do this reveals that phone makers are sort of market makers between app makers and customers, creating an environment which, in a certain sense, is a neutral ground between these two types of "users."
> Your visibility into all of this is poor by design, and getting worse.
Great! This article is all good news, it seems.
For some android phone brands delivery reliability is like 40-50%. Some brands are better (reaching 80%, still bad) some very bad (usually the chinese brands, for some reason).
And the user has no say in this. They can't say: deliver every notification without classification. Or "allow this app to wakeup whenever it wants". Everything is babysat by the great overseer, even if you write the app yourself for yourself.
Have fun writing a telephony app that receives only 50% of calls. :D
Wow. Y’all must be much more tolerant of your time being wasted than i am. One notification from an app I didn’t need/request/expect is cause for deletion. 2-5 per week would be enough to go and rate the app 1/5 on the AppStore and actively recommend everyone I know to delete the app.
> visibility into all of this is poor by design, and getting worse.
Good! I pay Apple big money to protect me (user) from you (abusive app developer, abusive by definition since you talk about my attention as if it were your property)
And then app developers discovered that hooks like "look what you missed" work on users and so now we all have to get them in the same category.
I can’t think of a single app I want a “Discover” tab on anymore. The moment you include one is the moment there is someone trying to game it. I definitely don’t want push notifications trying to show me something new. I’m hardly lacking in distractions
(Yes I am sure somebody can give me an example of a good use of Discover but you get my point)
An intermediate seems to be trying to fix it.
Is it ideal? No. But it's the spammers who are to blame.
There's zero reason not to include it as a toggle.
How is bad summarisation good for a user, for example?
This is how taxis worked for decades before smartphones existed. You phoned for a taxi, then remained vaguely aware that it would arrive shortly.
The question is whether a single “it has arrived” notification is worth the surrounding noise: “driver accepted”, “driver is nearby”, “rate your driver”, “here’s 10% off your next ride”, and so on.
In most cases, it is not. The useful information is either already obvious (you can see the car outside) or you have re-opened the app to check where they are.
Operational and marketing notifications should never share the same permission. Until that is enforced at the OS level, I will treat them all as unnecessary spam.
The withering cry of the software engineer "just tune your setup!" This is simply not a thing that people will do.
The defaults are so, so important. They are crucial. The vast majority of people rely on the defaults to be sane. The defaults should be sane.
I do want to know when a car is arriving.
I don't want messages asking if I'm hungry.
So many apps use annoying and questionable marketing notifications that I'd say I have about 70% of app notifications disabled globally (because the app itself does not allow disabling notifications / has no granular control).
However, it seems that SOME self hosted services can directly notify you without APNS / FCM. As an example, see https://companion.home-assistant.io/docs/notifications/notif...
>an iPhone could not afford to let every installed application maintain its own background poll against a remote server. The proposal...a single persistent TLS connection from each device to Apple, over which any registered third party could deliver alerts.
I thought apps were sending notifications locally in the device. Like, if a messaging app receives a message, there's a network call for that. Then if the messaging app wants to tell the user they received a message, it can just hit a local API for that, right?
Is the pattern actually that the app makes another network call to the notification service to register the notification, which makes another network call to the device to deliver it?
So … mission accomplished then? This is pretty much how I would like it to operate.
On iOS I have to find the right setting page and then all notifications are either on or off. Doesn’t make sense.
Right now on iOS there is no way to do this. And yes, I've explicitly turned off the cash-back deals notifications in my bank app's settings and that is completely ignored.
"...a notification lives only in the notification centre, which clears, drops and summarises what passes through it and retains nothing reliably."
Your notification center reliably retains information. Something like an inbox does exist, just not in userland: https://www.forbes.com/sites/larsdaniel/2026/04/10/fbi-pulle...
[2] In December 2023 Senator Ron Wyden disclosed that the U.S. government and foreign governments had secretly compelled Google and Apple to turn over information from push notifications, including communications metadata and sometimes content. A detail that should bother any developer: app developers have no way to stop the practice if they want to send notifications on the platforms iPhones and Android rely on. Apple had been gagged from disclosing it until the program became public, after which it said it was updating its transparency reporting to detail these kinds of requests. So the architectural hypothesis isn't speculative — it's the confirmed mechanism, differing from Section 215 mainly in domain (apps vs. calls) and legal vehicle (ordinary subpoenas, FISA orders, and NSLs rather than the specific business-records theory of §215)
[1] "Its just metadata". Thanks Obama! (joking of course, no single individual is responsible for these things, it is our collective political will and its the best we can do unfortunately)
[1] https://www.youtube.com/watch?v=9iUdm0QMDM0 [2] https://epic.org/sen-wyden-reveals-government-surveillance-o...
No way!
Pun aside, it makes sense for a notification framework including a notification delivery network to be built into these mobile OSes, because the alternative (letting applications run arbitrary background services) is usually worse.
Are you hungry? Open your Uber Eats app now for 10% off.
/this message sent through PalantirFinder -- from marketing and coupons to ordnance, we deliver everything!
My phone is in do not disturb mode 24/7. If your app notifies me about something pointless, it gets deleted and I start using your website instead
I have a mail rule that moves any email with the word “unsubscribe” out of the inbox into its own tagged area. Every few days, I go in and unsubscribe to everything that’s arrived.
Whenever a retail point of sale worker asks for my details or phone number or asks me to sign up to their club, I ask if there’s a discount. Because if there’s no discount - they get no details. It’s a simple exchange; offer to pay a fair price for my details and I’ll consider it. But so far my time and details are worth more than any retailer has offered to pay.
I've been doing this for many years, and none of my friends or colleagues are aware of it, and they don't need to be. Notifications don't help you respond quickly, they just grab your attention from things YOU wanted to do.
I haven't checked Discord today yet. I haven't checked my email. Whenever I do want to know if my friends wrote me, or if I have some new bills, or if I need to follow up on something, I will open the respective app and deal with it.
I can put my phone next to me for hours and not get distracted.
For me the notification is the point, and the point of notifications to me is that they deserve my attention. Of the vanishingly few apps I install these days, almost nothing can say it deserves my attention. Even my bank doesn’t get those privileges.
In fact, Uber on Android does use these notification channels. I just have "All Promotions & Recommendation notifications" disabled, and then "Taking a ride" channel enabled.
How much time must everyone be asked to waste to “tune” a working set of applications to something reasonably sane for human beings.
Sure, what is sane for one human might not be for the next, but it’s not as if trends cannot be discerned.
How ridiculous would it be to be told “if you don’t want people constantly barging into your office, lock the door”?
Who is he kidding? The vast majority of apps have absolutely proven they can't be trusted to respect your attention. From my perspective, the more roadblocks the platforms put between unnecessary notifications and my phone, the better. And I don't think Apple or Google are some sort of heroes here, but I do believe their incentives better align with mine than the marketing department of some app I was forced to download because I bought a ticket once or something like that.
With an app configured to do notifications like this, no banner shows up at the time the app's notifications are delivered; and these notifications don't even show up visibly on the lock screen. You only see this type of notification if you choose to actively scroll down past the "timely" notifications that do get delivered onto your lock screen, to "catch up" on all your notifications.
Basically, these notifications are relegated to an "email inbox" that you can check or not check as you like. But unlike your email inbox, you can go "inbox zero" on your notification "inbox" whenever you like without worry, since notifications (unlike email) are inherently prohibited from being a critical path in an app workflow.
> Phone, Messages, Whatsapp, Apple Health, [brand] bank.
Anyone else annoyed by the fact that you can set up do-no-disturb, with exceptions for certain phone numbers, but it doesn't work for apps like WhatsApp?
Consent is more than pressing 'Allow' on a notification pop-up. It's often not even informed consent, as those pop-ups are usually a part of some onboarding flow where users are just trying to get to the value the app promises and pressing 'ok' to everything.
Even if people do indeed want notifications at the time of the ask, one doesn't really know if the message provider will wind up spamming, that's a matter of trust. And once opted-in, even if the users no longer want notifications, a lot just don't know how to turn them off. People are often incredibly accepting of sub-par experiences like this because of the friction and capability demanded of them to opt-out. My parents get tons of spam notifications that would pass your test of 'knowingly opt into receiving' but that when asked they say they do not want.
Finally there's myriad dark patterns that tons of apps use, like changing and resetting notification preferences among others.
I'd hazard a guess that observed opt-in rates far exceed users actual desires, so I wouldn't put much stock in them. I do agree that there are some people that like them tho!
Fwiw I've worked on both the delivery side (OneSignal) and developer side (Margins) so I've lived these choices and trade-offs. My believe is in terms of power dynamics, senders generally don't deserve their power to interrupt and should not possess that power. At best, they offer opportunities, which ideally are verified somehow prior to being presented to users. I'm happy that devices and ecosystems are moving in the direction of triaging and filtering sender content, as power needs to lie in the user's holistic, most pre-frontal cortex driven expression of their desired experience, and not just one moment's opt-in button they pressed.
Thank you for writing the article, good discussion points.
I used the Southwest Airlines app recently and allowed notifications so that I could find out about things like delays and gate changes (both of which happened on my trip). Less than a week later I'm getting ads for travel "deals" pushed as notifications.
Unsurprisingly, it was difficult to find the notification setting, which was on their website, not even in the app.
(I'm reminded of this every time a client want "WhatsApp support" in their (commercial) app, so they can "communicate with customers".)
But equally every user will have a different subset of apps they want notifications for.
For example shift workers need to know when they've been allocated a shift. Or when a shift has opened up (because someone scheduled failed to arrive etc.) One group of users consider this really important, another group of users treat it as spam.
But, per the rule above, unfortunately "useful notifications" can easily be subverted by marketing notifications. Yes I want to know my delivery driver is outside, no I don't want to know that you're running a special this week.
Unfortunately there's no way to solve this problem technically. Bad actors can (and definitely do) behave badly. But ultimately the system should work for "good citizens". In other words, the user should ultimately determine what they want to see of not. And if an app has "notifications on or off" as the only option then the user should ultimately determine that setting. Not Google. Not Apple.
Building society around the lowest-common-denominator just ends up sucking for everyone. We should actively promote good behavior, while allowing bad behavior to be punished. Not just banning everything "because it might be bad".
I also stopped doing store loyalty cards about 7 years ago and it's been fantastic. I actually get a lot less junk mail and spam/"legit" marketing emails. I don't have a gob of cards to sort through.
Corporations should not speak unless spoken to.
With the exception of one trying to extract currency from the other, in exchange for something of dubious value—no.
I have no audible sounds from notifications. They don't go to my phone, with few exceptions. I get no popups. Yet, I am responsive. It was trivial to set up.
Are you really installing that many apps that this is so hard?
On iOS I assume you're sol, that notification system is unhinged to my eyes.
"I want item ABC rev D with options X, Y, & Z – I do not wish to pay for undercoating"
>[salesperson looks at autist dumbfoundedly] "I'm not sure we can do that; don't even know what Y & Z are..."
"It's a valid configuration, please just do this for me."
----
Why does my state still require new car sales via a dealership model?!
[1] I know a few people whose phones constantly beep and flash numerous times a minute, and when on, the top is completely unusable because any notification dismissed is immediately replaced, obscuring those upper buttons again. I don't understand how they tolerate it.
The push notification UX is just beyond terrible and it just got worse over time as app developers tried abusing their super power of being able to interrupt the user at will and Apple and Google tried to get on top of that. The net result is something that's very mediocre for the handful of valid uses I have left for notifications. My list is similar to yours. Things like bank approvals, 2FA stuff, etc. are useful mainly as deeplinks into apps. But other than that, it's just not worth dropping whatever I'm doing and staring at my phone.
The most used apps on my Android phone (older Google pixel model) are Firefox and gmail and just a handful of other things. As a notification channel, my email inbox is actually far more useful than mobile push notifications. They are more actionable and informative. And I can individually unsubscribe them or filter them out and easily find them back. Most apps can do both and that makes the push notifications inferior and redundant.
Which makes me wonder why you have notifications for your bank and Whatsapp enabled.
If I have an account, I know what transactions are coming out of it. I was the person who owned the account.
If I have someone's number, I know if I want to see messages from them. I was the person who gave them my number.
Seems really sill that you have notifications enabled for those apps. If you care about missing something, you'd just check them anyway.
A nondeterministic, energy hungry classifier is inferior to writing a policy to define channels.
And it was awesome.
A zealous guard of your attention will occasionally block something you would like to have seen.
That being said, yes most notifications are garbage and should be blocked.
This was the biggest thing for me. Before, I was paranoid that if I turned off notifications, I'd miss something important. As though I didn't miss notifications anyway.
Getting used to regularly checking (important) things also has two wonderful side effects (at least it did for me):
* My "mental notification system" got better. Because I was less dependent on my phone doing it for me, I developed the skill more on my own. * The apps and services that I checked less and less frequently became more obvious in how unimportant they were to me altogether. I have far fewer apps and accounts now, making me MORE punctual overall.
I disagree. What the is the point of forcing everyone to use the Google Play Store (or whatever app store on iOS) if the store doesn't stop spammers?
People complain about Uber, but Lyft does the same shit. I got a promotional notification from Lyft and could not disable it without disabling the main notifications that tell me when drivers were arriving.
If app stores were useful instead of just rent-seeking, they would kick Lyft off until they stopped doing that.
And when I had an office, I closed (not locked) the door to signify I was in a focus mode. I don't get your point.
Align better for now. It will get enshittified.
I try very hard to avoid installing apps specific to a particular business or organisation. So far I have only had to install a government app and some from banks. Even those are avoidable (but it would be very inconvenient to do so).
To the extent a platform has the same assumption, its interests are aligned with mine.
To the extent a sender does not have this assumption, I want the platform to defend my attention on my behalf.
> I'm happy that devices and ecosystems are moving in the direction of triaging and filtering sender content, as power needs to lie in the user's holistic
I don't disagree necessarily, but I see it as them putting themselves in a position to act as a toll collector, which has already happened with email and web search and is only getting worse with the introduction of LLM's into both of those things.
It's a bummer this article ended up doing much better than my email one, as I think that might better position the problem in a lot of user's minds and highlight just how much surveillance is sitting on top of those free inboxes.
There’s also substantially more filtering happening in the inbox which is mostly useful from a user perspective.
Yahoo literally wrote a paper more than a decade ago showing how they can model predictive causal chains for emails they expect you to receive, as an example.
I have WhatsApp notifications enabled because it is the primary way people communicate where I live. If my elderly mother messages or calls me, it will most likely be through WhatsApp.
Both of those notifications contain genuinely important or time-sensitive information which may require action on my part.
That's the distinction between them. A person contacting me is fundamentally different from a brand attempting to engage me. Transaction alerts are fundamentally different from “your order is out for delivery”.
The criteria is not “did a thing happen”. It's whether the notification gives meaningful new information that is important or time-sensitive, and requires me to take action.
Most app notifications fail that test completely.
Some of the delay will be ordinary things like their push service fell over or is unreliable (you also get some feedback when they don't accept push messages), or their push connection runs into silent NAT timeouts on some networks. But some of it will be things like you ran into an undocumented push quota, so Blackberry users don't get timely pushes at peak, etc. On client platforms where you have reliable background execution with network connectivity, you can potentially signal connecting clients if platform push isn't working well and have them switch to persistent connections until the push service comes back. But that was never an option for iOS; it hasn't been a reasonable option for Android since at least Android 6 when Doze was introduced... and app killers before then made it hard before then; and all the other platforms are dead. Now, push really just has to work.
AFAIK, Apple has always been willing to deprioritize pushes when you send "too many", especially when there's no user interaction; or when they added silent (voip) pushes to wake up the app, they only let you have a few silent pushes if you don't post a user visible push.
For ordinary async messaging, push latency doesn't become a big deal until it hits double digit seconds. For voice/video calls, you really want pushes to be as near to real time as possible, or the caller is gone before the callee phone rings.
Spam filter push notifications.
Ideally enough spam reports for Uber Eat’s constant marketing abuse and they lose APNs access for the Bundle ID associated with the spam reports. For example.
We are partly there in spirit with App Transparency keeping track of the IPs and hostnames apps connect to.
Android has notification channels, but I'm not sure how widely it's used: https://developer.android.com/develop/ui/compose/notificatio...
it's a tradeoff. eliminating notification spam means behaving more synchronously when booking a taxi. i don't mind waiting outside for five minutes. especially if i'm not getting a random ping when i'm definitely not booking a taxi :shrugs:
Uber may have that functionality, but a surprising number of other apps don't - for example Makro, Tops, and 7/11 Thailand, three very popular Thailand retailers, use notifications for when an order is out for delivery, about to arrive, etc. But they also send constant promotion notifications every day, even with audio alerts enabled.
I get your point and see it as valid, yet to nitpick most people don't feel they have a choice.
Not answering the phone or replying to people's messages is a no-no to many, which sets them in an arms race against spammers and social apps trying to get them from all fronts. And they get frustrated by us living in no-disturb land 24/7.
I don't know it could be solved, but I feel for them.
I'd rather choose better software than let Google/Apple decide what software running on my device is allowed to do.
You are a two factor app. I should never be in a situation where there is an unexpected login I need to verify.
I know lots of apps behave badly when it comes to notifications but I'd still prefer if the apps controlled the level of notifications they sent. I could, of course, reduce that client-side, but I don't see why I'd want Google or Apple or any other intermediary see or control the notifications.
If an app behaves inappropriately, I could uninstall it. If a gatekeeper like Google or Apple prevent an app from sending me notifications, I'd have to change my OS, usually my hardware, too.
The marginal cost of each notification is so low that companies simply spam users nonstop, and their A/B tests shows that the revenue is increasing. What's being lost though is that we're getting more and more agitated with these brands and their uncapped malicious behaviors. This is also true with their UI and UX as well, they keep adding banners with incredibly small close buttons, because someone will continue with the shopping after accidently missing the tiny button, and that's an added sale, who cares about 99% of users who are fuming with dissatisfaction, what are they going to throw away their $200-300 smart home device because companies abuse them?
Then next month, you create a new notification channel for your new promotional messages because too many people opted out of the old channels. You default that new channel to opt in, to make sure the user gets their chance to experience it and share in the delight you mean to share with them.
Presumably, you continue this until you have hundreds of such toggles and presumably some kind of dedicated Toggle Engineering Department that oversees them all. Nextdoor, Meta apps, LinkedIn, and countless others all appear to be competing for the most such toggles.
My phone has been on DoNoDisturb since 2010 or so. Here's the reality: I don't check for any of those things. Delivery drivers can ring the door bell. If I'm very hungry I'll keep the app open and check where they are. I literally do not care to be notified about any of the things that apps want to notify me off.
Anyone who cares to reach me knows to ring the phone twice in case of emergency to get through DnD. Anyone else? The best time to call is text me. Or schedule a time.
As for Claude, the point of clankers is that they work in the background. The robot can wait, their infinite patience is a feature.
What if you receive notification about transaction that you didnt make? :)
The question is, will it work over Tailscale/WireGuard? I'd assume so, but I've honestly never tested local pushes as I simply haven't needed them :)
1. Uninstall the app
2. If the app is non-optional for some reason, block all notifications.
Channels are a great first level, and iOS absolutely needs to implement an Android-tier version of this.
But channels continue to be abused, even on Android. When all deterministic controls fail...
Secondly, channels are set by the developer (or platform). In an ideal world, I want to define whatever channels I care about, and turn them on/off at will.
I wrote recently about what Google, Yahoo, Microsoft, and Apple are doing to your email: how four providers stopped being transport layers and turned into active intermediaries between brands and their customers, parsing, ranking, summarising, and increasingly answering on the recipient's behalf.
The same thing is happening to push, with two companies in control instead of four. Apple and Google run the only two pipes that matter, and every notification you have ever sent has passed through one of them. Over the last five years the on-device model that now sits between delivery and your lock screen began summarising, reordering and, on some surfaces, rewriting it.
![]()
Notification summaries on Android.
Push begins as a battery problem. In June 2009 Scott Forstall stood at WWDC and made the case that an iPhone could not afford to let every installed application maintain its own background poll against a remote server. The proposal, delayed from its initial September 2008 announcement after Apple decided to restructure the underlying infrastructure for scale, was the Apple Push Notification Service, a single persistent TLS connection from each device to Apple, over which any registered third party could deliver alerts.1 APNs shipped with iPhone OS 3 on 17 June 2009. Google followed in 2010 with Cloud to Device Messaging, then Google Cloud Messaging in 2012, then Firebase Cloud Messaging in 2016.2
The channel was intermediated from the start. Every notification you send to an iPhone passes through Apple's servers; every one to an Android phone passes through Google's. The platforms have always been able to throttle, drop, log, deprioritise or refuse. For most of the channel's history they did very little of it visibly. The architecture was permissive of intervention; they simply chose not to intervene much. That restraint is what ended.
The early consumer push era between 2009 and 2017 was comparatively quiet. APNs and the various Google services delivered to whichever apps the user had installed, with limited platform-level filtering and minimal user controls beyond a single per-app on or off toggle.
Android's first significant on-device intervention was notification channels in Android 8 Oreo, August 2017.3 Before Android 8, individual notifications carried a priority level decided by the sender. After Android 8, that lever passed to the developer at the channel level and then to the user at the channel level. The developer declared a small number of channels per app (downloads, messages, promotions, and so on), each with an importance value from IMPORTANCE_NONE to IMPORTANCE_HIGH; the user could then independently mute, demote, badge-disable or fully block any channel without affecting the others.3 Once a channel's importance was set by the developer it could not be raised later. Any app targeting Android 8 had to declare channels or notifications would simply not display.
Apple introduced its own version in iOS 15 in September 2021 under different language. Focus, Scheduled Summary, and a new four-level interruption taxonomy (passive, active, time-sensitive, critical) restructured how iOS treated each push.4 Time-sensitive was the only level you could meaningfully address, and Apple was explicit, then and now, that you should not use it for marketing.4 Android made permission itself the lever in August 2022, when Android 13 turned POST_NOTIFICATIONS into a runtime permission, requiring an explicit user grant rather than the implicit opt-in that had applied since the platform's launch. Opt-in rates fell predictably: Pushwoosh's 16 million device sample showed gaming apps losing nearly a third of their opted-in base and news apps dropping 19 percent.5 Batch's 2025 benchmark, drawn from more than 800 billion messages across 10,000 apps, reported Android opt-in falling from 85 percent to 67 percent in a year and the cross-platform average settling at 61 percent.6
Every step subtracts a degree of sender control. Some of it passes to the user, and that is a good thing: a person deciding what is allowed to interrupt them is the channel working as it should. The rest passes to the platform, and that is the part that should concern a sender, because the platform's judgment is opaque, unappealable, and increasingly made by a model rather than by a setting the user chose. Over fifteen years the channel has been rebuilt around one assumption: the receiver's attention is a scarce resource the platform is obliged to defend. It defends that resource for its own reasons as much as the user's. A clean, low-fatigue notification surface protects the platform's retention and ecosystem, reduces uninstalls, and shows off its AI, so the editing is the platform guarding an asset it owns, not pure user advocacy. As a sender you are on the wrong side of that assumption, whichever way the control moved.
Email is further along, and I've told that story in full. The same intermediation has been building on push in parallel, a step behind, which makes email a reliable preview of where push is going. Push is the harder case, though: email at least gives senders some instrumentation to see it working, Postmaster Tools and deliverability dashboards, where push gives them almost none. There is no push equivalent of the inbox, either: an email persists in a place the recipient can scroll back through, search and return to, while a notification lives only in the notification centre, which clears, drops and summarises what passes through it and retains nothing reliably. Machine learning has decided inbox placement since the late 1990s, when Bayesian spam filtering moved providers off rule-based filters and onto classifiers weighing content, sender reputation and recipient engagement; authentication standards (SPF, DKIM, DMARC) layered on later as signals feeding those models rather than replacements for them. Marketers slowly learned to treat email less as a publishing act than as a request a hidden classifier grants or denies.
Gmail's tabbed inbox in 2013 sorted legitimate mail into Primary, Promotions, Social and Updates with the same kind of classifier. The Promotions tab was not the spam folder but a separate category for commercial mail the user had agreed to receive yet the model judged promotional; Apple Mail added its own categorisation in 2024. Each move pushed the line between the sender's intent and the user's experience another step away from the sender.
Mail Privacy Protection, shipping in iOS 15 in September 2021, was the visibility blow. Apple Mail began prefetching remote content through Apple-controlled proxies whether or not the user opened the message, masking the IP address and breaking the open-pixel mechanism marketers had relied on for a decade. One vendor, Omeda, watched Apple-driven open rates climb from 22.6 to 40.5 percent in six months purely from those prefetches rather than from readers.7 The open rate in its old form became unrecoverable, and click-through and downstream conversion took over as the engagement signal.
Then Yahoo and Google made deliverability itself the gate. From early 2024, any sender pushing real volume to personal inboxes has had to authenticate with SPF and DKIM, align DMARC, offer one-click unsubscribe and keep spam complaints under a low ceiling, or not reach the inbox at all; Google moved from deferrals to outright rejection in November 2025, and Microsoft published equivalent rules.8 Apple Intelligence summarisation reached Mail in October 2024, and Gmail's Gemini summaries followed.
Push has now arrived at roughly the same intermediation maturity email reached a decade earlier, with a few differences in the mechanism that cut against you. Email runs on open, federated protocols (SMTP, IMAP, and the DKIM and DMARC standards) that anyone can implement; the reading client is decoupled from the provider, so a recipient can open the same mailbox in any app; and a subscription is just an address on a list that you, the sender, hold. Push has none of that. A user's permission lives inside a specific install on a specific device, a native app or, since iOS 16.4, a home-screen web app, tied to a token (APNs or FCM) that Apple or Google can invalidate at will, and you hold no list you can take elsewhere. Web push widens who can send, with no App Store download required, but the notification still lands in the same tray under the same on-device editing, so it broadens the channel without escaping the editor. Email has DKIM signatures a receiving mailbox can check; push has no analogue, because every notification is already signed by Apple or Google's infrastructure as a condition of being delivered at all. Email gives you layout control via HTML; push gives you a small structured payload and little control over the collapsed lock-screen view beyond the platform's templates. You can supply a richer custom layout for the expanded view, a content extension on iOS, custom layouts on Android, but it renders only once the user pulls the notification open, and the collapsed text the summariser works on stays template-bound. Email lives in a queue the user opens deliberately; push interrupts.
In email, the death of the open rate should have taught marketers what an open always was: a proxy for delivery at best, never for engagement. Plenty never learned, and still read opens as engagement today. Push is heading the same way. You are losing the ability to tell whether your notification was summarised, hidden behind a Focus mode, deprioritised by an on-device model, or filed into a quiet folder.
Email's editing happens mostly in transit. Gmail's Promotions classifier, the spam filter, sender-reputation systems and bulk-sender policy enforcement all run on the provider's servers, reading the payload as it passes. Push's editing is downstream of all that. The transport is a relay, end-to-end encrypted in the case of web push, and the decisions about whether a notification is shown, summarised, deprioritised or grouped are made on the device at the display layer. The on-device model is what matters here, not the network, and its weights and signals are not public.
Apple Intelligence runs on a 3 billion parameter on-device foundation language model and a larger Parallel-Track Mixture-of-Experts server model available via Private Cloud Compute. The on-device model uses KV-cache sharing and 2-bit quantization-aware training to fit Apple's silicon; the technical report published in July 2025 describes the architecture in detail.9, 10 An earlier report from July 2024 set out how the summarisation adapter itself is trained: on a data mixture of email, message and notification payloads, with the target summaries generated synthetically by the larger server model and then filtered.11 The model is not used directly for each Apple Intelligence feature. Small LoRA-style adapters of typically tens of megabytes, dynamically loaded by the operating system, specialise the base model for specific tasks: summarisation, entity extraction, refinement, notification prioritisation among others.11 Apple's news summarisation problems in late 2024 and early 2025 were tractable to address feature-by-feature because the base model did not need replacing; the adapter for a surface could be retrained or switched off. After the BBC complained that summaries were generating false headlines, Apple disabled them for News and Entertainment in iOS 18.3, began rendering AI summaries in italics, added a per-app off switch on the lock screen, and started warning that summaries may contain errors.12 The editing is neither invisible nor permanent: where a user turns it off, their full text, which is your text, shows again. The defaults still summarise, and most people never change them, but the backlash bought senders a partial reprieve.

Google's equivalent, Gemini Nano, runs inside AICore, an Android system service introduced in Android 14 that holds the model on the system partition, shares its weights across all authorised apps, and isolates each inference request without persisting input or output data.13 AICore is governed by Android's Private Compute Core principles: restricted package binding, no direct internet access, model updates delivered through Google Play System Updates.13 Gemini Nano comes in multiple sizes, with Nano 1 for standard memory devices and Nano 2 for higher-RAM devices, each routed automatically to the device's NPU, GPU or CPU. Like Apple's adapter approach, AICore supports Low-Rank Adaptation so that individual features (Pixel Recorder summaries, notification organising, smart reply) can be specialised without retraining the base.13 On the Pixel 10 series and Samsung Galaxy S26 series, notification summaries and the Notification Organiser run on this stack; by secondary reporting the One UI summary surface is Android's own System Intelligence rather than a Samsung-specific model, though OEM AI stacks are poorly documented and shift fast, so treat the specifics as provisional.14

Gemini Nano architecture.
The editorial decision for a given notification is the product of several layers. Your app constructs a payload and submits it to APNs or FCM. The platform's infrastructure delivers it to the device, where the operating system applies any user-controlled rules first: Focus modes, Do Not Disturb schedules, channel mutings, per-app blocks. The notification then enters the platform's ranking and presentation logic. On iOS, if Notification Summaries are enabled and the notification is groupable with others from the same app or category, the operating system passes the combined text to the on-device foundation model with the summarisation adapter and replaces the original title and body with a generated line marked by a sparkle icon and italics.15 If Priority Notifications is enabled (off by default since iOS 18.4) the system applies a learned per-app ranking that can pin some alerts and demote others.16 If Reduce Interruptions Focus is active, the model evaluates whether each notification clears the user's customised importance threshold.15
Two granted patents are confirmed via Google Patents and assignee searches. Microsoft Technology Licensing LLC, US 11,340,963, granted 24 May 2022, describes improving "the clarity of information provided in automatically generated notifications ... by substituting one word in the notification with another more specific word, adding additional content ... and/or by rephrasing the content for grammatical correctness and/or clarity".17 This is the explicit ML rewriting of notifications, filed in January 2019, predating the iOS 18 controversy by years. Google LLC, US 11,609,806, describes a trained machine learning model using prior interactions between the user and the target application to decide whether and when to deliver a notification.18 Google's prioritisation work runs back further: US 8,707,201, with a priority date of 2012 and a continuation granted in 2017, describes an on-device ranking model that scores each notification, updates itself from user input, and graphically emphasises the ones it judges most important, the same shape Apple would later ship as Priority Notifications.19 The resemblance is not evidence of borrowing: several companies patented variants of ranking notifications by learned user behaviour in the same few years, which says the direction was obvious by the early 2010s, not that one vendor took it from another. Other patents in the prioritisation, summarisation, predictive-timing and cross-device-coordination cluster exist but were not positively attributable to a known platform-vendor assignee at the time of writing and have been left out rather than cited speculatively.
You have limited mechanisms to influence any of this. On iOS, UNNotificationServiceExtension lets your app code briefly mutate a delivered notification before display (decrypting payload, fetching an image, modifying text); UNNotificationContentExtension lets you define a custom UI for expanded views. Neither runs after the platform's summarisation or prioritisation steps. The apns-priority header offers a choice between 5 (delivered at a time that conserves power, for non-urgent alerts) and 10 (delivered immediately, for genuinely interactive ones). On Android, NotificationListenerService is the system-level API OEMs and accessibility apps use to read incoming notifications; you write to NotificationManager and declare channel importance, but you cannot opt out of the system's classification. The Gemini Nano stack runs after your payload is parsed. There is no API by which you can detect whether your notification was summarised, filed into the Promotions section of the Notification Organiser, suppressed by Focus, or quietly demoted by Priority Notifications.
Wearable platforms inherit this stack. Apple Watch mirrors notifications from the iPhone by default but obeys the iPhone's Focus and Summary state. From watchOS 11 the Smart Stack uses on-device signals (location, time, calendar) to surface relevant widgets; you don't target the Watch directly, only decide whether your iOS notifications mirror, via the user-facing toggle. Wear OS bridges phone notifications to a paired watch by default, with developer controls (BridgingConfig, setBridgeTag, setDismissalId) that suppress duplicates when a companion watch app is installed; you can suppress watch delivery for low-priority alerts, but you cannot force watch delivery for a notification the user has muted on the phone. The wearable is a strict subset of the phone's notification stream, with the same platform editing applied upstream and one additional filter (bridging behaviour and watch-side complications) applied downstream.
Most notifications do not prompt immediate action. People register them and carry on, and only a fraction produce an immediate switch into the app. This awareness role was first established on the desktop, in Iqbal and Horvitz's CSCW 2010 field study of Outlook alerts, and the mobile literature has confirmed and built on it since.20
Sahami Shirazi, Henze, Dingler, Pielot, Weber and Schmidt's "Large-Scale Assessment of Mobile Notifications" at CHI 2014 collected close to 200 million notifications from more than 40,000 users via an instrumented Android launcher. The paper identified the importance hierarchy users give different notification categories, with messaging notifications consistently ranked most valuable and promotional notifications consistently ranked least.21 The original empirical case for treating message-from-a-person and message-from-a-brand as different surfaces, which the Android Notification Organiser now codifies twelve years later, is in this paper.
Pielot, Church and de Oliveira's MobileHCI 2014 work "An In-Situ Study of Mobile Phone Notifications" found that users faced 63.5 notifications a day on average, mostly from messengers and email, and attended to them within minutes whether or not the phone was on silent.22 Mehrotra, Hendley and Musolesi's "PrefMiner" at UbiComp 2016 built on this with an interpretable rule-learning approach: the system extracted human-readable if-then rules from a user's interaction history and presented them for acceptance, with more than 50 percent of the generated rules accepted in deployment.23 Mehrotra, Pejovic, Vermeulen, Hendley and Musolesi's "My Phone and Me: Understanding User's Receptivity to Mobile Notifications" at CHI 2016 showed that even valuable notifications cause disruption, and that the psychological traits of the individual mediate the perceived disruption.24 Pielot and Rello's "Productive, Anxious, Lonely: 24 Hours Without Push Notifications" (arXiv 1612.02314, CHI 2017) reports a one-day notification blackout in 30 participants that made people more productive but also more anxious and less socially connected, and more than half of the participants began to disable or manage notifications more consciously after the study.25 The line from this research to shipping product is direct. Okoshi and colleagues built Attelia, a middleware that detected breakpoints in a user's phone activity and held notifications until one arrived, cutting cognitive load by 46 percent in a controlled study and 33 percent in the wild,26 and a later large-scale deployment inside the Yahoo! Japan app reported up to a 60.7 percent increase in click rate from timing alone.27 Mehrotra and Musolesi's survey of intelligent notification systems is the umbrella reference for the field.28
Localytics, before its acquisition by Upland Software in February 2020 and integration into Upland's Customer Experience Management Cloud, published findings widely cited: 52 percent of users who disable push notifications eventually churn from the app entirely; 2 to 5 notifications per week is the optimal range for most apps and exceeding it materially increases uninstalls; segmented audiences open at roughly double the rate of broadcast.29 Leanplum, now part of CleverTap, published that personalised notifications had open rates around 800 percent higher than generic broadcasts and that 90 percent of opened push notifications produce an action within an hour. CleverTap's own 2025 fintech report finds segmented campaigns averaging 16.3 percent open rate against 4.7 percent for untargeted campaigns.
These numbers are vendor self-reports and should be discounted accordingly, but the direction is consistent across vendors, methods and decades. Volume kills permission. Relevance is the only reliable lever you control. Time-of-send matters, but less than relevance. Anything that looks promotional gets classified as promotional, often correctly. Users tolerate transactional and conversational notifications at far higher volumes than promotional ones, which is why the Promotions category in Android's Notification Organiser looks set to become the centre of gravity for marketer-sent push, the way Gmail's Promotions tab did for email, though how systematically promotional push gets relegated still varies by manufacturer and is less settled than the email case.
None of this bites evenly. The editing falls hardest on broadcast and promotional push; the notifications people actually want tend to pass through untouched or amplified. A message from a person, a critical alert that overrides Focus, a Live Activity tracking a ride or a delivery, a status update on something the user set in motion, these clear the filters precisely because the user wants them, and some gain screen presence rather than lose it. Live Activities are the clearest case: an ActivityKit session renders onto the Lock Screen and Dynamic Island, a surface separate from the notification tray, so the summariser and grouping never touch it, and Android's Live Updates and ongoing notifications do the same. For genuinely live, transactional content, a ride, a delivery, a match, a timer, that is the cleanest route around the editor, with the limit that it only works for events that are actually ongoing; you cannot dress a promotion as a Live Activity. The controls are user-facing too: summaries, Focus, channels and permissions can all be switched off. The catch is that defaults govern and most people never change them, and the argument here is about marketer broadcast, which is most of what gets sent and nearly all of what gets edited.
Dekker, Baumgartner, Sumter and Ohme's 2024 Media Psychology study "Beyond the Buzz" ran a one-week randomised trial in which disabling notifications did not reduce how often people checked their phones, nor their screen time.30 People compensated by going to the apps directly. Read that as confirmation that turning down your volume rarely costs as much engagement as the opt-out rate implies, because the users who opt out often still come back to the app on their own.
Your visibility into all of this is poor by design, and getting worse.
The available metrics, in increasing order of unreliability, run sends, accepted-by-platform, delivered-to-device, displayed-on-device, opened, attributed conversion. APNs and FCM expose accepted-by-platform reliably, since your server gets a response code on submission. APNs does not provide delivery receipts the way SMTP does; the most you know is that Apple has accepted the payload and queued it.31 FCM gives you somewhat more, including a message ID and, in some cases, a delivery callback, but the line between "delivered to device" and "displayed to user" stays opaque. iOS storing only the most recent notification per app when offline means older notifications can be silently dropped before they ever reach the user.32
Lifecycle platforms (Braze, Iterable, OneSignal, Airship, CleverTap, MoEngage, Pushwoosh, Customer.io, Batch) layer their own measurement on top, exposing per-message delivery, open and click rates aggregated from the SDK in your app. The SDK records when the notification was shown, when the user tapped it, and whether the tap produced a session start. The granularity depends on whether your app declares a NotificationServiceExtension on iOS or an equivalent broadcast receiver on Android, which lets the SDK confirm receipt. Without that, "delivered" collapses back to "accepted by APNs/FCM," which inflates your apparent delivery rate relative to what users actually see.
Click-through rate, as OneSignal's own guidance documents, is conventionally taps divided by deliveries, with deliveries usually meaning "passed through FCM or APNs." That counts notifications that were never displayed, swiped away unread, dismissed silently, or hidden behind a Focus or Reduce Interruptions filter. The "confirmed delivery" metric some platforms expose is closer to the truth, since it counts notifications the SDK saw render, but it still can't tell you whether the user saw the rendered notification before dismissing it.33
Mobile measurement partners (AppsFlyer, Adjust, Branch, Singular, Kochava) attribute downstream sessions to specific push campaigns by embedding tracking links in the payload and matching them against subsequent SDK events.34 On iOS this has worked under SKAdNetwork constraints since App Tracking Transparency in April 2021, with the wrinkle that re-engagement attribution (as opposed to install attribution) doesn't require ATT and uses the IDFV or app-level identifiers instead. Re-engagement attribution is therefore one of the few measurement chains you reliably keep.
In-app analytics (Amplitude, Mixpanel, Heap, PostHog) sees the downstream session but not the upstream notification on its own. Stitching the two is a solved integration problem: pipe your push platform's send and open events into the analytics tool on a shared user identifier, through a native connector, an event stream like Braze Currents, or a reverse-ETL job, and notification, session and conversion line up, give or take the identity-resolution leaks around logged-out users and reinstalls. What that does not recover is the silent middle of the funnel: how often a delivered notification was displayed, summarised, deprioritised, suppressed by Focus or never seen. The push platform cannot tell you that either, because APNs, FCM and the operating system never report it. That middle is dark.
There is no platform-provided signal for any of the following. Whether a notification was bundled into a Notification Summary on iOS. Whether it was placed in the Promotions section of the Notification Organiser on Pixel. Whether Reduce Interruptions silenced it. Whether Priority Notifications demoted it. On iOS, whether the user swiped it off the lock screen without reading it. Whether the user is in a Focus mode that suppressed it. Whether iOS's storage limit caused it to be dropped before display. Whether Samsung's One UI 8.5 summarised it. The one place push reads better than email runs the other way: on Android a delete-intent fires when a user swipes a notification away, so a deliberate dismissal is loggable, an explicit rejection email never exposes. It is Android-only, fires only for notifications that were shown, and cannot tell a considered swipe from a clear-all, so it is a narrow win, but a real one.
You measure push in 2026 the way email marketers measure email after Mail Privacy Protection: with metrics you know sit downstream of an editing layer you can't see, calibrated against conversion data that captures only the users who acted. The notifications that produce measurable conversion are a non-random subset of the ones you sent, and the bias runs in the direction of the platform's judgment of relevance. If your engagement metrics improve over time, you might be sending better notifications, or you might be sending notifications the platform increasingly trusts, and you cannot tell the two apart from inside the dashboard. Email at least gives you Google Postmaster Tools as a partial diagnostic. Push gives you nothing equivalent.
Broadcast copy no longer survives intact. On-device summarisers compress a notification to its gist, so what comes through is the concrete fact, not the brand voice around it. Lead with the payload, the amount, the name, the time, the action, and a summary has something to keep. Bury it behind a brand-voice opener, an exclamation, an emoji or a pun, and the summary can keep the emoji and drop the meaning, or keep the wrong half. The Sahami Shirazi finding that users rank notifications by sender category and information type, not by literary quality, is the indirect backing; nobody has published a direct test of how to write for a summariser.21
Treat the title as a structured data field that happens to be written in natural language. "Your delivery is 15 minutes away" is summary-stable. "We've got great news!" is not, because it carries no fact. As a rough self-check, see whether the title still tells the user something useful when stripped to its first few words: if it does, it has a fact a summariser can keep; if it does not, it was a brand-voice signal, and the platform, the user or both will edit it out of recognition. Treat that as a habit, not a guarantee. The same principle applies to Live Activities and Live Updates: the proposition is the field (ETA, score, step count), not the brand wrapper.
The case for not abusing the time-sensitive interruption level is documented in Batch's developer guidance: "If your time-sensitive notifications are not often interacted with, iOS will prompt your users from the lock screen to let them disable time-sensitive alerts for your app".4 One tap and the level is off, per-app, from the lock screen, decided by the user. You get no equivalent appeal.
Push should carry less of the lifecycle programme. The surfaces you own inside the app, in roughly increasing order of intrusiveness, are: passive in-product cards (in a feed the user reaches deliberately, neither summarised nor blocked by Focus), persistent in-app message centres or inboxes (a permanent location the user can return to), targeted in-app messages triggered on session events (modal, slide-up or banner, shown only during an active session), and embedded messaging primitives inside the product flows themselves (placed on the screens users already visit to complete a task). None of these passes through APNs or FCM. None is touched by Apple Intelligence or Gemini Nano. None is summarised. None is suppressed by Focus. And all of them are fully visible to you: the SDK records render, dismiss and interaction events with no platform-mediated gap.
The catch is that owned surfaces only reach the active user. Someone who hasn't opened the app in fourteen days can't be reached by an in-app message; they can only be reached by push. So push becomes your channel for re-engaging dormant users and for transactional, time-sensitive alerts to active ones. The in-product surfaces become the channel for everything else: cross-sell, upsell, content discovery, education, value-add. Batch's 2025 data showed in-app messages clicking at 16.1 percent on Android and 17.9 percent on iOS for promo-code campaigns, well above push CTR.6 The same data shows the reachable in-app audience is smaller than the reachable push audience, because in-app requires a session. Push exists to bring users back into the product; once they're there, the owned surfaces take over.
Treat push and the in-product surfaces as a portfolio. The platform's editor only acts on one of them.
The on-device language model, once it's there, has uses beyond summarisation. Apple's Foundation Models framework, exposed to developers from iOS 18.4 onwards, lets any app call the same model the operating system uses, for summarisation, entity extraction, text understanding, refinement and short dialog.10, 35 Google's ML Kit GenAI APIs, sitting on top of AICore, expose summarisation, proofreading, rewriting and image description.13, 36 The model isn't a feature any more; it's infrastructure, available to any app that asks. The next step, visible in Google's "smarter, more proactive Android with Gemini Intelligence" framing and Apple's roadmap toward a more agentic Siri, is for these models to act on the user's behalf in response to your notification: open the app, complete the booking, dismiss the alert, draft the reply.37 Apple has patented a version of exactly this: a digital assistant that detects which notification you are looking at, takes a spoken instruction, and carries out the action in the app or in the notification system itself.38 The underlying capability is not speculative. Yahoo's researchers showed a decade ago that a provider can model the causal chain of messages a recipient expects, a purchase confirmation predicting a shipping notice predicting a delivery alert, and detect when the chain breaks.39 A platform that can already anticipate your next message, and already runs an on-device model over the one in front of you to summarise it, has the building blocks for handling the notification on your behalf. The acting layer is still to come, and when it ships the heavier reasoning will likely run server-side, on Apple's Private Cloud Compute or Google's cloud models, rather than wholly on the device. The plumbing for this already has names. Apple's App Intents framework lets a developer expose typed app actions to Siri and Apple Intelligence; on Android, App Actions and Gemini's emerging ability to act inside third-party apps do the equivalent.40 The implication for senders is concrete: the work is no longer only writing a notification a summariser will not mangle, but exposing the action behind it, so an agent can complete the booking or clear the alert without the user opening the app at all. The notification stops being the destination and becomes a trigger consumed by an agent, and the click-through metric that anchored ten years of push measurement loses most of its meaning.
You are negotiating with an editor you cannot see, running on a model you cannot inspect, that answers to the user rather than to you. You cannot out-shout it, and there is no appeal. Ten things follow from that.
Push, like email, was never really owned. It was just less rented than social, and the lease is being repriced in the platform's favour with every release. The senders who come through the next decade intact will not be the ones who send the most, or the cleverest. They will be the ones whose message the editor would defend if asked, because the recipient wanted it anyway, and the ones who already moved their best work to the surfaces no editor stands in front of. Write for the model you will never see. Build for the channels it cannot reach.
I just got an iPhone 17 Pro, so I look forward to seeing how Apple Intelligence's features work in progress.
Apple Developer Documentation. Registering your app with APNs (User Notifications). https://developer.apple.com/documentation/usernotifications/registering-your-app-with-apns
Google / Firebase. Firebase Cloud Messaging documentation. https://firebase.google.com/docs/cloud-messaging
Android Developers. Create and manage notification channels (importance levels IMPORTANCE_NONE to IMPORTANCE_HIGH, channels required from Android 8.0). https://developer.android.com/develop/ui/views/notifications/channels
Batch. Understanding and managing iOS 15 time-sensitive interruption level. https://help.batch.com/en/articles/5543431-understanding-and-managing-ios-15-time-sensitive-interruption-level
Pushwoosh. 2025 Android 13 Impact: Opt-In Rates and User Engagement. https://www.pushwoosh.com/blog/android-13-opt-in-rates-research/
Batch. EXCLUSIVE: The Great Push Notifications Benchmark 2025. https://batch.com/ressources/etudes/benchmark-notifications-push-crm-mobile
Omeda. The Impact of Apple's Mail Privacy Protection: 6 Months Later. https://www.omeda.com/blog/the-impact-of-apples-mail-privacy-protection-6-months-later/
Google Workspace Admin Help. Email sender guidelines and FAQ (5,000/day bulk-sender threshold, SPF/DKIM, DMARC alignment, RFC 8058 one-click unsubscribe, 0.3% spam-rate ceiling, November 2025 enforcement). https://support.google.com/a/answer/81126 ; https://support.google.com/a/answer/14229414
Apple Machine Learning Research. Introducing Apple's On-Device and Server Foundation Models. https://machinelearning.apple.com/research/introducing-apple-foundation-models
Apple Machine Learning Research / arXiv. Apple Intelligence Foundation Language Models Tech Report 2025 (arXiv 2507.13575). https://arxiv.org/abs/2507.13575
Apple Machine Learning Research / arXiv. Apple Intelligence Foundation Language Models (arXiv 2407.21075, July 2024). https://arxiv.org/abs/2407.21075
Apple's statement temporarily disabling Apple Intelligence notification summaries for News and Entertainment apps in iOS 18.3 (January 2025), alongside italic labelling of AI summaries, a per-app lock-screen toggle, and a beta "may contain errors" warning, as reported by CNBC. https://www.cnbc.com/2025/01/16/apple-disables-ai-notifications-for-news-in-its-beta-iphone-software.html
Android Developers. Gemini Nano on Android. https://developer.android.com/ai/gemini-nano
SamMobile. AI notification summaries coming to Galaxy devices with One UI 8.5 (reportedly Android System Intelligence / on-device Gemini Nano), October 2025. https://www.sammobile.com/news/one-ui-8-5-ai-notification-summaries-galaxy-devices/
Apple Support. Summarize notifications and reduce interruptions with Apple Intelligence on iPhone. https://support.apple.com/guide/iphone/summarize-notifications-reduce-interruptions-iph1fbe7d2b9/ios
Apple Newsroom. Introducing Apple Intelligence for iPhone, iPad, and Mac (Priority Notifications, summaries, Reduce Interruptions Focus), June 2024. https://www.apple.com/newsroom/2024/06/introducing-apple-intelligence-for-iphone-ipad-and-mac/
Microsoft Technology Licensing LLC. US 11,340,963 - Augmentation of notification details (granted 24 May 2022). https://patents.google.com/patent/US11340963B2/en
Google LLC. US 11,609,806 - Determining whether and when to provide notifications based on application content. USPTO. https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11609806
Google LLC. US 8,707,201 B1 - Systems and methods for prioritizing notifications on mobile devices (priority date 27 June 2012, granted 22 April 2014); continuation US 9,817,869 B2 (granted 2017). https://patents.google.com/patent/US8707201
Iqbal, S. T. and Horvitz, E. Notifications and awareness: a field study of alert usage and preferences. CSCW 2010. https://erichorvitz.com/shamsi_iqbal-eric_horvitz_cscw_2010.pdf
Sahami Shirazi, A., Henze, N., Dingler, T., Pielot, M., Weber, D. and Schmidt, A. Large-Scale Assessment of Mobile Notifications. CHI 2014. https://weberdo.com/publications/2014-Large-Scale-Assessment-of-Mobile-Notifications.pdf
Pielot, M., Church, K. and de Oliveira, R. An In-Situ Study of Mobile Phone Notifications. MobileHCI 2014, pp. 233-242. https://dl.acm.org/doi/10.1145/2628363.2628364
Mehrotra, A., Hendley, R. and Musolesi, M. PrefMiner: Mining User's Preferences for Intelligent Mobile Notification Management. UbiComp 2016. https://pure-oai.bham.ac.uk/ws/files/29201286/PrefMiner_Mining_User_s_Preferences_for_Intelligent_Mobile_Notification_Managemen.pdf
Mehrotra, A., Pejovic, V., Vermeulen, J., Hendley, R. and Musolesi, M. My Phone and Me: Understanding People's Receptivity to Mobile Notifications. CHI 2016, pp. 1021-1032. https://dl.acm.org/doi/10.1145/2858036.2858566
Pielot, M. and Rello, L. Productive, Anxious, Lonely: 24 Hours Without Push Notifications. arXiv 1612.02314. https://arxiv.org/pdf/1612.02314
Okoshi, T., Ramos, J., Nozaki, H., Nakazawa, J., Dey, A. K. and Tokuda, H. Attelia: Reducing User's Cognitive Load due to Interruptive Notifications on Smart Phones. IEEE PerCom 2015. https://www.semanticscholar.org/paper/b69d4d0a57a7dfebd42168b85661a4b14bd29d12
Okoshi, T., Tsubouchi, K., Taji, M., Ichikawa, T. and Tokuda, H. Attention and Engagement-Awareness in the Wild: A Large-Scale Study with Adaptive Notifications. IEEE PerCom 2017. Project page: https://www.ht.sfc.keio.ac.jp/~slash/research/attelia/
Mehrotra, A. and Musolesi, M. Intelligent Notification Systems: A Survey of the State of the Art and Research Challenges. arXiv 1711.10171 (2017). https://arxiv.org/abs/1711.10171
Upland Software. Upland Software Acquires Localytics, Raises Guidance (7 February 2020). https://uplandsoftware.com/resources/acquisitions/upland-software-acquires-localytics-raises-guidance/
Dekker, C. A., Baumgartner, S. E., Sumter, S. R. and Ohme, J. Beyond the Buzz: Investigating the Effects of a Notification-Disabling Intervention on Smartphone Behavior and Digital Well-Being. Media Psychology 28(1), 2024, pp. 162-188. https://www.tandfonline.com/doi/full/10.1080/15213269.2024.2334025
Apple Developer Documentation. Handling notification responses from APNs (the status codes APNs returns on submission). https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns
OneSignal Documentation. Push overview. https://documentation.onesignal.com/docs/en/push
OneSignal. Guide to Understanding Push Notification Performance. https://onesignal.com/blog/guide-to-understanding-push-notification-performance/
Singular. Push Notification Campaign Measurement. https://support.singular.net/hc/en-us/articles/34936651200539-Push-Notification-Campaign-Measurement
Apple Machine Learning Research. Updates to Apple's On-Device and Server Foundation Language Models. https://machinelearning.apple.com/research/apple-foundation-models-2025-updates
Google for Developers. Overview of the ML Kit GenAI APIs. https://developers.google.com/ml-kit/genai
Google Blog. A smarter, more proactive Android with Gemini Intelligence. https://blog.google/products-and-platforms/platforms/android/gemini-intelligence/
Apple Inc. US 12,243,523 - Digital assistant for providing handsfree notification management (detecting the notification a user attends to, taking a spoken instruction, and performing the action; PCT publication WO2023049140A1, 2023). https://patents.google.com/patent/WO2023049140A1/en
Gamzu, I., Karnin, Z., Maarek, Y. and Wajc, D. You Will Get Mail! Predicting the Arrival of Future Email. WWW 2015 (Companion). https://doi.org/10.1145/2740908.2741694
Apple Developer Documentation. App Intents: Integrating actions with Siri and Apple Intelligence. https://developer.apple.com/documentation/appintents/integrating-actions-with-siri-and-apple-intelligence
Apple could fully enforce their policies and fix this in a heartbeat, but they won’t.
There are some apps I can’t afford to mute or uninstall, such as phone, transportation, communication and work. I wish I could, but I currently can’t, I’m not privileged enough.
“Punishment by Apple” in this instance is somehow the only response anyone had to misbehaving companies.
What's frustrating is that a lot of grocery stores do this. If you sell something absolutely necessary, such as basic foods, you should not be allowed to do the whole "mark it up to mark it down" strategy.
Also, a tip for most grocery stores (at least in the US): enter in any area code plus 867-5309. Chances are high that somebody has registered it. It's better than sharing with a family member because so many people are using it, the data becomes less useful.
Alternatively, ask the clerk to "use the store card". Usually, they will oblige.
Hence I doubt retailers will ever consider offering a fair price.
Having apps sleep and a daemon wake them to handle notifications doesn't require all of the notifications coming from Apple.
I have my phone set to only ring for people in my address book. It’s probably time to do something similar for email. Not in my address book? Straight to trash.
There has always been "unpluggers" [0] amongst technologists, but the vibes are bad and getting worse. I feel like that is getting more common between "normal" people I know, but maybe outside of my country town bubble its not happening.
I was thinking we're only one or two big influencers away from a cascade, but then the ultra-influencers are never really going to commit because its their livelyhood and saying throw your phone away is self-limiting on the viral aspect.
I guess we're just stuck under the boot.
^0 https://biggaybunny.tumblr.com/post/166787080920/tech-enthus...
("list-unsubscribe" OR "unsubscribe" OR "list-id")
It would be better if they were totally opt-in of course (1), but that's not bloody likely to happen.
(1) As in off by default with no questions.
Manually polling multiple items as you go around your day is stealing valuable mental bandwidth that could be used in better things.
You want to use any of those things, you’ll have to pay their toll booth, figuratively or literally.
On the flipside, I have an app that sends notifications. We don't abuse it or use it for promotions, and APNS and Google's version works perfectly fine for us.
The single persistent connection is just to receive pushes, there is still some daemon controlled by apple in charged of dispatching to correct app.
All that said, it's not like the platform developers are fully in the wrong when they're reducing pushes. It does have an impact on battery life, and if users aren't acting on them quickly, maybe the platform shouldn't either, even if there's risks when delaying communication.
Never underestimate the ignorance of the average person…
I am talking about those people who consume content while ads blink around the content in a all four directions and they don‘t even actively notice.
Feels like an education issue rather than a tech issue.. thoughts?
edit: downvote all you want. Fact remains that there is no way currently to block advertisement notifications and no disincentives for those who use them.
Of course you could describe almost all of the internet that way.
Isn't that kind of the point? If someone else is trying to login somewhere with your credentials, your two factor will ping up?
My phone is setup similarly. I did it manually back in the day, then sent some feedback to Apple, which they added in the next update about a year later. I’ve submitted a lot of feature requests, this was the only one they actually did, which is a great one. It made things much easier. Though they seemed to have changed the settings of how this works with the call screening feature. I used to have a shortcut to toggle this off and on, when I was expecting a call from an unknown number. I need to revisit my setup here, as the shortcut doesn’t actually do anything anymore.
Doing this to email is an interesting idea. If sitting in one ecosystem, maybe it would work. I’m fractured, so it’s a non-starter. Even beyond that, I think it would be an issue as there are real emails I do want to get which I’d never add to my address book, as I’d never send an email to the address. I think I’d want a whitelist for these addresses, that imported the emails from my address book as a base.
At work I had a rule like this for many year. Anything internal would pass, plus a few external domains I named. Everything else would go to a spam folder for vendor emails. Keeping up on this was hard. I ended up throwing in the towel a couple years ago after running the rule for 5-10 years. This blog post is what made me move away from this rule[0].
I’m sorry but if you honestly think the number of users who receive marketing spam have expressed “informed consent” you’re fucking high. There is a multi-trillion dollar industry devoted to tricking people into opting into spam. Stop pretending these people are expressing any consent at all.
Same with websites like Youtube who don't understand a plain "no" but offer a fake choice between "yes, harvest all my data" and "ask me again later". That isn't consent, it's coercion.
2. because most of the time, any other option is bloody inconvenient
Maybe she didn’t opt in, but she will never unsubscribe from anything.
Emails from every site she’s ever shopped at.
I both agree and disagree with you. I disabled notifications for everything and found myself refreshing email too often. But if I have the notifications, I can get disturbed too often which also takes mental bandwidth.
For me I found the best tactic was to selectively enable notifications (whatsapp for just one person), and delete (not silence) everything else - I don't have email on my phone now - the temptation to check it is more than the need to have it. As for things like PagerDuty, I have it send an SMS and phone me instead.
I find polling less disruptive because my phone or watch are almost always nearby. Being in control of when to get interrupted feels better than having stuff constantly pop up while you’re doing something.
Just holding my partner’s phone spikes my cortizol. You try to type 2 sentences and get 5 notifications for random other apps and messages popping up on screen in the meantime. Literally one notification every 10 seconds on average. It’s horrible
Now a few apps have started sending notifications through WhatsApp because they have my phone number. e.g. Amazon
Except for marketers! I don't think there's a less sympathetic category of technologists, save for maybe CSAM peddlers.
You're upset that you can't get "visibility" into whether the bullshit ad you tried to ram down my throat landed on target? You're worried that I'm a dormant user and my phone will silently delete the spam you sent to try to hook me back into engaging with whatever worthless product you're hawking?
World's tiniest violin, buddy. Boo fucking hoo. Your last paragraph says the "senders" (read: spammers) who make it through the next decade intact will be, to lightly paraphrase, the ones who send messages the recipients actually wanted. You say that like it's a bad thing!
The computer is in my life because it is a tool that does the things I want. It is not an open mic for marketing sleazebags to try to sell me shit. May every single one of your attempts to invade my life and hijack my attention be flushed swiftly down the toilet.
Works well.
Conferences are great examples. You do want to submit your paper and go to a conference. To do that, they need your email address(understandable). That email ends up on dozens of email lists run by people who are doing "outreach" or something of the sort.
It can be hard to set phone boundaries with work. There are certain people who get very upset if I don’t answer their phone call.
Unfortunately Google isn't really exposing this to users, so you need something like App Ops or adb to set it up.
Suppose you want delivery notifications for your packages. The seller, by contrast, wants to spam you with marketing.
If getting the notifications requires you to install their app, they're going to shovel any spam into it that they can, and then they're writing the code that runs on your device. Whereas if the software on your device is controlled by you and the notifications are received using a standard protocol, you (or someone like uBlock) can create filters to only show the notifications you actually want and discard the spam.
But for that to actually work you need the software running on the client to be under the control of the user independent of which device or service they're using, and subject to competitive pressure. Otherwise the platform uses is as a means for lock-in and then filters your notifications in the ways that benefit them rather than you, or just does a lazy job because they know you've been deprived of having a lot of other alternatives.
If there's a chat app I installed 3 years ago, with no intention of giving it camera access, and I suddenly need to use that app for a video call, I don't want to be stuck debugging broken camera issues for two hours. I'd much rather have the app tell me that it doesn't have camera access.
I guess you can make the argument that you are then made aware of login attempts, but that feels more like something the host service should control.
My neighborhood has a WhatsApp. I engage with it if I feel like it. Works great
It's integrated somehow with the phone app on iOS, whatsapp calls show alongside GSM calls.
This too is frustrating. Spam is not allowed unless you have a "prior relationship".
But fuck me, that single toddler's bike I bought many years ago for my then toddler no longer qualifies as us having a relationship.
Hundred percent agree. I wouldn't support having notifications for everything enabled.
Also, websites are shady. If you put in a required email, they'll usually automatically check a little box for you that says "allow us to ruin your inbox?" How helpful of them.
And, I'm not even convinced that checkbox does anything.
Should be, but not always. There are plenty of apps that still mix marketing and functional notification.
Hell, even Apple does this, especially on new devices.
[Settings]: Log in to your iCloud account to sync data.
Three minutes later…
[Settings]: You qualify for three free months of Apple Music!
I am just looking for a fucking taxi.
Are there any VCs looking to give away a few billion dollars to disrupt the ossified, wasteful, poor customer experience taxi app market?
Imagine you're a shipping company and lock yourself into a parcel tracking protocol. You then decide to offer the innovative feature of parcel lockers, which need a code (or an action on your device) to open. How are you going to make the thousands of weird homebrew clients that people are using on their jailbroken Nintendo Switches or whatever to behave?
In other words, you need the user of the software to pay for it's development. Since that won't happen ...
I can actually confess that this hit me. Almost nothing on my phone has permission to use my camera, including my web browser (why???). I assume this was done in a fit of pique upon discovering that the setting even existed.
Roll on (god knows how many years later) and I cannot get into the gym with the link I was emailed to have my browser read a QR because my browser is just a grey screen. It was only when the member of staff suggested permissions that I realised what was going on.
I'm the problem, it's me
Because to get that far they entered your password? Which you might like to change?
You did mention: "You are a two factor app."
If they've got past your first factor, you might want to know.
This has been going on since at least 2006.
Startups will "growth hack" by buying e-mail lists and feeding them into their password recovery tools.
A certain percentage of people will then follow the links and end up creating a new account on a service they had no interest in that now has their confirmed contact information, a new user, and a plausible reason to bombard them with marketing email.
The checkboxes seem to be a placebo. Sometimes there isn't one. Sometimes it doesn't do anything. Sometimes they say "updates on your order", which apparently also means future products you might want to buy a week after you receive your order. (Marketers' English seems like a foreign language to me).
Repeat until the emails stop.
People. Opt. In.
Stop conflating your preferences with other people’s.
Waymo are rolling out, slowly. No one'll be in a real position to compete against them.
The account was supposedly registered for an organization whose name was somewhat similar to mine, so I thought somebody fat-fingered their coworker's email (the initial email was an invitation to create an account and join the org), but it might have very well been the tactic you described.
> Almost like there are aligned interests there rather than a purely adversarial relationship.
You might very well be the exception, but for something like 99% of marketing content that reaches me, our interests aren't aligned. First of all, they want to generate "needs" where there weren't any before and probably shouldn't be. A pizza ad produces the wish for unhealthy food. A fashion ad produces the wish for new clothes (even though I have enough) and probably even changes the societal dynamics of individual expression and personal style to be consumption oriented.
Second, even if I have a legitimate need for a solution, they still want me to buy their product, consume their media, give my attention to them. I, on the other hand, want to be informed by a neutral third party about the pros and cons of some product. Sure you can say "but unhappy customers are bad for us", but there are actually very few niches, where this signal is powerful enough to align incentives, because information and power asymmetry limit the customers understanding of product quality and their leverage to correct harmful market dynamics.