- Can I install richsage/rms-push-notifications-bundle in a Laravel application?
- No. This is a Symfony2 bundle, not a Laravel package: there is no ServiceProvider, no publishable config file, no facade, no Illuminate\Notifications channel, and no queue or job wiring. Its integration contract is Symfony's ContainerBuilder, DependencyInjection\Extension, and Bundle registration, which Laravel never executes. Making it work would mean hand-building a shim in a service provider to reconcile two different container and lifecycle models. Treat it as a stop condition rather than a tradeoff.
- Which Laravel versions does this package support?
- None. The codebase uses Symfony 2.x-era idioms for a framework that has been end-of-life since November 2018, and it predates modern PSR code style. There is no Laravel version matrix, no CI matrix, and no test surface to validate against Laravel 8, 9, 10, or 11. Any compatibility claim would be aspirational rather than tested.
- Is richsage/rms-push-notifications-bundle still maintained?
- No. The repository is archived with an explicit NOT MAINTAINED marker and has zero dependents. There is no visible CI or test suite, no upstream owner shipping fixes, and no CVE feed to monitor. Adopting it transfers one hundred percent of maintenance to your team, with no community forks to inherit from.
- Does this bundle support Firebase Cloud Messaging (FCM) HTTP v1?
- No. Its Android path targets GCM and C2DM, both of which have been retired: C2DM was shut down years ago and GCM was superseded by the FCM HTTP v1 API in 2019. Writing code cannot fix this, because the remote endpoints no longer exist. For FCM today you need the HTTP v1 API with OAuth2 service account credentials.
- Does it support modern APNs with .p8 JWT tokens over HTTP/2?
- No. The iOS path uses the legacy binary provider protocol with certificate-based authentication, not the current APNs HTTP/2 provider API with .p8 key-based JWTs. APNs is the only transport in this bundle that is conceptually still alive, and even that path is the outdated implementation. A production iOS integration today should use the token-based HTTP/2 API.
- Which push notification providers does the bundle support?
- The documented transport list is iOS APNs, Android GCM and C2DM, BlackBerry BIS and BES, and Windows Mobile MPNS. Four of those five are provider-dead: C2DM was retired, GCM was replaced by FCM HTTP v1, BlackBerry services were discontinued, and MPNS was retired. Only APNs remains reachable, and only in its legacy form.
- Does the bundle work with Laravel queues for batched delivery?
- No. The bundle advertises queued or batched delivery for large device lists, but that concept is implemented against Symfony's service container and has no integration with Illuminate\Queue, dispatchable jobs, or Laravel's worker lifecycle. You would have to build the queue wiring yourself on top of a package you are already maintaining alone. The advertised batching is not a reason to overlook the missing framework integration.
- Is it safe to put an archived package like this in production?
- The MIT license is permissive and unproblematic, but licensing is not the risk here; ownership is. There is no upstream maintainer, no security advisory feed, and no patch path if a transport or dependency is compromised. For the notification path specifically, an archived dependency is a poor place to carry that exposure. The safer policy is a one-line rule against archived packages on the notification path.
- What should I use instead for push notifications in Laravel?
- Use actively maintained options: Laravel's built-in notification system with a community notification channel for FCM, a maintained FCM SDK such as kreait/firebase-php, and a current APNs HTTP/2 library for iOS. If you need multiple platforms behind one API, define your own PushSender or PushChannel contract with one driver per platform bound through a Laravel manager or factory. That keeps drivers swappable and avoids coupling your domain code to any single vendor package.
- Is there any legitimate reason to evaluate this package at all?
- Yes, but only as design prior art, never as a dependency. The bundle is a useful catalog of what a multi-provider push abstraction looks like: driver per platform, a message DTO, a device token store, and a stale-token feedback loop. Harvest that contract shape and discard the implementation. Frame the deliverable as a requirements input for an internal build or vendor RFP, and record the decision in an ADR so it is not re-proposed when someone searches for push notification packages and sees the star count.