Haptics when the audio channel is already busy
Last verified August 22, 2026 · 7 min read
A rest timer ends and the app plays a chime. At that moment the phone is already playing the user's music, or a podcast, or your own coach voiceover, and quite possibly two of those ducked against each other. The chime lands in the middle of that mix, in a room with a fan running and a plate rack being unloaded. Audio is the channel a fitness app has the weakest claim on, and it is the channel most workout cues get built from first.
Haptics are the way out, with one condition attached from the start: a tap is a second channel, never the only one. This page is engineering guidance. The legal layer lives in compliance, and this cluster makes no claims there.
What Apple actually says about pairing the two#
Apple's Human Interface Guidelines put haptics under accessibility with one specific instruction:
"Use haptics in addition to audio cues. If your interface conveys information through audio cues — such as a success chime, error sound, or game feedback — consider pairing that sound with matching haptics for people who can't perceive the audio or have their audio turned off."
Three phrases carry the whole design. In addition to: the chime stays. Matching: the same event on both channels, not a second vocabulary the user has to learn. And the closing clause names two groups in one breath — people who can't perceive the audio, and people who have their audio turned off. At six in the morning in a commercial gym, the second group is most of your users, and they get the fix for free, because it is the same fix.
Keep Apple's verb as well. The sentence says "consider pairing", not "you must pair". We are not going to upgrade it here.
On iOS the framework is Core Haptics, which Apple summarises as "Compose and play haptic patterns to customize your iOS app's haptic feedback". The overview adds: "Core Haptics lets you add customized haptic and audio feedback to your app. Use haptics to engage users physically, with tactile and audio feedback that gets attention and reinforces actions." Apple's own description of a haptics framework keeps saying "and audio". The two are meant to be composed, not swapped.
Android: read Google's guide before porting anything#
Google publishes a haptics guide for Android. We fetched it while compiling the evidence for this cluster and confirmed it is the canonical page, but we did not extract sentences we are prepared to quote. So this page describes nothing about the Android API — no constant names, no defaults, no behavior on any device class. Read it before you design the Android cue set, and do not assume an iOS haptic vocabulary transfers unchanged.
That gap is deliberate. Inventing a plausible-sounding Android constant would be the one error we cannot walk back, and a reader who ships against it finds out in production.
What a tap can carry#
A haptic is a very low-bandwidth channel, and the bandwidth drops further when the person receiving it is under load, breathing hard, and thinking about their third rep. Design for two or three discriminable patterns per app, not a language.
| Cue | Works as a haptic | Why |
|---|---|---|
| Set complete | Yes | Binary, and the user is already waiting for it |
| Rest over, next work interval starting | Yes | Binary and time-critical, at exactly the moment eyes are elsewhere |
| Interval change in a structured session | Yes, with two patterns at most: work starts, work ends | Any finer distinction is guesswork for the person feeling it |
| Form warning | As an alert, yes. As a diagnosis, no | It can say "look at the screen"; it cannot say which knee |
| Which of eight exercises comes next | No | More states than anyone can discriminate mid-set |
| Heart-rate zone, one of five | No | Same problem, and the user cannot check their answer without looking anyway |
Our rule of thumb, offered as judgement rather than as anyone's documentation: if you cannot name the states on one hand and describe each in two words, the haptic is an alert to look at the screen and nothing more. Ship it as that, label it as that internally, and stop trying to encode a value in it.
The corollary is that a haptic almost always needs a visual state that persists. The tap says something happened; the screen says what. If your rest timer's only record of "rest is over" was a buzz two seconds ago, a user who was mid-rep when it fired has no way to recover the information except to guess.
Where haptics stop working#
This is the part that gets left out of accessibility write-ups, and it is the reason the pairing rule exists in both directions.
Gloves. Lifting straps. Cold hands outdoors in February. A phone in an armband on the opposite arm, in a jersey pocket, in a bike mount two feet from anybody's skin, or face-down on a bench while the user does the set. A haptic delivered to a device nobody is touching was not delivered. And reduced sensation in the hands is exactly as real a condition as reduced hearing, which means the population you added haptics for and the population that cannot feel them overlap.
So the design rule is symmetrical with Apple's sentence: every event that matters gets an audible cue, a visible state change, and a haptic, and the app remains usable when any one of the three is missed. That is more work than picking a nice pattern, and it is the actual accessibility outcome. A single-channel cue is a cue that some of your users simply do not receive, and you will never see it in a crash report.
Two more traps worth naming. Do not use a haptic for anything destructive without a confirmable state — a tap that means "workout ended" and nothing on screen to prove it is worse than no cue. And do not fire haptics continuously as ambient feedback during a set; a channel that is always active carries no information when something actually happens.
The wrist is a better place for a tap than the pocket#
A watch is strapped to skin by definition, which a phone in a waistband is not. If your product already has a watch app, or could, the wrist is where cue delivery stops depending on where the user happened to put the phone, and it is the surface the user glances at to resolve the cue anyway. That is a physical argument rather than a platform claim; we have not measured anything about haptic hardware on any device.
Building that side of it is the watch-apps cluster, and the differences that matter between the two watch platforms are in watch platform differences. If the cue you want to deliver is a form correction coming out of a camera or sensor pipeline, how form feedback works covers what that pipeline can honestly tell you before you attach a buzz to it.
Monday morning#
Make a list of every audio cue your app plays during a workout. For each one, write down the event it represents and whether that event is binary. Pair the binary ones with a haptic and a persistent visual state; for the rest, demote the haptic to "look at the screen" and stop there.
Then run the app three times without changing any code: once with system sound off, once wearing training gloves, and once with the phone in an armband while you actually move. Every cue you miss is a cue that currently has one channel. Fix those, and read Google's haptics guide before you write the Android half. Testing the whole thing on hardware you do not own is device lab and CI.
Frequently asked questions
- Should a rest-timer haptic replace the chime or play alongside it?
- Alongside. Apple's guidance is to use haptics in addition to audio cues, and to consider pairing a sound with matching haptics for people who cannot perceive the audio or have it turned off. The word is addition, not instead. Replacing the chime moves the problem rather than solving it, because a haptic reaches nobody whose phone is in an armband, a jersey pocket or a bike mount. Keep the sound, add the tap, and make sure the screen still shows a persistent state that survives both being missed.
- How many distinct haptic patterns can somebody tell apart during a set?
- Fewer than you want. We have measured nothing here, so treat this as design judgement rather than a platform fact: assume two or three patterns per app, and only for events the user is already expecting. Set complete and rest over work because they are binary and anticipated. Encoding which of eight exercises is next, or which of five heart-rate zones the user is in, does not, because the person feeling it is under load and cannot check their answer without looking at the screen anyway. If a cue needs more states than that, the haptic means look at the screen.
- What happens to haptic cues when the user is wearing gloves or the phone is in an armband?
- They may not arrive at all, and your app will never know. Gloves, lifting straps, cold hands and reduced sensation all cut the channel at the skin; an armband, a jersey pocket or a bike mount cuts it before that, because a device nobody is touching cannot tap anybody. This is the reason a haptic is a second channel rather than a replacement. Give every event that matters an audible cue, a visible state that persists after the moment has passed, and a haptic, then confirm the app is still usable when any one of the three is missed.
Keep reading
Elsewhere on the site
Pages that share this one’s concepts and sources, from other sections.
Next steps
Was this page useful?
Independent comparison, last reviewed August 22, 2026. Pricing, rate limits, and feature availability change often — confirm current details in each provider’s official documentation before you commit. Product and company names are trademarks of their respective owners; AIFitnessAPI is not affiliated with, endorsed by, or sponsored by any product listed here.
← All accessibility · by AIFitnessAPI