isSupported doesn't cover iOS haptics. Missing capability detection API

[jayk293]

isSupported checks for navigator.vibrate (Vibration API), which iOS Safari doesn't implement, so it returns false on iOS. But .trigger() still fires haptics on iOS via the <input type="checkbox" switch> fallback you've built in.

Discovered this when I wanted to provide a toggle for enabling haptics in my app, expecting this toggle to not be shown in the desktop version.
if (WebHaptics.isSupported) showHapticsToggle(); // This hides on iOS Safari, even though haptics work

To me, isSupported is more of a check on whether the Vibration API is supported, rather than haptics are supported on the device.

Would you be open to amending isSupported or adding like a canHaptic property that covers both paths?

static readonly canHaptic =
    typeof navigator !== "undefined" &&
    (typeof navigator.vibrate === "function" || navigator.maxTouchPoints > 0); 

navigator.maxTouchPoints > 0 is true on iOS and Android, false on desktop, matching the environments where haptics actually fire.

Happy to open a PR if this direction makes sense to you.

[lochie]

hey youre right! isSupported is currently incorrect. you're welcome to do a PR to update isSupported to be correct, or i can look into it shortly

[Raandino]

I dug into this from an app-side repro on iPhone Chrome/Safari and confirmed the mismatch.
trigger() can still produce haptics on iOS through the hidden label + input[type="checkbox"][switch] fallback, but WebHaptics.isSupported currently only checks navigator.vibrate. So for app code, isSupported behaves more like “supports the Vibration API” than “WebHaptics can actually attempt haptics here”.
That creates a real integration problem because apps naturally use isSupported to decide whether to show a toggle or enable haptics, and that incorrectly hides iPhone support.
My proposed fix is:

• change WebHaptics.isSupported to return true when either:
  • navigator.vibrate exists, or
  • the device looks touch-capable enough for the existing fallback path
• add a separate WebHaptics.supportsVibrationApi static property for consumers that want the narrower signal
• expose that same distinction through the React/Vue/Svelte helpers
• update the README/docs so isSupported matches runtime behavior
  That keeps isSupported useful for product-level capability gating, while preserving a more explicit API for callers that specifically care about the Vibration API.

[jayk293]

Fix IsSupported already created

[Raandino]

Oh, thanks!