Laravel Webpush Kit Laravel Package

Product Decisions This Supports

• Whether to ship browser push as a channel at all. This package collapses the front-end half of web push — permission UX, service worker, subscription persistence and rotation — into a Blade component plus routes. That turns "web push" from a multi-sprint front-end project into a scoped spike, so the decision becomes about audience value rather than engineering cost.
• Opt-in rate as the metric that decides the feature. The polite two-step prompt (your page asks first, the browser dialog opens only after Allow) exists because a single mis-click on the native dialog permanently blocks that user in that browser. If you are modelling notification reach — and you should be — this component is a lever on the one number that caps everything downstream: the percentage of visitors who end up subscribed.
• Re-engagement and lifecycle messaging on the roadmap. Push is the only channel that reaches a user who has closed the tab without an email address. Treat this as an enabler for cart abandonment, price drops, "your report is ready" and similar triggers, routed through Laravel's existing notification system rather than a new vendor.
• Build vs. buy, and it is genuinely close. The surface area here is small enough to write yourself, but the edge cases are not: pushsubscriptionchange re-subscription, 404/410 dead-endpoint cleanup, service worker scope and caching, declarative web push payloads, and iOS's Add-to-Home-Screen requirement. These are the parts teams get subtly wrong and then discover months later as silent delivery failures.
• iOS reach as a scoping question. The optional manifest and <x-webpush-kit::head /> exist specifically for iPhone/iPad Home Screen apps, because Safari only delivers push to installed web apps. That is a real product constraint: on iOS you are not buying a push channel, you are buying a "convince users to install your web app" funnel. Decide whether that funnel is in scope before committing.
• Support-cost and time-to-first-push. php artisan push:test sends a real push and reports what each push service actually answered, flags dead subscriptions the channel removed on 404/410, and warns on a VAPID_SUBJECT that Safari rejects. That is a diagnostic tool that shortens onboarding and cuts a class of "push doesn't work" support tickets — worth valuing separately from the UI component.
• Instrumentation planning. The component fires webpush-kit:subscribed / webpush-kit:unsubscribed browser events. Wire these into analytics before launch or you will have no way to evaluate the rollout.

When to Consider This Package

Consider it when all of the following hold:

• You are on PHP 8.3+ with Laravel 12 or 13, and comfortable pinning to laravel-notification-channels/webpush 11–13. Older Laravel is out — look elsewhere or budget for a fork.
• You are already using, or willing to adopt, laravel-notification-channels/webpush for server-side sending. This is explicitly the browser half of that stack, not a standalone push provider; it is not an alternative to OneSignal/Firebase.
• Your front end is Blade and/or Livewire. The value is in the drop-in component. On a React/Vue/Inertia SPA you would be adopting routes, a service worker and a test command while discarding the main deliverable.
• You care about permission-request UX and edge states — blocked, unsupported, insecure origin, iOS Safari A2HS. Hand-rolling these is where teams burn time and lose subscribers.
• You want vendor-neutral, first-party push rather than another SaaS dependency in the messaging path.

Look elsewhere, or wait, when:

• Maturity is a gate. This is v0.1.0. There is no deprecation policy, no migration history, and no evidence of production usage at scale. For a payments-adjacent or compliance-sensitive surface, that is disqualifying today.
• Firefox or desktop Safari are material to your audience. Neither was tested. Mobile Safari and actual iPhone/iPad Home Screen apps were also not exercised — only the state handling for them. You would be the one finding those bugs.
• Notification click-through is a core success metric. The click target is set and checked in Chrome, but the click itself was never exercised end-to-end because the banner did not render on the test machine. If CTR is how you will judge the feature, you cannot validate your own KPI without doing this testing yourself first.
• You need guaranteed compatibility across the browser matrix or a support contract. This is a young, narrow package.
• You need segmentation, scheduling, journeys or a dashboard. Those live in the channel package or a commercial provider, not here.

How to Pitch It (Stakeholders)

For executives, one paragraph: Web push lets us reach users who have left the site, without an email address and without paying a messaging vendor. Historically the expensive part was not sending the notification — it was the browser-side work: asking for permission without getting permanently blocked, handling the users who already said no, keeping subscriptions alive, and dealing with the iOS quirk that push only works once someone installs our site to their home screen. This package, from the maintainers of the Laravel web push channel, packages all of that as a drop-in button, a service worker and a diagnostic command. It is a small, focused dependency that converts a multi-sprint front-end project into a short integration, and it makes our opt-in rate something we can actively optimise rather than accept. The caveat is maturity: it is a 0.1.0 release, tested thoroughly on Chrome and in CI but not yet on Firefox or desktop Safari, and its notification click-through has not been verified end-to-end. I would recommend a time-boxed pilot on one property to measure opt-in and delivery rates, not a company-wide rollout.

For engineering, the summary: Adopt it as the browser-side layer on top of laravel-notification-channels/webpush, which we would need anyway. It gives us a Blade/Livewire <x-webpush-kit::button /> with permission priming and explicit handling of subscribed, blocked, unsupported, insecure and iOS-A2HS states; a publishable service worker at /webpush-sw.js that renders both WebPushMessage and DeclarativeWebPushMessage, honours data.url / navigate on click, and re-subscribes on pushsubscriptionchange; routes that call the channel's own updatePushSubscription() / deletePushSubscription(); an optional manifest and <x-webpush-kit::head /> for iOS; and php artisan push:test for verifying credentials and surfacing dead endpoints. Constraints: PHP 8.3+, Laravel 12/13, channel 11–13. Quality signals are reasonable for a 0.1.0 — Pest, Pint, PHPStan level 6, CI across three PHP versions and two Laravel majors, plus a real Chrome install against Google's push service including a genuine 410 and Livewire wire:navigate re-renders. Known gaps we would own: Firefox, desktop Safari, iOS Home Screen apps, and an unverified notification click. Plan to verify those four in the pilot, wire the webpush-kit:* events into analytics, and pin the version explicitly.

Ask: approve a scoped pilot with a defined opt-in-rate target, conditional on us completing the Firefox, Safari and click-through verification before any broader rollout.