Notificato Laravel Package

Product Decisions This Supports

• Build vs. buy for notification delivery: Notificato is a datapoint for the "buy" side of the ledger — it shows that a focused, MIT-licensed push library can cover APNs delivery, certificate handling, and feedback/queue semantics without custom code. Use it to size the engineering effort you avoid, then compare against what a maintained equivalent costs today.
• Legacy portfolio triage: If the package already appears in an existing PHP/Laravel codebase (check composer.lock and transitive deps), this assessment supports a sunset-and-migrate decision rather than an upgrade decision. Archived status plus a 2019 final release makes it a known liability on the maintenance roadmap.
• Architecture reference, not a dependency: The library's structure — payload construction, per-device feedback handling, retry/backoff around a queue — is a useful spec for how you want your own notification service (or a managed provider like FCM/OneSignal/SNS) to behave. Treat it as a design artifact for the notification-reliability epic.
• Vendor and channel evaluation: Informs the choice between a PHP-native channel package (e.g., laravel-notification-channels/*), a managed push vendor, and in-house delivery. It also frames the channel abstraction decision: notifications as a first-class domain event vs. ad-hoc calls scattered across jobs.
• Roadmap framing for notification reliability: The existence of a dedicated feedback-service component is a reminder to product-plan for token invalidation, uninstall cleanup, and delivery analytics — features that are easy to defer and expensive to retrofit.
• Do not use it to support: a new feature launch, any iOS release targeting modern APNs, or any Android push work. The protocol generation it implements is obsolete (see below).

When to Consider This Package

Consider it only in these narrow cases:

• You are auditing a legacy PHP application that already depends on it, and you need to understand its behavior before replacing it.
• You need a read-only reference implementation of push payload construction, certificate rotation, and feedback-service polling for a design document or migration plan.
• You are doing a short, time-boxed spike (hours, not days) to establish a performance/behavior baseline for a build-vs-buy comparison.

Look elsewhere — decisively — when any of the following hold:

• New build. The APNs binary provider API and its feedback service were retired by Apple (binary protocol deprecated in favor of HTTP/2 + JWT-based token auth). A library last released in 2019 almost certainly targets the retired interface. GCM, the Android counterpart for this era, was likewise shut down in favor of FCM. This is not a maintenance gap; it is a functional dead end.
• You need security or compliance assurance. An archived repo with no maintainer means no CVE response, no dependency updates, and no support path for a security review. Certificate-handling code is exactly where you cannot accept that.
• Modern runtime requirements. PHP 8.x, Laravel 10+, and current TLS/cipher expectations are unlikely to be covered by a 2019 release.
• Ecosystem signal matters. Zero dependents on Packagist is a strong negative indicator: no downstream users means no incidental bug reports, no compatibility PRs, and no community pressure to keep it working.
• You need scale or observability. No evidence of batching, connection pooling, delivery metrics, or structured failure handling at the level a production notification pipeline requires.
• Your team is small. Absorbing an unmaintained dependency means you inherit ownership of it. Budget for that explicitly or don't take it on.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated Notificato, a small open-source PHP library for sending mobile push notifications. It is free (MIT), focused, and its design is sound for its era. However, it was last released in 2019, the repository is archived, and the Apple and Google push interfaces it was built against have since been retired. It has no downstream users and no maintainer. Recommendation: do not introduce it into any product, and if we already depend on it, schedule a migration. The cost of replacing it is small and bounded (roughly one engineering sprint for a typical Laravel service); the cost of an unmaintained, non-functional dependency in our notification path is not.

For engineering leads: This is a reference, not a dependency. We get more value extracting its patterns — payload shaping, feedback/queue handling, token lifecycle — than its code. The concrete blockers: obsolete APNs binary protocol (retired by Apple), obsolete GCM (retired by Google), no PHP 8 / modern framework coverage, no maintainer for security response. If we need a PHP-native path, evaluate a maintained notification-channel package or a managed provider instead. If you want to keep momentum, spend one day turning the library's feedback-service model into acceptance criteria for whatever we build or buy next.

For product/roadmap: Treat push notifications as a first-class capability with an owner and an SLA, not a utility call buried in a job. The lesson from packages like this is that delivery reliability, token invalidation, and uninstall hygiene are product requirements that quietly rot. Fund them once, correctly, on a maintained foundation.