Apns Php Laravel Package

Technical Evaluation

Recommendation up front (revised): the critical blocker from the previous assessment is removed. duccio/apns-php v2.0.0-alpha speaks HTTP/2, so the package is no longer structurally incapable of delivering a notification. That is a material change and the "do not adopt under any circumstances" verdict no longer holds. The verdict is now hold for evaluation, do not production-adopt the alpha: pilot in staging, pin the exact pre-release, and gate any production use on a stable tag plus verified PHP 8 / curl-nghttp2 support. The package has moved from technically dead to technically viable but operationally unproven.

Architecture fit

• The architectural model is unchanged: a stateful, per-process client (ApnsPHP\Push) that you construct, connect, send, disconnect. HTTP/2 improves the economics of that model considerably — one connection now multiplexes many notifications instead of one TLS handshake per worker — but it does not change the shape. There is still no Laravel service provider, config file, facade, notification channel, or queue integration; all wiring, credential handling, connection lifecycle, and token bookkeeping remain first-party work.
• The important architectural gain is that the per-process connection is now defensible. A long-lived queue worker holding one HTTP/2 connection is a reasonable pattern, whereas the binary-era serial socket per request was not. That makes the package compatible with Horizon-style worker pools in a way it previously was not.
• The modern APNs feature surface is now reachable but not demonstrably implemented. HTTP/2 transport is a prerequisite for apns-topic, apns-push-type, apns-priority, apns-collapse-id, 4 KB payloads, and per-notification response codes — it is not a guarantee that the library exposes them. VoIP, critical alerts, Live Activities, and background pushes all depend on header control and correct push-type declaration, so these must be verified in code, not assumed from the release note.

Integration feasibility

• Installation remains trivial and the licence remains permissive (BSD-3-Clause), so forking and internal patching are legally clean. That matters more now: an alpha release is a plausible fork candidate if the maintainer goes quiet again.
• The new hard prerequisite is an environment constraint: PHP's curl extension must be built against a curl with HTTP/2 (nghttp2) support. This is satisfied on most current distro and container images but is not universal, particularly on older base images, Alpine variants without the right build flags, or where curl was compiled against a bundled OpenSSL without nghttp2. This must be verified per environment (local, CI, staging, production) before any estimate is credible. It is a one-line check and a potentially multi-day platform fix.
• The second new constraint is credential work: the release explicitly states the binary-era certificate cannot be reused and a new one must be generated. That is a forced, non-optional task involving Apple Developer Portal access, per bundle ID, per environment, with a named owner outside engineering.
• PHP 8 compatibility is the unresolved question. The release note says nothing about supported PHP versions, and the previous release was 2016. An HTTP/2 rewrite is a plausible occasion for a PHP 8 modernization, but "plausible" is not "verified" — this needs to be confirmed against actual composer constraints and a real test run on your pinned Laravel PHP version.
• Alpha status is itself an integration consideration: composer require needs an explicit stability flag, the version must be pinned exactly, and the public API may change before stable. Budget for one breaking-change cycle.

Technical risk

• Critical / certain: legacy binary provider API is shut down. Resolved by v2.0.0-alpha. This was the single blocking risk and it is gone.
• High (new): pre-release stability. 2.0.0-alpha signals an API that may change, incomplete feature coverage, and unknown test depth. There is no track record of this code path in production anywhere you can observe.
• High (unchanged in kind, reduced in degree): maintainer velocity and credibility. A single alpha after a nine-year gap does not establish a sustainable release cadence, a security-response process, or a support path. The next Apple-side change may again go unanswered for years.
• High: certificate-only authentication persists. The release note instructs you to generate a certificate, which means the package still does not implement .p8 provider keys with JWT — Apple's current recommendation. Certificate rotation remains a recurring manual operational task with hard expiry failure, and the new-certificate requirement means you inherit that burden immediately rather than inheriting an existing credential.
• Medium: response-code handling is unverified. HTTP/2 delivers per-notification status including 410 Unregistered and BadDeviceToken. Whether the library surfaces these to the caller determines whether token hygiene is a small adapter or a rebuild. Treat the feedback-service replacement as still outstanding until proven otherwise.
• Medium: payload ceiling and header support are unverified. 4 KB should now be achievable; whether the message-building API exposes apns-* headers and enforces the new limit correctly needs a code read, not a changelog read.
• Low–Medium: documentation lag. The linked Apple reference is the pre-HTTP/2 "Universal Push Notification Client SSL Certificate" guide, which suggests the docs were not rewritten alongside the transport. Stale docs on a fresh transport layer is a reliable source of integration mistakes.

Key questions

• Is this greenfield or remediation? The answer is no longer automatically "no" for greenfield, but greenfield adoption of an alpha is still a hard sell against a mature HTTP/2 client.
• Does v2.0.0-alpha declare PHP 8.x support in composer.json, and has anyone run it on your pinned Laravel/PHP version?
• Do your local, CI, staging, and production images have curl with HTTP/2 (nghttp2) compiled in? This is the fastest disqualifier and should be checked first.
• Does the library expose apns-topic, apns-push-type, apns-priority, and apns-collapse-id, and does it return per-notification status codes to the caller?
• Is .p8 JWT provider-token auth on the maintainer's roadmap, or is certificate auth the permanent design?
• What push classes are in scope — alert, background, VoIP, critical, Live Activities — and does the new transport actually cover them?
• What is the maintainer's stated commitment level for the 2.0 line: is there a stable-release target date, a CI matrix, and an issue-response history since the alpha tag?
• Who owns Apple Developer Portal access and certificate issuance for the new certificate, and what is the lead time?
• Current volumes, fan-out per event, and peak burst rates — unchanged, but now the answer informs "queued HTTP/2 client" versus "managed provider" rather than "anything but this package."

Integration Approach

Stack fit

• Now a legitimate candidate rather than a non-starter. It is still not a Laravel-native package, so the integration shape is unchanged: wrap it behind a first-party interface so the rest of the application never sees ApnsPHP\* types.
• Evaluate it against edamov/pushok and aporat/php-apns on three axes that matter more than raw features: JWT .p8 support, per-notification response-code surfacing, and release cadence. If those two do the same job on a stable tag, the alpha's only advantage is that you may already have the dependency and the message-building code.
• The strongest argument for this package specifically is incremental migration: if you have existing binary-era code, v2.0.0-alpha may let you keep your message construction and call sites while swapping the transport. That is a real schedule win and the main reason to evaluate it seriously rather than dismiss it.

Migration path

1. Verify the floor before planning. Confirm curl-with-HTTP/2 on every environment and confirm PHP 8 support from composer.json and a smoke test. Both are cheap; either can invalidate the whole plan.
2. Abstract first. Define PushSender::send(DeviceToken, PushMessage): DeliveryResult in the application domain. This is non-negotiable regardless of which library wins — it is what makes the alpha's instability survivable and what makes a later swap to a stable client or a managed provider a configuration change.
3. Issue the new certificate. Parallel-run window: old certificate remains valid for the legacy path, new certificate issued and deployed for the HTTP/2 path. Separate owners, separate workflows, and the usual source of schedule slippage.
4. Adapter spike, time-boxed. Implement ApnsPhpHttp2Sender behind the contract and send to Apple's sandbox. Success criteria: a real alert push arrives; a deliberately invalid token returns a distinguishable 410/BadDeviceToken; a 4 KB payload is accepted; a background push with the correct apns-push-type is accepted. If any of these requires patching the library, that is a fork decision, not a spike outcome.
5. Token hygiene pipeline. Replace any feedback-service polling with a queue consumer that reacts to per-notification failure codes and expires tokens in your own store. Build this regardless of which sender wins; it is the piece most likely to be missing from the library.
6. Canary. Internal testers, then 1–5% of tokens, behind a feature flag keyed by bundle ID and token cohort. Never dual-send to the same token outside staging — duplicate notifications are user-visible.
7. Decide at the gate. Promote to production on the alpha only with explicit sign-off on maintainer risk and a documented exit path to a stable client or a vendored fork. Otherwise absorb the learning into the abstraction and switch the binding.
8. Decommission. Remove the binary path, the adapter, and any stored legacy certificate credentials; revoke unused certificates in the portal.

Compatibility

• PHP: unverified. This is the top compatibility unknown and should be resolved from composer.json before any estimate.
• curl/OpenSSL: HTTP/2 requires nghttp2-linked curl. Version skew between local dev and production base images is the likely failure point.
• Credentials: certificate-based only. Plan for a new certificate per bundle ID and a rotation calendar from day one, since the old one cannot be reused.
• Payloads: audit builders for the old 2 KB assumption; verify the library enforces or permits 4 KB. Check for APS keys the new path may validate more strictly (content-available, mutable-content, thread-id, apns-*).
• Feedback: no feedback service in HTTP/2. Any existing polling loop is dead code that must be deleted, not ported.

Sequencing

• Day 1–2: HTTP/2 curl verification and PHP 8 confirmation. Go/no-go on the alpha before anything else.
• Week 1: inventory call sites, credential types, and push categories; write the ADR comparing this alpha against a stable HTTP/2 client; initiate certificate issuance (longest lead time, start it immediately).
• Weeks 1–2: PushSender contract + adapter spike against sandbox + the four acceptance criteria above.
• Weeks 2–3: token hygiene consumer, observability, feature-flagged canary.
• Week 4: cutover per app, then removal of the legacy path and credentials. Hold one sprint of slack for Apple portal permissions and certificate procurement.

Operational Impact

Maintenance

• Materially better than the previous assessment but not solved. If the 2.0 line is genuinely maintained, you inherit a normal dependency relationship: periodic updates, occasional breaking changes during the alpha-to-stable transition, and a security path. If the maintainer goes quiet again, you are back to owning a fork — this time a fork of an HTTP/2 client, which is more code and more surface than the binary one.
• The recurring certificate rotation burden is now higher than the previous assessment implied, because the new certificate requirement means you start the rotation clock immediately rather than inheriting a working credential. Token-based .p8 auth would eliminate this; the package does not offer it.
• The alpha tag is a standing maintenance obligation: exact version pinning, a documented upgrade checkpoint at stable, and a plan for the API break that a 2.0.0 stable will likely carry.

Support

• Diagnosis improves significantly. HTTP/2 returns a JSON reason per rejected notification, so "notification not received" tickets become traceable in a way the binary protocol never allowed — provided the library surfaces those codes to your adapter. If it swallows them, you have gained transport modernization without gaining observability, which is the worst of both.
• On-call runbooks must now cover: curl/nghttp2 availability after base-image changes, certificate expiry and the new-certificate workflow, Apple endpoint connectivity over HTTP/2, TLS handshake failures, and the token-invalidation backlog. The endpoint-connectivity risk changes character — instead of "always down," it becomes "down after a platform upgrade," which is easier to fix and easier to miss.
• Runbooks and dashboards for the canary period should be built before the canary, not after; the first HTTP/2 rollout is where connection-lifecycle bugs surface.

Scaling

• Genuinely improved. HTTP/2 multiplexes many notifications over one connection, so throughput scales with connection reuse rather than with worker count and handshake rate. Broadcast workloads that were wasteful under the binary model become tractable.
• Caveats: one connection per PHP process still means worker-pool-sized connection counts, and Apple applies per-connection and per-token rate limits. Batch and chunk jobs to keep queue latency predictable and avoid holding a live connection inside a web request.
• Capacity planning should be based on provider-side limits and connection reuse, not on Horizon worker counts. This is a change from the previous guidance and worth calling out to whoever owns queue sizing.

Failure modes

• curl built without nghttp2 — hard failure at connect, environment-specific, and the single most likely surprise. Verify before committing.
• Certificate expired or revoked — authentication failure across every bundle ID using that certificate; now also applies to the newly issued certificate, so the rotation calendar starts at cutover.
• Alpha regression or API break on upgrade — unannounced behavior change in the send path; mitigated only by pinning and by the abstraction layer.
• Response codes not surfaced — stale tokens accumulate silently, sends are wasted, metrics inflate, and there is no pruning mechanism because the feedback service no longer exists.
• Payload over the enforced ceiling — truncation or rejection depending on how the library validates; verify the limit rather than assuming 4 KB.
• PHP or OpenSSL upgrade on the host — fatal errors or subtle TLS misbehavior in a code path that is exercised only on send.
• Duplicate sends during any dual-run — user-visible and reputationally costly; enforce single-send per token by construction, not by convention.
• Stale documentation — engineers following the linked pre-HTTP/2 Apple guide will misconfigure certificates. Write internal docs; do not link the vendor's.

Ramp-up

• Learning curve for the package itself remains low (hours): small API, readable source, permissive licence.
• Learning curve for HTTP/2 APNs specifics is the real cost (days to a sprint): connection lifecycle and reuse in long-lived workers, apns-topic mapping to bundle ID, push-type headers per notification class, response-code handling, and token lifecycle without a feedback service. This knowledge is portable across every client library and every future platform, which is a better return on the investment than the binary-protocol knowledge it replaces.
• Staffing implication: one backend engineer can own the contract, the adapter, and the cutover. The critical non-engineering dependencies are Apple Developer Portal access for the new certificate, a named owner for the rotation calendar, and QA device coverage across iOS versions for the canary cohort.
• Team communication: the previous assessment's "this is dead, do not evaluate it" message is now wrong and needs an explicit correction, or engineers will dismiss a viable option and stakeholders will lose trust in future assessments on this package.