Rms Push Notifications Bundle Laravel Package

Product Decisions This Supports

• It does not support feature or roadmap decisions. This repository is archived ("NOT MAINTAINED"), has 0 dependents, and its transport layer is entirely obsolete. It should never appear on a build-vs-buy comparison for anything shipping in the next 12+ months. Treat it as a historical artifact, not a candidate dependency.
• It informs scope for a notification layer you will build or buy. The genuinely reusable output is architectural shape: a provider abstraction over multiple transports, a device-token registration store, a message/fan-out concept, and per-platform payload adapters. That is the same decomposition to specify in your own PRD before choosing a vendor.
• It surfaces device-token lifecycle as a real product requirement. Reading it exposes the unglamorous work PMs routinely under-specify: token registration on login, refresh on app launch, de-registration on logout, pruning after provider feedback, and per-user multi-device fan-out. Concrete input to requirements, not code to reuse.
• Build vs. buy — with the answer pre-written. Its transport list (iOS binary APNs, Android C2DM and GCM, BlackBerry, Windows Mobile toast) is a cautionary tale: 100% of it is dead. That is the strongest available argument for delegating transport to a managed service (FCM/APNs via OneSignal, SNS, Pusher Beams, or Expo) rather than owning per-platform protocol code in-house.
• Technical-debt inventory and migration sizing for legacy estates. The package is a Symfony2 bundle, not a Laravel package — its presence in a dependency tree is a signal that the surrounding application predates 2014 and that the notification path is a known risk area. That drives a replacement decision and a rough sizing conversation.
• Vendor/fork risk assessment. MIT licensing is permissive and unproblematic, but "archived" means no security patches, no PHP-version compatibility work, and no response to provider API changes. The decision it most directly supports is fork-and-own it, or retire it — never adopt it.

When to Consider This Package

Consider it only in these narrow cases:

• You maintain an application that already depends on it, pinned to Symfony 2.x and an old PHP runtime. Even then, treat it as frozen: fork internally, pin the version, assign an owner, and log a retirement date.
• You need prior art for a multi-provider push abstraction and want to read someone else's attempt before designing your own interfaces. Read the source; do not add it to composer.json.
• You are writing a migration or replacement plan and need to enumerate what the current system does — the platform list works as a checklist of transports to confirm dead before deletion.

Look elsewhere — decisively — if any of the following are true (i.e., almost always):

• You are on Laravel. This is a Symfony2 bundle. It does not integrate with Laravel's service container, notification system, queues, or config conventions. There is no service provider, no publishable config, no facade, no Illuminate\Contracts\* compatibility. Bridging it means bootstrapping a Symfony ContainerBuilder shim inside a Laravel provider — the cost exceeds writing the integration from scratch, and you would own the result anyway.
• You need any currently supported transport. C2DM was retired in 2012, GCM shut down in 2019 in favor of FCM, BlackBerry BIS and Windows Mobile toast are gone, and the legacy APNs binary interface has been superseded by HTTP/2 with .p8 token-based auth. Four of five transports cannot be fixed by patching — the remote services no longer exist.
• You need maintained PHP support, security patches, or upstream responsiveness. Archived + 0 dependents = zero maintenance signal and no downstream fork momentum to inherit.
• You want production push today. Use maintained options instead: kreait/laravel-firebase (FCM HTTP v1), Laravel's first-party notification channels, or a managed provider that owns APNs/FCM protocols on your behalf. For teams that must own the PHP side, a thin client over FCM HTTP v1 plus APNs HTTP/2 is a small, well-documented surface — far smaller than this bundle's footprint implies.

How to Pitch It (Stakeholders)

Executive summary (one paragraph): richsage/rms-push-notifications-bundle is an archived Symfony2 bundle for mobile push notifications, last useful roughly a decade ago. Every transport it implements is retired — C2DM, GCM, BlackBerry, and Windows Mobile are all shut down, and its iOS path predates Apple's current HTTP/2 API. It is not a Laravel package, has no dependents, and receives no maintenance. Recommendation: do not adopt. There is no licensing cost (MIT), but also no support, no security patching, and no viable code paths for modern iOS or Android. Its only residual value is as a design reference — a reminder of which concerns a notification layer must own (token lifecycle, multi-device fan-out, per-platform payload shaping, invalid-token cleanup).

For engineering: This is not a dependency proposal — treat it as a reading assignment and a checklist. Extract the interface boundaries (provider adapter, token store, message DTO, per-token result object) and discard the implementations. Replacement mapping is straightforward: APNs binary → APNs HTTP/2 with .p8 JWT; GCM/C2DM → FCM HTTP v1 with OAuth2 service account; BlackBerry and Windows Mobile → retire as sunset paths only; bundle service wiring → a Laravel service provider with drivers bound via a manager/factory. Design for PHP 8.x, PSR-18 HTTP clients, queue workers, and TLS 1.2+. If it appears anywhere in our tree, it flags a Symfony2-era service that needs a named owner and a replacement plan. Do not fork without that maintainer.

For product/roadmap: Push notifications are a buy, not build, decision for us. Owning per-platform transport code means absorbing every APNs and FCM API change, plus ongoing token hygiene and delivery-failure cleanup. Managed providers do that work and expose a stable API. The PM-level deliverable from this evaluation is a short requirements list — token registration/refresh/de-registration, multi-device delivery, per-platform payload differences, invalid-token pruning, delivery observability — to hand to vendor evaluation, not a ticket to integrate this bundle.

Risk if ignored: Low and contained. The risk is not "we lose a capability"; it is that someone unfamiliar with the project's age adds this to composer.json — as a "temporary" bridge no less — and we inherit a dead protocol stack with no maintainer and unbounded future patching. A one-line note in the dependency policy — no archived packages in the notification path — closes that gap.