Native Push Laravel Package

Product Decisions This Supports

• Build vs. buy on push infrastructure: this package makes "build on the platform's own push credentials" a credible alternative to buying OneSignal, Airship, Braze, or Firebase Cloud Messaging-as-a-service. The decision it unlocks is whether to pay a vendor per-subscriber/per-message or own the APNs .p8 key and FCM service account directly.
• Mobile companion app roadmap: push is table stakes for the native apps produced by akyos/ux-native-cli --notification; this is the notification backbone for that toolchain, so it directly gates any roadmap item that assumes re-engagement (order updates, alerts, transactional events, deep links back into the app).
• Data-sovereignty / GDPR posture: device tokens and message payloads never transit a third-party processor. This is a decision input for legal and security review, not just engineering.
• Feature scoping — native push vs. lifecycle messaging: the package covers delivery (send, token hygiene, deep link) but not campaigns (segmentation, scheduling, A/B tests, analytics dashboards). That cleanly separates "we need notifications" from "we need a marketing automation platform," which are frequently conflated in roadmap discussions.
• Staged platform rollout: iOS and Android are optional and independent, so shipping on one platform first is a configuration choice rather than a re-architecture — useful when App Store review or an Android release slips.
• In-house vs. hosted device registry: PushDevice storage with deduplication, automatic reassignment, and dead-token pruning is a real piece of product logic (multi-user devices, reinstalls, hand-me-down phones). Keeping it in your own database means you can join it against your user model for support and reporting.

When to Consider This Package

Adopt when:

• You are on a Laravel/PHP stack already using Symfony Notifier and are comfortable with its Transport/Notifier abstractions (this is a native-push://default transport, not a standalone SDK).
• Your recipients are Doctrine entities implementing PushSubjectInterface — the package's user model is Doctrine-centric. Teams running pure Eloquent models should treat ORM fit as an explicit spike item before committing; a thin adapter might be trivial or might be a real cost, and that should be proven, not assumed.
• You are already using the Akyos native app generator, or your apps are set up to consume url() deep links.
• You want to avoid a third-party push vendor for cost, latency, or data-protection reasons, and you are willing to own the operational side: .p8 key rotation, FCM service-account secrets, APNs HTTP/2 connectivity, and certificate/credential expiry monitoring.
• Your volume and complexity are modest: transactional and engagement notifications to a known user base, not high-frequency fan-out with segmentation.
• You value the included operational surface — POST/DELETE /native-push/devices, the Stimulus controller, and the check / test / send / devices commands — as a meaningful reduction in glue code.

Look elsewhere when:

• You need campaign management, scheduling, audience segmentation, A/B testing, or delivery analytics. None of that is here; a vendor is the correct buy.
• You need web push, in-app inboxes, notification history/read state, or cross-channel orchestration (email + SMS + push in one journey).
• You are not on Laravel/Symfony, or you need a framework-agnostic client.
• You require enterprise support terms, SLAs, or a large maintainer community. This is a v1.0.0 from a single agency; bus factor and long-term maintenance should be priced in.
• Your compliance model requires vendor-provided audit trails, or conversely, you cannot store tokens yourself.
• You need guaranteed delivery semantics, retries with backoff, or provider failover — verify what happens on APNs/FCM 5xx and rate limits before assuming.

Adoption risks to price in: first stable release with no prior public assessment, so treat the API as stabilizing rather than frozen; push cannot be meaningfully tested in CI without real devices or provider sandboxes; and the operational ownership of credentials is a permanent, recurring cost, not a one-time setup.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, focused library that lets our applications send native iOS and Android push notifications directly through Apple and Google, using our own credentials, with no third-party push vendor in the middle. It removes a per-subscriber subscription line and a data processor from our stack, keeps device data inside our own systems, and it arrives with the plumbing already built — device registration endpoints, token cleanup, and admin commands — so the incremental engineering effort is small. The trade-off is that we take on credential management and we forgo the campaign tooling a vendor would bundle. My recommendation is to adopt it where we need straightforward notifications and deep links, and to keep a vendor on the table only if marketing-led campaigns become a near-term requirement.

For engineering (the short version): Standard Symfony Notifier transport (native-push://default) over APNs HTTP/2 with a .p8 key and FCM HTTP v1 with a service account. Entities opt in via PushSubjectInterface + PushSubjectTrait. Ships device persistence with dedupe, reassignment, and dead-token removal, plus a url() deep link, optional device endpoints, a Stimulus controller, and four Artisan/console commands. Because it sits on the Notifier abstraction, the transport is swappable — so the lock-in is low and the decision is reversible. Two things to validate in a spike: the Doctrine-entity assumption against our actual models, and our on-call story for expired Apple/Google credentials.