27 May 2026

What Apple and Google are doing to your push notifications

Contents
  1. Push as a battery problem
  2. Fifteen years of platform intervention
  3. What email did first
  4. The on-device editor
  5. What users actually do with notifications
  6. What the marketer can see
  7. Writing for the model in the pipe
  8. Shifting weight to owned surfaces
  9. What this becomes
  10. What to do about it

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 as a battery problem

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.

Fifteen years of platform intervention

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.

What email did first

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.

The on-device editor

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.

A zoomed-in phone screenshot of the accurate BBC notification. It reads "CEO shooting suspect Luigi Mangione in angry outburst outside court as he fights extradition to New York- follow live." Below is the misleading Apple AI BBC notification from an iPhone. It reads: "BBC News, Luigi Mangione shoots himself; Syrian mother hopes Assad pays the price; South Korea police raid Yoon Suk Yeol's office".

 

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

A flow chart illustrating the architecture of an AI system, highlighting the flow of data and processing steps from the 'Client app' to the 'Service' component, including 'Input safety signals', 'Output safety signals', 'Weights' and 'Runtime'
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.

What users actually do with notifications

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.

What the marketer can see

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.

Writing for the model in the pipe

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.

Shifting weight to owned surfaces

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.

What this becomes

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.

What to do about it

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.

  1. Reserve push for the jobs nothing else can do. It is the one channel that reaches someone who has not opened the app in weeks, so its surest use is waking dormant users and carrying genuinely time-critical, transactional alerts. Cross-sell, upsell, education and discovery can work on push when they are timely and personal enough to clear the relevance bar, but they default to promotional and compete worst for the interruption budget, so they usually do more, and risk less, on a surface the user opened on purpose.
  2. Build push around the user's own activity and requests, not your campaign calendar. Two kinds of notification survive intermediation by design. The first is the signal the user set up themselves: a price-drop or back-in-stock alert, a watchlist or threshold trigger, the status of something they are waiting on. The second is the event your product generates from their own state: a document shared with them, a comment or reply on their work, a job that finished, a limit crossed, the next step in a task they are mid-flow on. Both clear the relevance bar automatically, because the notification is about the recipient's own stuff rather than your campaign, and both should deep-link straight into the place in the product where they can act on it. This is the inverse of broadcast: the trigger comes from the user, you only carry it, and the editor has no reason to suppress something tied to its own user's activity.
  3. Ask for permission in context, not on launch. Since Android 13 made notification permission an explicit runtime grant, opt-in rates have fallen sharply. Request it after you have shown value, tied to a feature the user actually wants notified about, not behind a system prompt on first open. The permission is the whole channel; do not spend it on a cold ask.
  4. Segment and personalise; broadcast is the worst use of the channel. The vendor data, directional as it is, has pointed the same way for a decade: segmented and personalised notifications open at roughly double the rate of broadcasts, and a generic blast both underperforms and spends permission you do not get back. If you would not send it to a named person for a specific reason, do not send it to everyone.
  5. Never spend an interruption you have not earned. Do not dress marketing as time-sensitive; iOS lets the user switch that off per app from the lock screen, and you get no appeal. Volume kills permission, and relevance is the only lever you keep.
  6. Engagement is your deliverability; prune the dead opt-ins. The platform's ranking learns from whether people act on you, so a large base that never taps trains the model to demote you and nudges the user toward switching you off. Push has nothing as systematic as email's sender-reputation machinery, and the effect is more app- and OS-specific, but the direction is the same. Sunset subscriptions that have gone quiet. A smaller base that engages holds more reach than a big one that is ignored.
  7. Lead with the fact, not the voice. Put the concrete payload, the amount, the name, the time, the action, at the front rather than behind a brand-voice opener. Summarisers compress to the gist and keep what is machine-readable, so a fact-led title tends to come through the rewrite intact where a tone-led one does not. Treat that as a sensible default, not a measured rule: nobody has published the test for it, and the supporting evidence is indirect (users value information type over literary quality, and the summariser is built to extract the point).
  8. Stop trusting the push dashboard. Opens and clicks sit downstream of an editing layer you cannot see, and the conversions you can measure are a biased sample of the notifications the platform already chose to favour. Downstream conversion is the least-bad signal, but push conversion events are sparse, so at normal sending volumes it rarely clears statistical significance per campaign and you are often reading noise dressed as a result. The honest posture is doubt: confirm render through the SDK where you can, pool campaigns and lengthen windows before believing a number, and read rising engagement as "the platform trusts me more" at least as readily as "my copy got better."
  9. Move the weight to surfaces you actually own. Your in-app inbox, logged-in product screens, physical mail and the loyalty surface where you are the platform have no model in the pipe: nothing summarises, ranks or silences them, and you can measure them end to end. Run push and owned surfaces as one portfolio, not as rivals.
  10. Build for the agent, not just the lock screen. As Siri and Gemini begin acting on notifications, the clean, machine-readable proposition is the thing an agent can execute, and the action behind it has to be exposed as something the agent can invoke, through App Intents on iOS or App Actions on Android, not buried three taps into your UI. Write so a model could carry out your message without a human ever reading it.

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.