Expo Laravel Package

Product Decisions This Supports

• Mobile stack selection (roadmap-level). It assumes Expo/React Native on the client and Laravel on the server, and it collapses the notification work into a single via() entry in an existing Notification class. If push notifications are on the near-term roadmap, this library is a credible reason to pick Expo over a bare React Native project — it removes the main backend objection to that choice.
• Build vs. buy, and specifically "buy vs. wire up." The alternative is not a SaaS vendor; it's ~200 lines of HTTP calls to Expo's push endpoint plus a device-token table, payload shaping, chunking, and error/ticket handling. This package is the buy option at zero cost (MIT). For a PM, that's a decision between one sprint of backend work plus permanent ownership, and an afternoon of wiring plus a much smaller surface to own.
• Push notification use cases it makes cheap to ship. Transactional (order status, appointment reminders, payment failures), security/operational (new device login, MFA prompts), and engagement (digests, re-activation nudges) all become a Notification class you can queue, test, and route per-user-preference like your existing email and SMS notifications. This matters because per-channel opt-out and "notify the user" logic usually gets reimplemented badly on mobile.
• Keeping mobile notifications in the existing Laravel mental model. Because it plugs into Laravel's Channel contract, notification preferences, queueing, throttling, localization, and testing patterns carry over from mail/SMS/database channels. That lowers the cost of the second and third push notification, which is where most of the roadmap value sits.
• Provider portability as a hedge. The Laravel channel abstraction means swapping to a dedicated push vendor later is a new channel class, not a rewrite of product code. It supports a "ship now, revisit at scale" sequencing decision rather than forcing a vendor commitment at MVP.
• Deferral signal, too. The low adoption numbers (69 stars, 0 dependents) mean the decision is really "vendor this small MIT library into our codebase" rather than "take a dependency." That reframes it as low-risk engineering work rather than a vendor-risk conversation, which is useful when push notifications are being deprioritized behind other roadmap items.

When to Consider This Package

Adopt (or fork) when:

• The mobile app is built with Expo — Expo-managed workflow, or bare React Native using expo-notifications and Expo's push service for FCM/APNs delivery. If you are not using Expo's push API, this package does nothing for you.
• The backend is Laravel and you already use, or intend to use, Illuminate\Notifications for at least one other channel. If your notification logic lives in service classes or event listeners, the abstraction buys you less.
• Notification volume is modest-to-moderate and use cases are transactional/user-targeted rather than campaign-driven. Hundreds to low tens of thousands of sends per day fits comfortably; broadcast campaigns to a large segmented audience do not.
• You want push in the MVP and are willing to pin a version and treat the source as yours — write integration tests against the Expo receipt endpoint, vendor the package if the maintainer goes quiet, and keep a thin internal wrapper interface in front of it.
• You have no dedicated mobile-backend team and want to avoid standing up separate FCM and APNs credentials/pipelines yourself.

Look elsewhere when:

• Native iOS/Android, Flutter, or non-Expo React Native. Use FCM/APNs directly, or the laravel-notification-channels/fcm / APNs packages. This package's core value is the Expo indirection.
• You need marketing-grade push. Segmentation, journeys, A/B testing, send-time optimization, in-app messaging, or cross-channel orchestration — that is OneSignal, Braze, Iterable, Airship, or Firebase territory. This package sends messages; it does not run campaigns.
• You need a support contract or a guaranteed SLA. 69 stars, 0 dependents, and a single-maintainer community project mean no vendor to escalate to. Anything customer-facing and revenue-critical at scale should be weighed against a paid vendor or an in-house implementation.
• You need delivery receipts, token pruning, and retry semantics at scale. Verify what the package actually handles before committing. Expo's push API returns per-message tickets that must be polled for receipts to detect DeviceNotRegistered errors; if the package does not manage receipt polling and token cleanup for you, budget for that work regardless of which option you pick.
• Web push, email, or SMS are also in scope. Those are separate channels. Don't let adopting this package read as "notifications solved."

How to Pitch It (Stakeholders)

To executives: Push notifications are table stakes for retention and for transactional confidence ("your order shipped," "your appointment is tomorrow"). Today, that work sits on the critical path of the mobile launch. This library, which is free and MIT-licensed, lets the team deliver push notifications through the same Laravel machinery we already use for email and SMS — roughly a day of integration instead of a sprint of custom work, with no new vendor contract, no new line item, and no lock-in. The trade-off is that it's a low-adoption community project, so we plan to pin it, wrap it behind our own interface, and cover it with tests; the code is small enough that we can own it outright if the maintainer disappears. Recommendation: use it for the MVP, revisit if push volume, campaign needs, or reliability requirements outgrow it.

To engineering: This is a thin adapter, not infrastructure. It gives us a ExpoChannel that slots into Notification::via(), so device tokens, payloads, and Expo's ticket/error handling live in one place instead of being copy-pasted across features. Adopt it, but on our terms: pin the version, put our own interface in front of it, add an integration test that exercises a real send plus receipt check, and confirm it handles Expo receipt polling and DeviceNotRegistered token cleanup — if it doesn't, that's the piece we build, and it's small. Do not let it become a load-bearing black box; assume we may fork it.