FIELD NOTE 021TypeScriptReviewed July 2026

Mobile Device Detection

Detects mobile devices (phones/tablets) using user agent string

Copy the complete example or adapt its typed interface to your project. Comments are kept inside the snippet so the intent travels with the code.

pattern.ts
/**
 * Detect if user is on mobile device
 * @returns True if mobile device, false otherwise
 */
function isMobileDevice(): boolean {
  return /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent);
}

// More precise mobile detection (excludes tablets)
function isMobilePhone(): boolean {
  return /Android|iPhone|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) &&
         !/iPad/i.test(navigator.userAgent);
}

// Usage Example
if (isMobileDevice()) {
  console.log('Mobile view detected');
  // Apply mobile-specific styles/functionality
}

Useful for applying device-specific functionality, responsive design adjustments, or mobile-first features

Implementation note

Review the input assumptions and browser or runtime support before adopting a utility unchanged. Small helpers are easiest to maintain when their contract stays narrow.

How it works

The expression inspects the browser user-agent string for known mobile device markers and returns a convenient boolean. A narrower expression can distinguish phones from tablets for legacy behavior branches.

What to watch for

User agents are spoofable, change over time, and do not describe capabilities such as touch, screen size, pointer precision, bandwidth, or performance. Device detection often creates brittle experiences on hybrid hardware.

Production use

Prefer responsive CSS and direct feature detection. Use user-agent checks only for a documented platform defect or telemetry segment, keep the fallback functional, and revisit the expression as supported browsers evolve.

Before you ship

  • Confirm the input contract with tests that cover empty, invalid, boundary, and representative real-world values before sharing the helper across a codebase.
  • Keep the function focused on one responsibility and name any project-specific policy explicitly instead of hiding it inside a generic-looking utility.
  • Measure behavior in the browsers or runtime versions your product supports, especially when timing, storage, DOM state, locale, or network access is involved.
  • Document the return type, mutation behavior, failure mode, and performance characteristics beside the call site so future maintainers can evaluate changes safely.
  • Compare the example with current official platform documentation when it relies on a browser API, language feature, or runtime behavior that may change over time.
  • If the helper crosses a trust boundary, validate again on the server and avoid treating browser-side checks, TypeScript annotations, or formatted output as a security guarantee.
  • Add a small regression test whenever a real edge case is discovered; concrete examples preserve the reason behind a guard more reliably than a general comment.