- What is laravel-notification-channels/ionic-push-notifications?
- It is a Laravel notification channel driver for sending push notifications to Ionic apps through Ionic's hosted Push API. It follows the canonical laravel-notification-channels pattern with a service provider registered via Composer auto-discovery, a channel class implementing Laravel's NotificationChannel contract, and a message/DTO class. Notification classes stay transport-agnostic, and the channel is swappable through via() and routeNotificationForIonic().
- Does this package still work with the Ionic Push API?
- No. It targets Ionic's hosted Push API at api.ionic.io/push/notifications with an Ionic API token and app ID, but Ionic retired its Push service and deprecated Ionic Cloud push in favor of direct APNs/FCM or third-party providers such as OneSignal. With no supported endpoint to authenticate against, there is no working end-to-end delivery path regardless of code quality.
- Which Laravel and PHP versions does this package support?
- It was built for the Laravel 5.3-5.6 era and is expected to require illuminate/support ^5.x, guzzlehttp/guzzle ^6, and PHP ^5.5 or ^7.0. It will not resolve on Laravel 9-11 or PHP 8.x without a fork and rewrite, and the release history provides no modern support commitment. Verify with composer why-not before attempting any integration.
- Is laravel-notification-channels/ionic-push-notifications still maintained?
- No. The repository is archived, the last release was 2017-10-17, and it has roughly 25 stars and zero dependents. There is no upstream maintainer to merge fixes, no signal of production use to inherit, and no CVE response process.
- How do I install and configure laravel-notification-channels/ionic-push-notifications?
- Historically you installed it with Composer, relied on package auto-discovery for the service provider, and published config containing an Ionic API token and app ID. You then added the channel to a notification's via() method and implemented routeNotificationForIonic() to return the device token. For any current Laravel or PHP version, Composer dependency resolution will fail, and the Ionic Push backend is retired, so installation is not recommended.
- How do I send a push notification with this channel?
- A notification class lists IonicPushChannel::class in via() and implements routeNotificationForIonic() to return the notifiable's device token. The channel then sends a message object, typically built in a toIonic() method, to Ionic's hosted Push API. The integration shape is clean, but no supported Ionic Push endpoint exists today, so the send cannot complete end to end.
- What are the best alternatives to Ionic Push for Laravel push notifications?
- Use Firebase Cloud Messaging HTTP v1, OneSignal, or direct APNs, depending on which provider your mobile client registers device tokens with. Keep notification classes transport-agnostic and implement or vendor a channel against the chosen provider. You can preserve via() compatibility by swapping the channel class token and returning the new provider's device token from routeNotificationForIonic() or routeNotificationForFcm().
- Can I use this package with Laravel 10 or Laravel 11?
- No. The dependency graph expects illuminate/support ^5.x, guzzlehttp/guzzle ^6, and PHP ^5.5 or ^7.0, so it will not resolve on Laravel 9-11 and PHP 8.x without a fork and rewrite. Even a successful fork would still target Ionic's decommissioned Push service. Run composer why-not against your target versions to confirm the conflicts.
- Is this package safe to use in production?
- No, treat it as high risk. It is archived and unmaintained, holds credential handling and outbound HTTP in the notification hot path, has no CVE response, and offers no PHP 8 compatibility guarantees. The code surface is small enough that owning a fork is cheap, but the fatal risk is the retired backend, not the handful of classes.
- How do I migrate from IonicPushChannel to FCM or OneSignal without rewriting my notifications?
- Preserve every notification class and its via() list, then substitute the channel behind a stable interface, for example IonicPushChannel to FcmChannel or an internal PushChannel. Reimplement routeNotificationForIonic() as routeNotificationForFcm(), or keep the method name and return the FCM or OneSignal device token so notification classes need no edits. If an external contract depends on the Ionic message shape, add a thin adapter DTO instead of leaking provider fields into notification classes.