InputIntermediate

Haptic Feedback

The phone taps back — on mobile the hands ARE the screen, and haptics is the only physical channel you get.

inputhapticsmobilevibration

Examples

Captured from this page's own interactive demo below.

Overview

On a touchscreen there is no button travel, no spring, no click — a finger presses glass and the glass gives nothing back. Haptics is the missing half of every mobile input: a 10-millisecond tap when a button lands, a thump when a hit connects, a crisp double-tick on a win. Players don't consciously notice it, but hand a tester the same game with haptics off and they'll tell you the buttons feel 'mushy' without being able to say why.

Treat vibrations like sound design: short, shaped, and synchronized to the exact frame of the visual. UI ticks want 10–30 ms; gameplay impacts 40–80 ms; anything past 400 ms reads as an incoming call. Build a small vocabulary (light / medium / heavy, success / warning) and reuse it consistently — iOS formalized exactly this with its Taptic patterns, and players' hands already speak that language.

The platform reality check: on native iOS you get the rich Taptic Engine (UIImpactFeedbackGenerator); native Android gets amplitude control via VibrationEffect. On the web — which includes playable ads — Android Chrome and most webviews honor navigator.vibrate(), while iOS Safari ignores it entirely. So design haptics as a bonus layer that degrades silently: fire-and-forget, never gameplay-critical, always with a settings toggle.

Interactive Demo

pattern: pulse / gap / pulse · this browser has no vibration API — exactly why haptics must be a bonus layer

Pulses2

Pulse Length120ms

Gap80ms

Use Cases

Button presses and UI confirmationsHits taken and landed in mobile gamesWin, loss and reward momentsPlayable ads on Android (bonus layer)

Best Practices

Do

✓Fire the haptic on the exact frame of the visual — a 50 ms desync reads as lag in the fingertips.
✓Build a small reusable vocabulary: light tick for UI, heavy thump for impacts, patterns for outcomes.
✓Feature-detect and degrade silently — iOS web has no vibration API, and the game must not care.

Don't

✕Don't run vibrations past ~400 ms; long buzzes read as phone calls and drain the battery.
✕Don't vibrate on every frame of a drag or scroll — constant buzz numbs the hand in under a minute.
✕Don't ship without a haptics toggle; sensitivity varies and some devices buzz much harder than others.

Common Mistakes

⚠One long generic buzz for every event, turning a rich channel into a doorbell.
⚠Haptics tuned on a flagship phone and untested on budget devices whose motors are twice as strong and half as fast.
⚠A playable ad that gates progress on feeling a vibration — invisible on iOS, where navigator.vibrate does nothing.

Implementation

Paste this into your AI assistant (Cursor, Copilot, Claude) to add the effect to your project.

Prompt

Add the "Haptic Feedback" game-feel effect to my project: The phone taps back — on mobile the hands ARE the screen, and haptics is the only physical channel you get.

How it works: On a touchscreen there is no button travel, no spring, no click — a finger presses glass and the glass gives nothing back. Haptics is the missing half of every mobile input: a 10-millisecond tap when a button lands, a thump when a hit connects, a crisp double-tick on a win. Players don't consciously notice it, but hand a tester the same game with haptics off and they'll tell you the buttons feel 'mushy' without being able to say why.

Guidelines:
- Fire the haptic on the exact frame of the visual — a 50 ms desync reads as lag in the fingertips.
- Build a small reusable vocabulary: light tick for UI, heavy thump for impacts, patterns for outcomes.
- Feature-detect and degrade silently — iOS web has no vibration API, and the game must not care.

Avoid:
- Don't run vibrations past ~400 ms; long buzzes read as phone calls and drain the battery.
- Don't vibrate on every frame of a drag or scroll — constant buzz numbs the hand in under a minute.
- Don't ship without a haptics toggle; sensitivity varies and some devices buzz much harder than others.

Implement the effect in whatever engine/stack the project already uses and follow its existing code style. Wire it up where it makes sense.