Push Notification Platform Without an App: What Works in 2026

1. Can you send push notifications without an app?

The reason this question is confusing is that the market answers it dishonestly in both directions. One group of vendors says "yes, push without an app!" and quietly means web push, which only works in a browser the customer has granted permission on. Another says "wallet notifications are just push without the app," which overstates what a wallet pass does. Both are selling something real. Neither is selling app push.

So start from the mechanism. A push notification is a message delivered by a platform's push service to a specific subscription or token that some software on the device registered. The question is never "can I push without an app" in the abstract — it is what software on the customer's phone is going to hold that registration, and what did the customer have to do to create it? Six answers exist, and only one of them requires an App Store download.

The six channels, compared honestly

Related concepts: push notification service, device token, service worker, wallet pass, notification permission.

2. What "push notifications without an app" actually means

This ambiguity is not pedantry. It changes the answer to every downstream question — who you can reach, what the customer has to do first, what you can send, when it appears, and what it costs. Below is each meaning stated plainly.

Meaning 1 — Web push without a native app

You send notifications to people who visited your website and granted permission there. There is no app at any point: the registration lives with the browser and a service worker you host. Mozilla's Push API documentation is explicit about the dependency — "For an app to receive push messages, it has to have an active service worker," and once active "it can subscribe to push notifications, using PushManager.subscribe()." The resulting subscription "includes all the information that the application needs to send a push message: an endpoint and the encryption key needed for sending data." That endpoint is what your platform sends to. This is the most literal reading of the search phrase and the one most web push vendors mean.

Meaning 2 — PWA push

A progressive web app is, in Mozilla's words, "an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app" — one that "can be installed on the device, can operate while offline and in the background." There is still no App Store submission, no native codebase and no review process, but the customer does install something. On Apple's platforms this distinction is not cosmetic: Apple's own guidance is to "add web push to Home Screen web apps in iOS 16.4 or later and Webpages in Safari 16 for macOS 13 or later." On an iPhone, in other words, the Home Screen web app is the requirement.

Meaning 3 — Wallet-based customer engagement

Instead of an app, the customer saves a pass — a loyalty card, membership card, coupon, offer or ticket — into Apple Wallet or Google Wallet, both of which are already on the phone. The business can then change what that pass says, and each platform surfaces some of those changes to the customer. This is a genuinely different model: there is no app to build, no permission dialog in the usual sense, and the persistent object is a card rather than an icon. It is also more limited than app push in ways Section 5 sets out precisely.

Meaning 4 — Other notification channels

SMS and email are not push notifications and it is worth refusing to blur that line. But when someone searches for a way to notify customers without an app, they are frequently describing a business problem — "I need to tell people something and I do not want to build an app" — for which a text message or an email is a perfectly reasonable answer, with different economics and different reach. Any honest comparison has to include them.

Related concepts: Push API, service worker, progressive web app, mobile wallet app, notification permission.

3. The best alternatives to app push notifications

Option 1: Web push

How it works. A visitor lands on your site. Your page asks for notification permission, they accept, and the browser creates a push subscription — an endpoint plus encryption keys — which you store against that person. Later, your server sends an encrypted message to that endpoint; the browser's push service delivers it; your service worker wakes and displays a notification. The whole flow is a cross-browser standard: Apple describes it as "push notifications that use the cross-browser Push API, Notifications API, Badging API, and Service Worker standards," and Mozilla notes the Push API has been "available across browsers since March 2023."

Requirements and permission model. Three things are non-negotiable. You need HTTPS and a service worker on your own domain. You need the user to opt in — and Apple is specific about how: "Provide a method for the user to grant permission with a gesture, such as clicking or tapping a button. When the user completes the gesture, call the push subscription method immediately from the gesture's event handler code." And you need a server set up for the standard: a VAPID key pair, payload encryption, and delivery per RFC8030.

Strengths. It is a real push notification, arriving outside your website, with no app to build. It is well supported on desktop and Android. It integrates naturally with anything you already do on the web, and the cost per message is effectively nil.

Limitations. Four, and they are material. First, it is per browser — a subscription created in Chrome on a laptop is not a subscription on that person's phone. Second, opt-in rates depend entirely on how and when you ask, and a permission prompt fired on page load is the single most common way to destroy a channel. Third, on Apple's platforms the mobile path runs through a Home Screen web app, not Safari tabs, per the requirement quoted above. Fourth, you cannot send silent, invisible pushes on Safari: "Safari doesn't support invisible push notifications. Present push notifications to the user immediately after your service worker receives them. If you don't, Safari revokes the push notification permission for your site."

Best for. Publishers, marketplaces, ecommerce and SaaS — businesses whose customers return to a website repeatedly and where the notification is genuinely about something on that website.

Option 2: PWA push

What a PWA is. A progressive web app is a website built to behave like an installed app: one codebase, delivered over the web, but installable, capable of running offline and in the background, and able to use operating-system-level features. Mozilla lists among its capabilities a "Notifications API" — "a way to send notifications that are displayed at the operating system level" — alongside background operation and badging.

How it differs from a native app. There is no app store submission, no review cycle, no separate iOS and Android codebase, and no download from a store listing. Updates ship the way your website ships. What you gain over plain web push is an app-like container the customer has deliberately installed, which on iPhone is also what makes web push available at all.

Installation and engagement considerations. This is the catch. Asking a customer to add your site to their Home Screen is real friction — less than an App Store download, but far more than saving a pass or accepting a permission prompt. It works when the product is used often and deliberately. It works badly as a marketing channel for a business the customer visits once a fortnight.

Strengths. App-like experience, offline capability, badging, one codebase, no store gatekeeping, and full web push support.

Limitations. Install friction; platform capability differences you must test rather than assume; no store discovery; and — for a local business with no software product — a fairly odd thing to ask a customer to do.

Option 3: Wallet-based customer engagement

How it works. Instead of asking someone to install software, you give them a pass: a digital loyalty card, membership card, coupon, offer, gift card or event ticket that saves into the wallet app already on their phone. Apple Wallet and Google Wallet are pre-installed, familiar and already hold things people care about. Enrolment is a QR code scan or a tapped link — no account, no download, typically a few seconds at a counter.

What you can do afterwards. The pass is not static. Apple's Wallet Passes documentation describes a full update cycle: you add webServiceURL and authenticationToken to the pass, the device registers it with your server, and then "Pass information changes and your server sends a push notification," after which "The user's device receives the notification and queries your server for updated passes." Google's model is different but also live: a messages array — "An array of messages displayed in the app. All users of this object will receive its associated messages. The maximum number of these fields is 10" — and a notifyPreference setting described as "Whether or not field updates to this object should trigger notifications. When set to NOTIFY, we will attempt to trigger a field update notification to users."

What it is good for. Anything where the customer benefits from keeping a card: stamp and punch cards, points balances, membership status and renewal dates, coupons and offers, VIP tiers, event tickets, and gift or stored-value cards where the platform supports them. The pass is a persistent, branded touchpoint that survives inbox clear-outs and does not depend on the customer remembering your website.

Why businesses like it. The economics are unusual. There is no app to build, no ongoing app maintenance, no store review, and no per-message carrier fee. Enrolment happens at the moment of maximum goodwill — at the counter, at checkout, at the end of a good visit — and the resulting object stays on the phone rather than in a feed.

Option 4: SMS

Strengths. Universal. Every phone receives a text, no install, no permission dialog, no browser, no wallet. It is read quickly, which makes it the right channel for genuinely time-critical messages — an appointment change, a delivery, a code, a same-day cancellation you need to fill.

Limitations. You pay per message, so the cost scales exactly as the audience does, and a channel that costs money per send tends to get used sparingly and then not at all. It is heavily regulated: consent rules, opt-out handling and, in many markets, sender registration requirements. There is no branding surface, no persistent object, and no state — a text is gone once read. For a full cost treatment, see our breakdown of the true cost of SMS marketing and the wallet versus SMS comparison.

Option 5: Email

Strengths. Cheap at scale, unlimited length, rich formatting, universally supported, and the natural home for receipts, statements, newsletters and anything a customer might want to find again. Consent is well understood and the tooling is mature.

Limitations. Attention, mostly. An email competes with every other email, deliverability is an ongoing discipline rather than a setting, and a promotional message can sit unopened for days. It is a considered channel, not an immediate one. We compare it directly with wallet in wallet marketing vs email marketing.

Related concepts: push notification marketing, VAPID, service worker, digital loyalty cards, opt-in rate.

4. Web push vs wallet notifications vs app push

The three differ before the message is ever sent, in what the customer had to do and what now lives on their device. Figure 2 shows the mechanism side by side, because almost every misleading claim in this category comes from skipping it.

Which one should you choose?

Decision logic, in the order that actually narrows the field:

1. Do you need functionality, not just messages? Accounts, complex workflows, offline use, device integrations, daily interaction — if yes, you are choosing an app, and push comes with it. Stop here.
2. Do your customers repeatedly visit your website? If your business genuinely lives on the web — content, ecommerce, a SaaS dashboard — web push is the natural fit, because the notification has somewhere to send them.
3. Do your customers visit you in person, or hold something from you? A card, a membership, a balance, a coupon, a ticket, a stamp count. If yes, wallet engagement is the strongest option, because the thing you are keeping on their phone has standalone value.
4. Do you need to reach everyone, including people who enrolled in nothing? That is SMS or email, chosen by urgency and cost.

Most businesses answer yes to more than one. That is fine and normal — the mistake is not running two channels, it is running two channels that do the same job.

Related concepts: push notification tools, wallet passes vs custom loyalty apps, opt-in rate, channel strategy.

5. How wallet-based notifications work without a mobile app

The journey, end to end

Conceptually the flow is short. A business creates a digital pass. A customer receives or saves it. The pass lives in the wallet app already on their phone. The business updates relevant information on that pass. The customer sees the updated information through the wallet experience — on the card itself, and, where the platform's rules are met, as a notification.

What Apple's documentation actually says

Apple's Adding a Web Service to Update Passes describes updating a pass as "a cooperative effort between the user's device, Apple servers, and your server," in five steps:

1. "The user installs a pass that supports updates on their device."
2. "The user's device registers the pass with your server and provides a device identifier and a push token."
3. "Pass information changes and your server sends a push notification."
4. "The user's device receives the notification and queries your server for updated passes."
5. "The user's device requests each pass that has changed."

The detail that settles the "is this app push?" question is in the payload. Apple specifies that the notification "uses the same certificate and private key that the creator of the pass used to sign the original, the push token registered by the device, and an empty JSON dictionary for the payload." There is no message in that push. It is a signal telling the device to come and fetch the changed pass. Apple also notes that "A push notification for a pass update works only in the production environment."

So where does the visible message come from? From the pass itself. Apple's Wallet developer guidance explains that "The device compares the latest version of the pass against the version it had before to determine which fields have changed. If the value of a field has changed and the field specifies a change message, the device shows the message to inform the user about the change." Apple then adds a warning worth repeating to any marketer: "Change messages interrupt the user and must be read immediately. They are typically appropriate only for information that is time sensitive."

Relevance: the other way a pass surfaces

Wallet passes have a second surfacing mechanism that has no equivalent in email or SMS. Apple's Showing a Pass on the Lock Screen states that "A pass can be relevant on a date, at a location, or both," and that "The system displays the pass on the lock screen if both the date and any location matches. Passes with no locations display on the relevant date. Similarly, passes with no relevant date display when one of the locations matches." The constraints are documented too: "A pass can have only 10 relevant locations," and coupons, store cards and generic passes "must provide locations if you added any other type of relevance information to the pass object." Beacon relevance is supported with "up to ten different UUIDs."

That is a real capability — a membership card that appears as you arrive at the gym — and it is also a bounded one. Ten locations is ten locations; a national chain has to choose, or update the pass as the customer moves. Anyone promising unlimited geofenced wallet marketing should be asked how they handle that limit.

Related concepts: wallet pass, PassKit, change message, lock-screen marketing, pass relevance.

6. Apple Wallet vs Google Wallet for app-free customer engagement

Use cases each platform supports well

• Loyalty and stamp cards — both. The card carries progress; updates change the count.
• Membership cards — both, with status, tier and expiry on the card face. See digital membership cards.
• Coupons and offers — both; Google additionally documents an automatic expiry reminder 48 hours before an offer card expires.
• Event tickets — both, with Google documenting an automatic upcoming reminder three hours before the event.
• Location-relevant cards — Apple documents Lock Screen relevance by date and location; confirm the equivalent behaviour on Google for your pass type rather than assuming parity.

Related concepts: Apple Wallet marketing, Google Wallet marketing, PassKit, Google Wallet API, pass class and object.

7. How to choose a push notification platform without an app

Group 1 — The app-free requirement itself

• No native app required from you — nothing to build, publish, review or maintain in either store
• No app required from your customer — ask explicitly; some "app-free" products still expect a companion app for scanning or redemption
• Web push support — if you need it: service worker hosted where, on which domain, and with what fallback
• Wallet support, named per platform — Apple Wallet and Google Wallet, not "wallet"
• Apple Wallet specifics — which pass types, whether passes are updatable after issue, and who holds the signing certificate
• Google Wallet specifics — which pass classes, and which of the documented notification paths the platform uses

Group 2 — Getting customers enrolled

• Enrolment methods — QR code, save link, SMS or email delivery, embedded on a web page, at a point of sale
• QR or code-based enrolment — where applicable, and whether one code can serve a whole counter or every customer needs a unique one
• Friction count — literally count the taps from scan to saved pass or granted permission
• Account requirement — whether the customer must create anything; the answer should usually be no
• Data captured at enrolment — what you collect, what consent you capture, and where it lives

Group 3 — Messaging capability

• What can actually be sent — and by which mechanism on each platform; ask for the documentation
• Scheduling — send at a chosen time, in the customer's timezone if that matters to you
• Behavioural triggers — fire on an event such as a save, a scan, a reward earned or a period of inactivity
• Segmentation — by tag, tier, behaviour, location or enrolment source
• Personalisation — per-customer content on the pass or in the message, not just a merge field in a blast
• Templates — reusable message and pass designs so campaigns do not start from blank
• Frequency controls — caps, quiet hours and suppression rules; a channel with no brakes gets abandoned

Group 4 — Measurement

• Enrolment analytics — saves or subscriptions, by source, so you know which QR code or page works
• Engagement analytics — scans, redemptions, clicks, repeat visits
• Campaign analytics — per send, not just lifetime totals
• Retention analytics — how many enrolled customers are still active after 30, 60 and 90 days
• Export — can you get your own data out, in a usable format, without asking support

Group 5 — Fit with what you already run

• Integrations — named support for your point of sale, ecommerce platform, booking system or CRM
• API — for anything the built-in connectors miss, with documentation you can read before buying
• Ease of implementation — can a non-developer launch it, and what is the realistic time to first customer enrolled
• Design control — your branding on the pass or notification, not a vendor template with your logo dropped in

Group 6 — Commercial and compliance

• Pricing model — per contact, per message, per pass, per location, or flat; and what happens when you grow
• Deliverability and reliability — what the vendor commits to, and what they say happens when a platform does not deliver
• Compliance — consent capture, opt-out handling, data residency and deletion; and for SMS, the rules in every market you send to
• Platform coverage — the honest split of your audience across iPhone and Android, and what each group actually experiences

Related concepts: vendor evaluation, QR code enrolment, segmentation, behavioural triggers, consent.

8. Push notification platform without an app: what businesses should look for

Scoring your own situation

Take the eleven categories, assign each a weight from 1 to 3 based on how much it matters to you, multiply by the scores above, and total. Three weightings come up repeatedly:

• Local business, repeat visits, no developer — weight setup complexity, customer friction, retention capability and cost at 3. Wallet wins convincingly.
• Online business, high web traffic, no physical location — weight reach, automation and analytics at 3, wallet support at 1. Web push wins.
• Product used daily, with accounts and workflows — weight personalisation, retention capability and analytics at 3, and accept that you are choosing an app.

Related concepts: evaluation matrix, weighted scoring, enrolment friction, retention capability.

9. How to send customer notifications without building an app

Step 1 — Define the customer event

Write down something that happens in the customer's life, not in your dashboard. "Signed up", "earned their fifth stamp", "has not visited in six weeks", "membership renews in ten days", "left something in the basket". If you cannot name the event, the message will be an announcement, and announcements are what get channels muted.

Step 2 — Choose the communication channel

Use Section 4. Match the event to the channel that suits it: a stamp earned belongs on the card; a delivery delay belongs in SMS; a monthly statement belongs in email. One event, one primary channel.

Step 3 — Choose the enrolment method

How does this customer get into the channel at all? A QR code at the counter, a save link at checkout, a permission prompt after a second visit to your site, a link in the booking confirmation. Enrolment is the constraint on everything downstream — a brilliant campaign to forty people is still a campaign to forty people.

Step 4 — Create the customer experience

For wallet, that means designing the pass: what is on the front, what the barcode does, what changes over time. For web push, it means the page that asks for permission and the moment you ask. This is the step where "app-free" stops being a limitation and starts being a design brief — the customer is going to see this object every time they open their wallet or their browser.

Step 5 — Create the message

One idea, one action, written as if to a person who is doing something else. Say what changed and what they can do about it. Keep in mind Apple's own guidance about change messages: they "interrupt the user and must be read immediately," which is a good test for whether the message deserves to exist at all.

Step 6 — Define the trigger

Manual, scheduled, event-triggered or behaviour-triggered. Be honest about which tier your stack supports before you design around the highest one — this is the single most common gap between a campaign plan and a campaign. Our guide to push notification automation covers triggers, drips and sequences in depth.

Step 7 — Set timing

Choose the moment the message is useful to the customer, not the moment it is convenient to send. A lunch offer at 11:20 is a different campaign from the same words at 15:00. For anything with a physical location, timing and location together are the whole message.

Step 8 — Add segmentation

The productive question is not "who should receive this" but "who should not." Exclude people who just visited, people who already redeemed, people who bought yesterday. Relevance is mostly subtraction.

Step 9 — Set frequency limits

Decide the maximum number of messages a customer can receive in a week, across every campaign, and enforce it centrally. Wallet and web push both have a hard failure mode — a deleted pass or a revoked permission — and unlike email there is no re-permission path that does not involve asking again in person.

Step 10 — Measure results

One KPI per campaign, decided before it sends. Enrolments for acquisition campaigns, redemptions for offers, repeat visits for retention, retained passes for programme health. Then take what you learn back to step one, because measurement should change which events you choose, not just which words you use.

Related concepts: behavioural trigger, segmentation, frequency capping, push notification marketing, campaign KPI.

10. Push notification use cases without an app

Related concepts: restaurants, coffee shops, salons, gyms, Shopify stores, agencies.

11. App-free customer retention strategies

The reason app-free retention works at all is that the customer is holding something. A pass with eight stamps on it is a reason to come back that exists whether or not you send anything. Messages then do a narrower and more effective job: they mark a change in state the customer already cares about.

Related concepts: customer retention strategies, local business retention, win-back, lifecycle automation, churn.

12. Push notifications without an app for loyalty programs

Compare the two ways a business without an app can run loyalty. A paper card is cheap and gets lost, and you learn nothing from it. A card in the wallet cannot be left at home, updates when the customer earns something, and tells you how many people are actually enrolled and returning. Neither requires a download. For the full mechanics of digital cards, see digital loyalty cards explained and our guides to the punch card app and stamp card app categories.

What a loyalty pass can hold

• Stamps and punches — visible progress toward a defined reward
• Points — an accumulating balance your system supplies to the card
• Tier or status — bronze, silver, VIP, or whatever your programme calls it
• Rewards available now — the state that most deserves a message
• Membership details — number, start date, renewal date, entitlements
• A barcode or QR code — how the card is actually used at a counter

Why the card outperforms the message

A loyalty pass changes the economics of retention because it is doing work between campaigns. The customer opens their wallet to pay for something else and sees that they are two stamps from a free coffee. No message was sent, no permission was consumed, no cost was incurred. When you do send something, it lands against a context the customer already has — which is why "your reward is ready" outperforms "here is 10% off" by a margin that has nothing to do with copywriting.

Related concepts: customer loyalty cards, loyalty card types, membership cards, POS loyalty, points and stamps.

13. Push notifications without an app for small businesses

The five constraints that actually decide this

• No development team. If a launch requires a developer, it will not happen — or it will happen once and never be changed again.
• Limited budget. The cost that matters is not the first month; it is the recurring cost twelve months in, at your real customer count.
• No app, and no realistic route to one. Even a cheap app carries store accounts, updates, OS changes and support, forever.
• Enrolment has to happen in person. At a counter, in a queue, in about ten seconds, without a signup form.
• Nobody has time to run it. Automations that fire on their own beat campaigns that need someone to remember.

Related concepts: free loyalty software, in-store marketing, counter enrolment, staff workflow.

14. Push notifications without an app: costs

The cost lines to model

• Software subscription — at the tier you will actually need in twelve months, not the entry tier
• Development — build cost for an app or PWA; integration work for web push
• Maintenance — the permanent line for anything you built yourself
• Messaging fees — per message where they exist; zero where they do not, which is the structural advantage of push and wallet over SMS
• Payment processing — only where the programme handles money, such as stored-value or gift cards
• Integration — connecting to your point of sale, ecommerce platform, booking system or CRM
• Design — pass artwork, notification creative, counter materials, QR signage
• Administration — the staff time to run campaigns, enrol customers and answer questions; at small scale this is often the largest real cost
• Customer acquisition — what it costs to get someone enrolled in the channel in the first place

Related concepts: total cost of ownership, SMS marketing costs, maintenance cost, per-message pricing.

15. Limitations of app-free push notification platforms

The limitations, stated plainly

• Platform differences. Apple and Google implement wallet messaging differently, and Google's FAQ states that "Developer authored push notifications are not currently supported by Google Wallet." You are designing for two systems with different rules, and neither is under your control.
• Permission requirements. Web push requires an explicit opt-in granted through a user gesture. Ask badly and you lose the channel for that visitor permanently — there is no second prompt.
• Browser limitations. Support and behaviour vary by browser, and on iPhone Apple documents web push for Home Screen web apps rather than ordinary Safari tabs. A web push strategy that assumes uniform mobile coverage will underdeliver.
• Wallet ecosystem constraints. Pass relevance is capped — Apple documents a maximum of ten relevant locations and up to ten beacon UUIDs. Message behaviour is defined by the platform. Google's notifyPreference is "ephemeral and needs to be set with each PATCH or UPDATE request."
• Customer adoption. Everything here depends on the customer taking one action first — saving a pass, granting permission, installing a web app. That action is cheap, but it is not free, and your reach is capped by it.
• Enrolment friction. Enrolment usually happens in person or at a specific moment online. Miss the moment and you may not get another.
• Not every use case survives the translation. Rich interactive notifications, in-app messaging, complex account experiences, offline functionality and deep device integration are app capabilities. No wallet pass and no web push subscription replicates them.
• Different notification experiences. A wallet update is not a push notification with your wording on it. Expect a different look, a different trigger and a different level of control.
• Thinner analytics. You can see saves, scans, redemptions and repeat visits. You cannot see in-app behaviour, because there is no app to instrument.
• Automation ceilings. Behavioural automation is only as good as the data your platform holds. If the reward state, the visit history or the purchase data lives elsewhere and is not connected, the automation you planned is not available.

Related concepts: platform constraints, opt-in rate, notification permission, analytics limitations, wallet passes vs custom apps.

16. PushNotice: customer engagement without building a native app

What it does, and where it sits

PushNotice issues branded passes into the two wallet apps customers already have, and gives the business a way to enrol people, tag and segment them, run campaigns, and update the passes afterwards. The enrolment path is the one Section 13 argues matters most for small businesses: a QR code or a save link, no account, no download, seconds at a counter. After that the card sits in the customer's wallet doing the work described in Section 12 — carrying progress, status and branding between campaigns.

What it does not do is equally important to state. It does not send native app push notifications, because there is no app. It does not replace a point-of-sale system, a CRM, an SMS gateway or an email platform. And it operates within exactly the platform constraints set out in Sections 5, 6 and 15 — Apple's pass-update and change-message behaviour, and Google's documented messaging and update-notification paths. No wallet vendor, including this one, can exceed what Apple and Google publish.

17. When you still need a mobile app

This guide is published by a wallet company and it would be easy to leave this section out. It is here because the alternative — pretending that app-free channels cover every case — would be false, and because the businesses for whom an app is right can usually tell within a few minutes of honest reflection.

The correct choice depends on the business objective, not on which technology is fashionable. A gym with a genuine app — booking, class schedules, workout tracking — should have an app and a wallet membership card, because the card reaches the members who never installed it. A coffee shop should almost certainly have the card and nothing else. For a direct comparison of these two paths, see wallet passes vs custom loyalty apps.

Related concepts: native mobile app, app push, offline functionality, device integration, build versus buy.

18. Push notifications without an app: FAQ

Nineteen questions, answered in the shortest accurate form. Where a platform behaviour is involved, the answer says which platform.

The core question

Web push and PWAs

Wallets

Choosing, cost and limits

Methodology, sources & disclosure

What is sourced, and how

Four categories of claim appear here and they are treated differently. Platform documentation — Apple's web push requirements, Apple's pass update web service, Apple's Lock Screen relevance rules, Google's Wallet FAQ, Google's Message and LoyaltyObject references, and Mozilla's Push API and PWA documentation — is quoted verbatim and consulted 27 August 2026. Industry research is not used, because we found no source in this category with a disclosed sample and methodology worth citing. PushNotice capabilities come from PushNotice's own published product and pricing pages, dated, with plan-dependent items marked to confirm. Everything else — the four-meanings taxonomy, the matrices, the decision tree, the scoring framework, the checklists and the ordering of the ten steps — is PushNotice analysis and labelled as such. Example communications in Section 10 are illustrative examples, written as templates, never presented as tested campaigns.

Why there are no statistics or prices here

Deliberate. Push notification benchmarks are widely republished with no disclosed sample, period or methodology, and figures for wallet adoption in particular tend to trace back to vendor marketing rather than to research. Vendor pricing changes and varies by plan, region and volume, so a price printed here would mislead a buyer within months. A cost model you can fill in with current numbers is more useful than a number that looks authoritative and is wrong. The same principle governs competitor capabilities: this guide describes categories of technology, not named vendors' feature lists.

How platform claims were verified

Every platform statement in Sections 5, 6 and 15 was taken from the vendor's own current documentation, not from third-party blog posts, and quoted rather than paraphrased where the exact wording matters. Where two Google documents appeared to conflict — the FAQ stating developer-authored push is unsupported, and the API reference documenting notification-triggering settings — both are quoted and the difference is explained rather than resolved in whichever direction suited the argument. Platform documentation changes; re-verify before building anything that depends on it.

Editorial policy and conflict of interest

PushNotice sells wallet-based customer engagement, which is one of the four approaches described here and the right answer for some readers and not others. We manage that conflict by saying so directly: Section 3 recommends web push where it fits better, Section 15 lists our own channel's constraints, Section 16 names six things PushNotice does not provide, and Section 17 tells readers who need an app to build one. Nothing here is paid placement, and no vendor reviewed this guide before publication.

Review and updates

Published 27 August 2026 and last reviewed 27 August 2026 by the PushNotice Editorial Team. Platform documentation changes frequently; the quoted Apple, Google and Mozilla material should be re-verified before being relied on for implementation. Corrections are welcome via the PushNotice contact page.

About the author

Sajid Ali — Founder & CEO, PushNotice. Sajid works directly on wallet pass design, pass-update and notification logic, and the retention programmes built around them, and reads the Apple Wallet Passes and Google Wallet documentation as a working requirement rather than as research. That is the perspective behind this guide's central distinction — between a push notification you compose and a pass update the platform propagates — which is the difference most "push without an app" marketing blurs. Connect on LinkedIn.

Reviewed by the PushNotice Editorial Team. The team verified every platform quotation against its primary source, confirmed that no statistic, benchmark, vendor price or competitor capability is asserted anywhere in the article, and checked that every PushNotice claim in Section 16 corresponds to something PushNotice publishes.

Sources

• Apple Developer — Sending web push notifications in web apps and browsers. Source of the Home Screen web app and Safari version requirements, the user-gesture permission requirement, the VAPID and RFC8030 server requirements, and the statement that Safari does not support invisible push notifications. Consulted 27 August 2026. developer.apple.com
• Apple Developer — Adding a Web Service to Update Passes (Wallet Passes). Source of the five-step pass update flow, device registration, and the empty JSON dictionary payload used for the update push. Consulted 27 August 2026. developer.apple.com
• Apple Developer — Showing a Pass on the Lock Screen (Wallet Passes). Source of date and location relevance behaviour, the ten-location limit and the ten beacon UUID limit. Consulted 27 August 2026. developer.apple.com
• Apple Developer — Wallet Developer Guide: Updating a Pass (archived documentation). Source of the change message behaviour: the device compares versions, shows a change message where a changed field defines one, and change messages interrupt the user. Consulted 27 August 2026. developer.apple.com
• Google for Developers — Google Wallet API FAQ. Source of the statement that developer-authored push notifications are not currently supported, and of the automatic notification table by pass vertical. Consulted 27 August 2026. developers.google.com
• Google for Developers — Message (Google Wallet API REST reference). Source of the TEXT and TEXT_AND_NOTIFY message type definitions. Consulted 27 August 2026. developers.google.com
• Google for Developers — LoyaltyObject (Google Wallet API REST reference). Source of the messages array limit and the notifyPreference definition, including its ephemeral behaviour. Consulted 27 August 2026. developers.google.com
• MDN Web Docs — Push API. Source of the service worker requirement, the subscription contents, and the cross-browser availability note. Consulted 27 August 2026. developer.mozilla.org
• MDN Web Docs — Progressive web apps. Source of the PWA definition, installation model and capability list including the Notifications API. Consulted 27 August 2026. developer.mozilla.org
• PushNotice — published product and pricing pages, consulted 27 August 2026, for the capabilities listed in Section 16. pushnotice.io/wallet-marketing

Frameworks, matrices, checklists and scoring in this guide are original PushNotice analysis and are labelled as such. They are structures to test against your own business, not findings. Example communications are illustrative templates and no performance results are claimed for them.

Related guides

Cite this guide

• APA: Ali, S. (2026). Push Notification Platform Without an App: What Works in 2026. PushNotice. https://pushnotice.io/blog/push-notification-platform-without-an-app
• MLA: Ali, Sajid. "Push Notification Platform Without an App: What Works in 2026." PushNotice, 27 Aug. 2026, pushnotice.io/blog/push-notification-platform-without-an-app.