Mobile Detect Bundle Laravel Package

Product Decisions This Supports

• Mobile delivery strategy: separate m-dot/tablet site vs. responsive. This bundle exists to implement the separate path — redirect to a mobile or tablet host, swap views by device class, and switch hosts. If the roadmap question is "do we ship a dedicated mobile experience?", this scopes the redirect/view-switching work down to config. It does not help you decide responsive vs. adaptive; it presumes you already chose adaptive.
• Build vs. buy for device detection. Verdict: buy the underlying library, not necessarily this bundle. It's a thin Symfony wrapper around mobiledetect/mobiledetectlib (MIT, widely used). The real build-vs-buy decision is "hand-roll UA parsing in middleware" vs. "depend on a maintained regex table" — and the library wins that. The bundle adds Symfony DI wiring, Twig helpers, and redirect config; that's convenience, not capability.
• Framework fit is a decision, not a detail. Despite being listed here as a PHP package, this is a Symfony 2/3/4/5 bundle with no Laravel service provider. On Laravel, the correct decision is to use mobiledetectlib directly inside a middleware plus a view-hint binding — roughly 150–250 lines — or pick a maintained Laravel-specific wrapper. Adopting this bundle in a Laravel app means porting it, which is strictly worse than depending on the library.
• Legacy platform triage. If we own a Symfony 2/3/4 app with an existing m-dot, this is the smallest-diff way to keep redirects alive while we modernize. That's a maintenance decision, not a feature decision.
• Feature gating and device-class UX. Supports "open in app" banners, tap-to-call links, reduced asset payloads, simplified navigation, and device-segmented analytics/experiments. Useful, but each of these is better solved by CSS media queries or Sec-CH-UA-Mobile where available.
• Roadmap signal: device detection is commodity infrastructure. Do not put engineering effort into differentiating it; do put effort into removing it from the critical path over time. Any roadmap item phrased as "detect device to do X" should be challenged to "can X be responsive or client-side?"

When to Consider This Package

Reasonable fits:

• You run a Symfony 2–5 codebase (realistically 4/5, both end-of-life) and already have device-conditional routes or templates you need to keep working.
• You need redirect-to-mobile-host plus view switching and don't want to own UA parsing, Vary: User-Agent handling, and the redirect rules yourself.
• Your acceptance bar for dependencies is low and the surface area is small — no database, no queue, no admin UI, minimal transitive weight.
• You want a reference implementation for how to structure device detection in a framework (useful even if you reimplement it for Laravel).
• It is still being released (May 2025), so it isn't abandoned — but see risks below.

Look elsewhere or don't use it:

• Laravel. No service provider, no facade, no config publishing that matches Laravel conventions. Use the underlying library with middleware.
• Symfony 6/7. The bundle targets 2–5. Confirm compatibility explicitly before assuming it runs on a current LTS; if it doesn't, you're adopting an unmaintained-branch dependency.
• A responsive product. UA sniffing is the wrong tool for layout. Use media/container queries, and Sec-CH-UA-Mobile / Sec-CH-UA-Platform Client Hints on Chromium for server-side branching — with Accept-CH negotiation and a fallback.
• SEO-sensitive or high-traffic properties. Separate mobile URLs carry real canonical/Vary/redirect-loop risk. Google has moved to mobile-first indexing; an m-dot is a long-term maintenance liability rather than an advantage.
• Chrome UA reduction and spoofing. UA strings are frozen and increasingly coarse, and trivially spoofable. If detection drives pricing, entitlements, or security, this is not the control point.
• Anywhere you need a community backstop. 1 star, 0 dependents, single maintainer. If you adopt it, pin the version, vendor or fork it, and cover the redirect/Vary behavior with tests. No community will find your bug.

Practical adoption checklist: verify Symfony major compatibility → confirm the underlying mobiledetectlib version and its update cadence → write tests around caching/Vary and redirect loops → decide bot/crawler handling (you almost certainly want crawlers to see the canonical desktop URL) → confirm who owns the fork if the maintainer stops.

How to Pitch It (Stakeholders)

For executives: This is small plumbing, not a platform bet. It only earns a place if we are keeping a legacy Symfony application that already runs a separate mobile site — in that case it is the cheapest way to keep redirects and mobile views working while we modernize. For anything new, responsive design plus Client Hints covers the same need without adding user-agent sniffing to the request path, and without inheriting an m-dot we have to maintain forever. Adoption cost is near zero; ownership cost is the real line item, so the recommendation is: use it only inside the legacy scope, time-boxed, with an exit plan. Do not let it spread into new surface area.

For engineering: It is a thin Symfony bundle over mobiledetect/mobiledetectlib — DI service, Twig helper, config-driven host/view switching and redirects. It is Symfony ≤5 only; there is no Laravel integration, so for our Laravel services the plan is the library plus a middleware, not this package. If we do adopt it, pin the version, vendor or fork it (1 star, 0 dependents, single maintainer — no upstream safety net), ensure crawlers always receive the canonical URL, and add explicit tests for Vary: User-Agent and cache behavior, since that is where mobile redirects typically break. Treat UA detection as a hint that degrades gracefully, never as the sole gate for content or entitlements.