- Is msouverain/rms-push-notifications-bundle compatible with Laravel?
- No. Despite being distributed via Composer, it is a Symfony 2-era bundle, not a Laravel package. The Bundle suffix, DependencyInjection extension, and Resources/config/services.yml bootstrapping are Symfony idioms, and there is no ServiceProvider, facade, or publishable config. Laravel's container can autoload the code, but it cannot bootstrap the bundle the way Symfony expects.
- Does this package still work with APNs and GCM today?
- No. The transport layer targets the APNs binary gateway, which Apple deprecated in 2021 in favor of HTTP/2 with JWT authentication, and GCM HTTP, which Google shut down in 2019 in favor of FCM v1. Even inside its native Symfony environment, this package cannot deliver a notification to a modern device today. Any adoption requires replacing both transport adapters.
- Can I install this Symfony bundle in a Laravel 10 or 11 application with Composer?
- It is likely to fail at composer require time. Laravel 10 and 11 ship symfony/* v6 and v7 components, while this package is Symfony 2 vintage, so Composer will probably hit an unsolvable dependency conflict. Run a throwaway Composer resolve against your target PHP and Laravel version first; if it fails, the decision is made for you and the spike ends in an hour rather than a sprint.
- What Laravel packages should I use instead for iOS and Android push notifications?
- Use laravel-notification-channels/apn and laravel-notification-channels/fcm. Both are actively maintained, Laravel-native, and use the same underlying transports you actually need today. Wire them into Laravel's built-in notification system rather than adopting a Symfony bundle. For a lower-maintenance route, outsource delivery to FCM, OneSignal, or Firebase and eliminate per-platform credential management.
- How would I fork or vendor this bundle into a Laravel project?
- Vendor the repository into packages/rms-push-notifications using a Composer path repository, then add a first-party PushServiceProvider. Delete and replace both transport adapters with APNs HTTP/2 token-based auth and FCM v1 with OAuth2 service-account credentials. Keep only the message-composition classes you can unit-test. The bundle's value is limited to thin message and device abstractions, so you are mostly buying naming conventions.
- Is this package maintained and safe to use in production?
- The technical risk is critical. It has zero stars, zero dependents, a single maintainer, no upstream activity, no CI badge, and no tagged release compatible with modern PHP. Symfony 2 code of this vintage often relies on Container::get() semantics removed in Symfony 3, pre-PSR-4 autoloading, and occasionally mcrypt. The MIT license is the one unambiguously positive signal because it permits a fork.
- Does it support device-token lifecycle management, feedback service, or stale-token pruning?
- The technical evaluation flags device-token lifecycle support as an open question rather than a confirmed feature. You need to verify whether it includes a feedback service, canonical ID handling, or pruning of stale tokens. If those are absent, you must build token lifecycle handling yourself. Certificate-based APNs authentication would also force manual annual credential rotation unless token-based auth is added.
- What PHP and Symfony versions does it require, and is it PSR-4?
- You must inspect composer.json directly, because the evaluation lists the exact constraints as a key question for the maintainer or spike. Check whether it is PSR-4 or pre-PSR-4, whether it depends on a separate rms/push-notifications library, and whether that library is maintained. Also look for mcrypt or openssl calls and whether credentials are read from a filesystem path, which is a secrets-management problem for containerized deployments.
- Does this package provide delivery receipts or per-message results?
- That is not confirmed and must be verified during the spike. The evaluation explicitly asks whether it exposes per-message results or is fire-and-forget. Because the legacy APNs and GCM endpoints are retired, delivery receipts are moot until the transports are replaced. Assume you will need to add result handling yourself if you fork it.
- What is the recommended migration path away from this bundle?
- Do not adopt the bundle as a dependency. Treat it as a design reference and implement push through Laravel's notification system with maintained channels such as laravel-notification-channels/apn and laravel-notification-channels/fcm. If a stakeholder insists on reuse, vendor the repository and replace both transport adapters, keeping only testable message-composition classes. Confirm the business requirement and channel mix, such as iOS only, Android, or WebPush, before committing to any path.