Apns Php Laravel Package

Product Decisions This Supports

• Push notification feature scoping (iOS): Still the gating question — can we ship iOS push on the current stack, and at what effort/risk? The v2.0.0-alpha release removes the hardest blocker: the package now speaks HTTP/2 instead of Apple's retired binary provider protocol. That changes the answer from "not with this, the transport is dead" to "only if we accept alpha-quality code we must own." The PM decision shifts from a categorical no to an explicit risk trade-off.
• Build vs. buy vs. adopt: The "adopt" branch is now partially open, but it is adopt-an-alpha, not adopt-a-library. One pre-release, no stable v2, no maintainer commitment, still zero dependents, no semver guarantee, and the upgrade path from v1 requires regenerating certificates. Treat this as fork-and-own with a head start, not adoption.
• Migration planning for existing integrations: This is the most concrete change. If a team is already on the binary protocol, v2.0.0-alpha is a plausible interim bridge rather than a forced rewrite — but it is a bridge to a bridge, not a destination. The deprecation epic becomes: if HTTP/2 is the only blocker, evaluate the alpha behind a feature flag; otherwise proceed to a maintained client.
• Platform/standards alignment: Two hard prerequisites now surface as platform requirements, not nice-to-haves: the PHP cURL extension must be compiled with HTTP/2 support, and the Universal Push Notification certificate must be regenerated (the binary-era certificate cannot be reused). Both are environment-provisioning and secrets-rotation work items with lead time — worth confirming before committing to any timeline.
• Auth model / compliance review: Unchanged and still a gap. HTTP/2 support does not imply token-based auth. The release notes reference certificates, so .p8 JWT tokens, short-lived credentials, and per-notification auth remain unaddressed. The rotation and blast-radius concerns from the prior assessment stand.
• Capability checklist for a replacement: v2.0.0-alpha is now a better reference spec — it demonstrates HTTP/2 connection handling on top of the existing payload builder and error taxonomy. The apns-push-type (mandatory since iOS 13), apns-priority, apns-collapse-id, apns-expiration, and apns-id correlation gaps still need to be verified against the source; do not assume the transport change closes them.
• De-scoping option: Weaker than before. "The transport is dead" is no longer a clean argument. If push is not a near-term roadmap item, the honest justification is now capacity and ownership, not technical impossibility — defer on those grounds and say so.

When to Consider This Package

Consider it in these narrow cases:

• Time-boxed bridge for an existing binary-protocol integration. The team is already on v1, the only blocker to staying is HTTP/2, and the work is a contained, feature-flagged swap to the alpha ahead of a planned move to a maintained client. Cap the investment and set an explicit expiry date.
• Air-gapped / frozen-environment constraints. A legacy PHP runtime that cannot take new Composer dependencies, now with the added requirement that its cURL is built with HTTP/2. Validate that first — if it is not, this package is no better than v1.
• Fork base. You intend to vendor the alpha, own it, and add JWT auth and modern headers yourself — accepting a named maintainer and an ongoing patch burden.
• Reference reading. Understanding HTTP/2 APNs connection handling, payload structure, and error responses while building or evaluating a replacement — no runtime dependency.

Look elsewhere when any of the following hold — which remains the default:

• Greenfield or new feature work. The only v2 artifact is an alpha. Shipping customer-facing notifications on an unmaintained project's pre-release is not a defensible risk posture. Use a maintained HTTP/2 client (a current edamov/pushok-style library, laravel-notification-channels/apn, or a managed provider) behind a Laravel notification channel.
• You need modern APNs capabilities: apns-push-type (mandatory for iOS 13+), apns-priority, apns-collapse-id, apns-expiration, per-notification JWT .p8 auth, multiplexing behaviour, response apns-id correlation. The release notes only claim HTTP/2 transport — verify each of these in source before assuming any of them.
• Security/ops posture matters: The release still centres on certificates, and now requires issuing a new one. Token-based auth with short-lived JWTs and no per-device credential files remains the better governance choice.
• Framework integration is expected. Still framework-agnostic despite the "Laravel/PHP" framing — no service provider, no config publishing, no queue integration, no notification channel.
• Test/CI and toolchain expectations: PHP 8.x compatibility, PSR-4 autoloading, static analysis, and modern PHPUnit are still not guaranteed. An alpha on a project dormant since 2016 does not establish a supported matrix.
• Support and CVE exposure: Unchanged. No stable release and no maintainer commitment means no security patches; adoption is a fork-and-own commitment regardless of the protocol upgrade.

How to Pitch It (Stakeholders)

To executives: The headline objection is gone — a new alpha release adds HTTP/2, the transport Apple actually supports. What has not changed is the risk profile: this is a pre-release of a project with no stable release since 2016, no dependents, and no maintainer commitment. So the recommendation softens but does not reverse: do not adopt for new work; if we already run the binary protocol, the alpha is a possible short-term bridge, not a destination. Either way we fund a contained migration to a maintained HTTP/2 client, and either way we need a certificate reissue and a cURL-with-HTTP/2 verification on our runtime — both with lead time. The cost stays bounded and the unpatched-dependency problem stays on the security register until the migration lands.

To engineering: v2.0.0-alpha is a genuine step — HTTP/2 connection handling on top of the existing payload builder and error taxonomy. Treat it as reference material and, at most, a feature-flagged stopgap. Before anyone plans around it, confirm three things in source: cURL HTTP/2 availability on our runtime, whether JWT .p8 auth exists or it is still certificate-only, and whether apns-push-type / priority / collapse-id headers are actually emitted. If any of those are missing, the gap list versus a maintained client is unchanged and the decision is a straight replace. The migration epic stays the same shape: new client behind a Laravel notification channel, token-based auth, modern headers, retry/observability on APNs response codes — gated on the same delivery tests the old client passed, plus a certificate rotation runbook.

Ask: Confirm (a) whether the current system still sends via the binary protocol, and (b) whether our PHP runtime's cURL has HTTP/2. If yes to both, the alpha is an option worth a time-boxed spike — assign an owner and an expiry. If HTTP/2 is unavailable or the alpha lacks modern-header/JWT support, proceed directly to a maintained client. Record the decision and the alpha's expiry in the architecture decision record either way.