Laravel Push Notifications Laravel Package

Product Decisions This Supports

• Multi-app push as a configuration concern, not a codebase concern. Push::app('name') with one config entry per app (APNs bundle_id/team_id/key_id/private_key, FCM service_account) maps directly to a product decision to ship more than one mobile app — white-label brands, regional variants, staging vs production bundles — without standing up new delivery infrastructure each time. If the roadmap has a second app anywhere in the next 12 months, this is the deciding shape.
• Build vs buy on commodity plumbing. APNs JWT signing and key rotation, FCM service-account OAuth, token refresh and caching, dead-token handling, retry semantics — all undifferentiated. Adopting this buys back the multi-week integration, keeping headcount on notification policy (what to send, to whom, when) rather than transport.
• Token hygiene as a product-quality metric. DeviceTokenUnregistered firing on APNs 410 / FCM UNREGISTERED means "user silently stopped receiving pushes" gets one cross-platform listener instead of per-provider cleanup. That is what makes a delivery-success-rate-per-app number trustworthy enough to put on a dashboard or in a roadmap review.
• Notification taxonomy stays in the product layer. Because it's a Laravel notification channel (via(), toPush(), routeNotificationForPush()), decisions about transactional vs marketing, per-user preferences, and which product events become pushes remain in application code — not baked into a vendor abstraction. Good for future preference-center or compliance work.
• Delivery predictability as an engineering-facing product commitment. Push::fake() (assertSent, assertSentTo, assertNotSent, assertSentCount, assertNothingSent) turns "user receives push" into an automatable acceptance criterion; php artisan push:test verifies credentials and a device token from the terminal, shortening release checklists.
• Sandbox fallback as a supported dev path. Optional retry of BadDeviceToken against the sandbox gateway legitimizes Xcode-build tokens instead of treating internal dogfooding/TestFlight as a hack — relevant if beta programs are on the roadmap.
• Scale-shape decisions. Connections shared across apps with the same APNs key, one FCM client per app, process-lifetime clients so queue workers keep connections and tokens across jobs, and a token cache shared through any Laravel cache store. These are the details that determine whether push is cheap or expensive at volume; they are also the reason to adopt early rather than retrofit.

When to Consider This Package

Consider it when:

• You are greenfield (or at a deliberate refactor point) on PHP 8.4+ and Laravel 12 or 13 — these are hard requirements, so this is not a candidate if a framework upgrade is a separate, unscheduled project.
• You need both APNs and FCM, or several apps, and want them behind one configuration surface.
• You run queue workers and care about connection reuse and a shared token cache (a nicety at low volume, a real cost saver at scale).
• You want push to ride Laravel's notification system with test fakes, rather than hand-rolling an SDK wrapper.
• Credentials come from a secrets manager; the package accepts a path or the PEM/JSON text directly, so that integration is not custom work.
• You can pin a version and absorb 0.1.x churn.

Look elsewhere, or wait, when:

• You cannot install it cleanly yet. The release notes state that until both packages are on Packagist, this package's own composer.json resolves the core from a sibling checkout via a path repository. That is a real blocker for a release-critical path: do not commit to this until aporat/push-notifications is published and a plain composer require works in a clean CI container. Treat the current release as evaluable, not shippable.
• You need v1 API stability, LTS, or a multi-maintainer project. This is a 0.1.0 first release with the usual single-maintainer and bus-factor exposure.
• You need providers beyond APNs/FCM — web push, HMS, etc. — or you need campaign tooling (segmentation, scheduling, analytics, A/B). That last category is OneSignal/Braze/Airship; this is transport, not marketing automation.
• Your stack is PHP < 8.4 or Laravel < 12, with no near-term upgrade.
• You are already well served by the incumbent laravel-notification-channels push channels: more mature, though less opinionated about multi-app config, shared connections, and cross-worker token caching — that difference is the actual buy decision.
• Security review of private key / service-account JSON handling is a precondition and cannot be completed against an early 0.1.x package.

How to Pitch It (Stakeholders)

Executives. Push notifications are a solved problem; the integration work is not. This package removes the undifferentiated glue — per-app credential handling, connection and token reuse across queue workers, dead-token cleanup, test doubles, and a credential smoke-test command — so the team spends its budget on which notifications to send and to whom, not on signing JWTs. It also makes the multi-app/multi-brand path cheap: adding an app becomes a config entry, not a project. The caveat is maturity, and it is a real one: this is a 0.1.0 first release, it requires PHP 8.4 and Laravel 12/13 (narrow today), and it is not yet fully installable from Packagist. Recommendation: a timeboxed spike on one non-critical app, with a go/no-go once the core dependency is published — not a platform-wide commitment.

Engineering. It is a thin Laravel binding over aporat/push-notifications. The wins are ergonomic config (one array entry per app; secrets-manager-friendly values), process-lifetime clients that suit queue workers, a shared token cache via any Laravel cache store, a notification channel that groups targets by app and sends concurrently, typed events for sent/failed/unregistered, optional sandbox retry for dev-build tokens, and first-class fakes plus php artisan push:test. The costs are equally concrete: PHP 8.4+/Laravel 12–13 only, pre-1.0 API, and a core dependency not yet on Packagist (note the path-repository entry in the package's own composer.json). Mitigate cheaply: pin versions, wrap Push::app() behind a small internal interface, and keep the DeviceTokenUnregistered listener provider-agnostic so replacing transport later is a contained change rather than a migration.