Pushok Laravel Package

Product Decisions This Supports

• Apple-platform roadmap unblocking. If any near-term initiative requires reaching iOS, macOS, watchOS, or tvOS users — release announcements, transactional alerts, re-engagement, order status — this package is the transport primitive that makes those features shippable in a PHP/Laravel backend rather than a reason to replatform.
• Build vs. buy at the transport layer. Implementing APNs directly means ES256 JWT signing, provider-token refresh, HTTP/2 connection handling, 410 Unregistered cleanup, and APNs' error taxonomy. This package collapses that to days of integration work. The decision it informs is "do we spend engineering weeks on a solved problem, or spend them on product?"
• Feature-class gating. The stated support for silent/background notifications and VoIP is a roadmap lever: it determines whether background data refresh, badge-only updates, and PushKit-based calling are feasible now versus requiring a vendor. Treat "VoIP push supported" as a decision input for any calling or real-time initiative.
• Scope honesty for infra planning. This is a client, not a notification platform. It does not persist device tokens, manage user preferences, fan out across segments, schedule sends, or report delivery analytics. Confirming that gap is itself a product decision: it tells you whether you need a managed provider layered on top, or whether you own that pipeline internally.
• Cost and data-residency posture. Sending directly to APNs avoids per-subscriber vendor pricing and keeps device tokens and payload content inside your infrastructure — relevant at low-to-moderate volume and under privacy or compliance review.
• Sequencing and MVP scoping. Because it is framework-agnostic and lightweight, it supports a thin MVP (single notification type, production only) with a deliberate path to add sandbox testing, categories, and richer payloads later.

When to Consider This Package

Consider it when:

• The backend is PHP/Laravel and there is a first-party or contracted Apple app to notify.
• The team is willing to operate the surrounding pipeline — token registry, retry/backoff, handling of invalid-token responses, queueing before send.
• Volume is modest enough that a queue plus a client is cheaper and simpler than a vendor contract, or data must stay in-house.
• You want a narrowly scoped dependency rather than adopting a full engagement platform.

Look elsewhere when:

• No Apple surface exists — Android/web-only work belongs with FCM or web-push tooling.
• The requirement is multichannel orchestration, templating, journey building, A/B testing, or delivery analytics. That is a platform, not a client; managed providers (OneSignal, Airship, Braze-class) or an in-house service is the better comparison.
• You need a contractual SLA or vendor support. A ~400-star, single-maintainer MIT package carries maintenance and bus-factor risk; check recent release cadence and issue responsiveness before committing.
• Backend is Node, Go, Java, or Python — native APNs libraries exist and the PHP client adds a service boundary for no gain.
• Very high fan-out where connection pooling, sharding, and throughput tuning become the dominant problem.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed, free dependency that lets our PHP backend deliver push notifications directly to Apple devices across iOS and macOS. It removes the main technical blocker between our roadmap and our Apple users, at no licensing cost and with no per-notification vendor fees — device data stays ours. The trade-off is operational: we own token management and delivery monitoring, and the library is community-maintained, so we should budget modest ongoing engineering attention rather than assume enterprise support. Net: a low-cost accelerator for Apple-platform features, not a complete notification solution.

For engineering: Provides HTTP/2 APNs transport with both JWT provider-token and certificate authentication, sandbox and production environments, a fluent builder for alerts, badges, sounds, and custom data, plus silent/background and VoIP payload support and explicit error responses for invalid tokens and payloads. It is framework-agnostic, so it needs a thin Laravel service-provider wrapper and our own device-token storage. Recommended implementation: wrap it behind an internal PushSender interface, run sends through the queue, handle expired/invalid tokens as a first-class cleanup path, and validate sandbox traffic before release. That interface also gives us a clean swap point to a managed provider if volume or SLA requirements change.